I've been having this issue many times. When I promote my staging app to production its config vars are not loaded properly. Right now my production app is using my staging's config vars. How can I fix this?
From the docs:
Pipelines only manage the application slug. The Git repo, config vars,
add-ons and other environmental dependencies are not considered part
of a pipeline and must be managed independently.
So if your "build artifact" (i.e. your slug) contains config vars from your staging app, it will get promoted to prod. All pipelines really do is allow you to skip the slug compilation by simply using the exact same slug from the previous environment. If you cannot remove config vars from the slug compilation for your code base in the staging environment, I would avoid pipelines.
Note: this is true as of the time this answer was submitted, who knows if Heroku will be able to change this in the future.
Related
I followed the documentation here https://devcenter.heroku.com/articles/pipelines and setup a pipeline with two stages:
The above link only talks about how to promote an app, without specifying how to deploy, this section specifically (we can read beyond this point and see there is no instruction on how to deploy):
Pipelines let you define how your deployed code flows from one
environment to the next. For example, you can deploy code to your
staging app (which builds it into a slug) and later promote that same
slug to production. This promotion flow ensures that production
contains the exact same code that you tested in staging, and it’s also
much faster than rebuilding the slug.
So I used the same command we use for deploying non-pipeline based apps (as instructed here):
docker push registry.heroku.com/ultimate-hello-world-cra-stage/web
This appears to be a wrong approach. You can see in snapshot above that STAGING app did get deployed, but when I try to promote the app using this command heroku pipelines:promote --app ultimate-hello-world-cra-stage, I get this error: Error: Pipeline promotions are not supported on apps pushed via Heroku.
What is the correct way to deploy to a pipeline and where can I find it in the docs?
I am using gitlab as repository and want to push my code on ec2 whenever any commit is done on gitlab. The gitlab CD/CI documentation states that I have to add a file .gitlab-ci.yml at the root directory of my repo. This is actually a problem for me because, I want project repo to have only code and not any configuration related info like build and deploy etc. Also when anybody clones the repo, they would have access to location where my code is pushed/deployed on ec2. Is there any work around for this problem ?
You'll need to use a gitlab-ci.yml filke to deploy your application. The file provides instructions and a pipeline "infrastructure" which, if properly configured, will build, test and automatically deploy your code.
If you are worried about leaking credentials, you should use the built-in instance variables to mask your important bits, like a "$SERVERNAME" or "$DB_PASSWORD" for instance.
Lastly, you can use the power of gitignore, in order to not publish all of your credentials or sensitive bits to your projects' servers or instances.
Heroku provides its own database name and other credentials, but my local database name is different.How can I change the database name according to the database credentials provided by heroku during production?
Use a package like dotenv. dotenv and variants of it likely exist for whatever language you're using.
Basically, you want to use environment variables instead of hard coding values into your code. So, instead of writing something like this:
my_database_connect('my_username', 'abc123')
You'd write:
my_database_connect(process.env.DB_USERNAME, process.env.DB_PASSWORD)
Heroku will already have these environment variables set on the "config" tab of your app. Then for local development, you'll create a file called .env and have this text in it:
DB_USERNAME=my_username
DB_PASSWORD=abc123
Don't commit .env to your git repository – it should only live on your machine where you develop. Now your code will run locally as well as on Heroku, and connect to the proper database depending on the environment it's running in.
Here's an article that explains this more thoroughly for node.js, although this is basically the best practice for general development: https://medium.com/#rafaelvidaurre/managing-environment-variables-in-node-js-2cb45a55195f
First I created an application name on Heroku. Then I deployed my app to heroku by connecting to github.
Heroku provides the database credentials after we deploy our applications. Then I redeployed the app through github by changing the configuration in application.properties file as follows:
#localhost configuration
SPRING_DATASOURCE_DRIVER_CLASS_NAME=org.postgresql.Driver
SPRING_DATASOURCE_URL=jdbc:postgresql://localhost/transactions?useSSL=false
SPRING_DATASOURCE_USER=postgres
SPRING_DATASOURCE_PASSWORD=some_pass
#server database configuration
SPRING_DATASOURCE_DRIVER_CLASS_NAME=org.postgresql.Driver
SPRING_DATASOURCE_URL=jdbc:postgresql://ec2-23-23-247-222.compute-1.amazonaws.com/d6kk9c4s7onnu?useSSL=false
SPRING_DATASOURCE_USER=rimjvlxrdswwou
SPRING_DATASOURCE_PASSWORD=dd903753bc0adffb96ce541b1d55fb043472e32e28031ddc334175066aa42f69
Then you have to edit the config vars according to your application.properties files as shown in the figure below
config_var.png
I am investigating adding an app.json file to my heroku pipeline to enable review apps.
Heroku offers the ability to generate one from your existing app setup, but I do not see any way to prevent it from automatically committing it to our repository's master branch.
I need to be able to see it before it gets committed to the master branch because we require at least two staff members to review all changes to the master branch (which triggers an automatic staging build) for SOC-2 security compliance.
Is there a way that I can see what it would generate without committing it to the repository?
I tried forking the repo and connecting the fork to it's own pipeline, but because it did not have any of our heroku add-ons or environment, it would not work for our production pipeline.
I am hesitant to just build the app.json file manually - it seems more prone to error. I would much prefer to get the automatically generated file and selectively remove items.
As a punchline to this story, I ended up investing enough time into the forked repository on it's own pipeline to demonstrate a POC
When you generate your app.json file, it should take you to a secondary screen that has the full app.json in plaintext at the bottom.
Why not open a PR with its contents in your project root. Once it's detected on the repository Heroku shouldn't ask you to regenerate it again.
I made a Sinatra app, that will be hosted on Heroku, and the source will be up on GitHub. The problem is that i have a file with API keys, that is currently in .gitignore. Is there a way, that I can push my repo to heroku with the key file and exclude the file when pushing to GitHub?
Thanks in advance!
It is possible to maintain a separate branch just for deployment, but it takes much discipline to maintain it properly:
Add a commit to a production branch that adds the config file (git add -f to bybass your excludes).
To update your production branch, merge other branches (e.g. master) into it.
However, you must then never merge your production branch into anything else, or start branches based on any “production commit” (one whose ancestry includes your “add the keys” commit).
An easier path is to adopt Heroku’s custom of using environment variables to communicate your secret values to your instances. See the docs on Configuration and Config Vars:
heroku config:add KEY1=foobar KEY2=frobozz
Then access the values via ENV['KEY1'] and ENV['KEY2'] in your initialization code or wherever you need them. To support your non-Heroku deployments, you could either define the same environment variables or fall back to reading your existing config files if the environment variables do not exist.
The Figaro gem provides a good way to manage this issue. It basically simulates Heroku's environment variable approach locally, and makes it easy to keep your keys in sync between your development environment and Heroku.