When I first started using Heroku for deployment, it truly was a black box for ‘push button deployment’ as I joked — one simply typed ‘git push heroku master’ into a black box, i.e. your shell, and things ‘should’ work…
But what if they do not, or if you need more options when deploying an application?
So, I took advantage of the holiday weekend to deep-dive into Heroku and first was these two useful rake scripts for adding staging/production deployment environments and rolling back migrations/deployments.
- Gist by Nicola Junior Vitta for deploying, migrating and rolling back
- Gist by Michael Dwan for setting up, deploying and breaking down
- Gist by George Brock for creating and deploying to separate staging and production environments
The .rake files go into the lib/tasks directory for Rails 3 applications, and their usage follow their task naming convention in the .rake file. So, tasks that are nested would be called by ‘rake deploy:rollback_staging’ if rollback_staging were nested inside the deploy task code block.
The reason for these rake files is that Heroku currently supports only one rollback under the release management add-on, and if you are working on a share project where you are not the owner then you cannot enable the add-on… which is where the .rake files come in.
Finally, ‘heroku create’ appears to be a black box but it does come with options like most bash commands, e.g.: heroku create app-staging –stack bamboo-mri-1.9.2 –remote staging, where app-staging is the staging application name / bamboo-mri.1.9.2 is the flavor of Ruby selected for use in deployment / –remote staging is added as the staging branch for the deployment repository.
This write-up stems from my curiosity about deployment after poking around with Linode via Capistrano, which offer more control but also more configuration.