Single branch development is easy. But this strategy’s easiness blows up once you release code to the general public. If you need to hot-fix an instance of deployed code, while in the midst of a development cycle, single branch development gets in your way by requiring you think. On the other hand, having more than one branch at least allows you to jump back in time via an alternate branch to perform a patch, while not disturbing an unfinished developmental branch. And you can do this without having to think much.
Consequently, if you have multiple Git branches (such as those managed via git-flow) you can map those branches to different Heroku environments quite easily. First, you’ll want to appropriately name your remote Heroku environments; for instance, you can name the remote repositories
You can add a remote Git repository like so:
heroku_app_name is the name you gave your app or the one automatically created by Heroku via the
heroku create command.
With different Heroku environments, you can easily map each one to a Git branch. For instance, a production environment can map to the
master branch and a test environment can map to a branch called
release. If you have a development environment, that can map to a branch dubbed
develop (note, these branch names correlate nicely with git-flow’s defaults).
To deploy the
release branch to your Heroku test environment, you can issue this command:
If you deploy often (i.e. push a lot!) and you can’t seem to remember the
release:master portion, you can create a remote alias like so:
Thus, deployments to the test environment are as simple as:
Heroku’s deployment model, which leverages Git, couldn’t be any simpler; what’s more, setting up a release pipeline with multiple environments mapped to different Git branches is just as easy. Dig it?