Menu
What is a good deployment strategy to use with Git + Heroku (Ruby on Rails)?
Currently, the way I work with my origin Git repository: All features (or 'stories') are first checked out as branches, then get merged with master and pushed to origin.
Anything pushed to origin/master triggers a script that pulls the new rails code to the staging area (simple rails webserver).
When the time comes for me to push a new production version to Heroku, should I create a new branch (called something like production_version_121), and push that somehow to Heroku?
Ideally, I'd like to pick and choose which features from previous development versions I should include into the production branch... test it, and push to Heroku.
For example, I may not want all the latest code to get pushed to production. I might want to feature "a" that I had worked on and feature "c" both merged into production somehow, without including experimental feature "b" which needs more debugging.
N.B. I'm going to try avoiding Capistrano at first and get something working manually for now.
Any thoughts? Best practices?
812
To deploy your app to Heroku, use the git push command to push the code from your local repository's main branch to your heroku remote. For example: $ git push heroku main Initializing repository, done. updating 'refs/heads/main' ...
Our first method is not only the most common, but also the simplest: pushing code from a Git repository to a Heroku app. You simply add your Heroku app as a remote to an existing Git repository, then use git push to send your code to Heroku. Heroku then automatically builds your application and creates a new release.
To see what's been deployed on the Heroku dashboard: Just click the Overview tab. You'll see an Activity view on the right that shows recent deployments with commit hashes. This should be the accepted answer.
The Heroku platform uses Git as the primary means for deploying applications (there are other ways to transport your source code to Heroku, including via an API). When you create an application on Heroku, it associates a new Git remote, typically named heroku , with the local Git repository for your application.
In the Gemcutter project we simply have a production branch. Any changes that we want to see on the production site get merged into that branch, and then deployed with:
git push heroku production:master The staging branch serves a similar purpose for the staging site (also on Heroku)
61
Ever since I read Vincent Driessen's A successful Git branching model, I have been hooked. My entire company (8 of us) have now standardized on this model and a few other places I've consulted with have also started using it as well.
Most everyone I've shown it to says they were doing something similar already and found it very easy to adapt.
In a nutshell, you have 2 branches that are permanent (master and develop). Most of the time you'll just be making branches off of develop and merging them back into develop. Things get a little more complex when you get into doing production releases and hotfixes, but after reading the post a couple of times, it becomes engrained.
There's even a command line tool called git-flow to help you out.
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
