Quiz time!
- How many times (each day) have you typed this at your console?
git push heroku masterand then forgotten to runheroku run rake db:migrate --app yellow-snow-3141orheroku ps:restart - Does your script support a multi-stage environments?
- Do you remember how to get to the application’s console process?
- Is your application’s configuration consistent across all stages?
- Are you deploy scripts tested?
Yeah, me too.
Enter heroku_san, the 85% solution, which allows me to do this:
$ rake staging deployAnd this is what happens: Maintenance mode is turned on; the latest green build is deployed to my staging server; all pending migrations are run, the app restarted, and then maintenance mode disabled. All while I go get a fresh cup of joe.
The value for us is that we don’t repeat ourselves, that our app will deploy, and we are confident that extending the toolkit is easy with a clear API and good test coverage. That’s a big win when you have dozens of apps deploying all day long.
Installation is pretty simple; add gem 'heroku_san' to your Gemfile (you are using Bundler, aren’t you?). This gem is only used locally, so you can add it to your group :development, :test block. Then create and edit a configuration file; config/heroku.yml[1]. The README file has more details and there’s a wiki on github with handy tips on how to extend the basic functionality in common ways.
So, why?
The gem has been around since 2010 and supported by a loyal core of maintainers. Version 2.1.1 brings changes large and small.
The biggest change since v1.3 is the creation of 2 new classes: Project and Stage, and a test suite to drive out the features. The task library is now almost entirely simple method calls, so there’s a lot of confidence that they will run correctly. Just to make sure, however, I’ve written an integration test, remote.feature which exercises the whole stack by creating an app on Heroku and run it through its paces. It’s worth a read.
There are some other new features worth highlighting:
- Heroku stack support (aspen, bamboo and cedar)
- Direct use of the Heroku::Client (instead of calls out to the shell)
- tags — By adding an (optional) tag configuration value to your
heroku.ymlfile,heroku_sanwill deploy only the most recent revision with that tag to your stage. This is great for creating a multi-stage environment, and when combined with auto_tagger and a continuous integration server (CI), you get a lot of bang for a little bit. See the wiki for more complete instructions.
tl;dr
Why write your own deploy scripts, again. Use heroku_san (or another gem like kumade)
Notes
[1]: I am working hard to remove the Rails dependencies.
About the Author
