As I dip my toes back into programming waters after a several-year hiatus, I’m finding that I’m pretty rusty and things have changed quite a lot in the Rails world. As I run across sticky problems or new ways of doing things, I’ll be noting them and writing the occasional blog post. I promise there will be nothing earth-shattering in any of these posts, and these posts will likely serve more as a reminder to myself than a public service of any sort, but the occasional useful insight may accidentally slip its way in.
One great development since I’ve done any serious programming is Heroku. I spent way too many hours hacking away at the command line trying (often in vain) to get a Rails app deployed, and the ease of using Heroku is just awesome. I’ve been coding on some side project lately, and contributing on some other people’s Heroku projects, as well. Despite the extreme ease of use, each time I start working on a new project, I seem to end up googling for the same set of information.
I often have multiple Heroku apps using the same base git repo. For example, most production apps I host on Heroku also have a QA app that I’ll deploy to before releasing a new version to production. Fortunately, it’s very easy to add multiple remotes to a project. I tend to give the remotes explicit names like heroku_production or heroku_staging just to give myself that last little reminder of what environment I’m deploying to.
> heroku git:remote -a your_production_app_name heroku_production
> heroku git:remote -a your_staging_app_name heroku_staging
But half of the time I’ve forgotten or done something that doesn’t follow this pattern, so I have to re-determine what I used. You can view your git remotes with:
> git remote -v
If you aren’t already using a similar pattern and would like to rename a git remote, it’s as easy as:
> git remote rename origin destination
Now that it’s all set up correctly, it’s time for a deployment. Deployment on Heroku is dead simple – just push to the correct remote git repo.
Use the git remote corresponding to the environment you wish to deploy from, and specify that you’re deploying from master:
> git push herokou_staging master
Deploying from a different branch or a tag is pretty dead-simple, too, though I’m embarrassed to admit how often have to look this up. I’m going to blame it on my stopping coding around the time everyone started moving from svn to git. (Yes, I realize that makes me a bit of a dinosaur)
> git push heroku_staging your_branch_or_tag_name:master
That’s all for now. Stay tuned for more blog posts in this series.
