Simplify your Heroku deploy with quick and concise deployment rake tasks.
Add this line to your application's Gemfile:
and then execute
install it yourself with
gem install paratrooper
Instantiate Paratrooper with the name of your heroku application.
You can also provide a tag:
.('amazing-app') do |config| config.tag = 'staging' end
You can authenticate your Heroku account in a few ways:
- Provide an API Key
.('app') do |config| config.api_key = 'API_KEY' end
- Set an environment variable
ENV['HEROKU_API_KEY'] = 'API_KEY' .('app')
- Local Netrc file
This method works via a local Netrc file handled via the Heroku Toolbelt and is the default and preferred method for providing authentication keys.
Git SSH key configuration
If you use multiple SSH keys for managing multiple accounts, for example in your
.ssh/config, you can set the
.('amazing-app') do |config| config.deployment_host = 'HOST' end
This also works if you're using the heroku-accounts plugin:
Paratrooper.deploy('app') do |config| config.deployment_host: 'heroku.ACCOUNT_NAME' end
Please note: Tag management has been removed from Paratrooper 3. It added unneccesary complexity around an individual's deployment process.
Sensible Default Deployment
You can use the object's methods any way you'd like, but we've provided a sensible default at
This will perform the following tasks:
- Push changes to Heroku
- Run database migrations if any have been added to db/migrate
- Restart the application if migrations needed to be run
namespace :deploy do desc 'Deploy app in staging environment' task :staging do .("amazing-staging-app") end desc 'Deploy app in production environment' task :production do .("amazing-production-app") end end
Bucking the Norm
Our default deploy gets us most of the way, but maybe it's not for you--we've got you covered. Every deployment method has a set of callback instructions that can be utilized in almost any way you can imagine.
add_callback method allows for the execution of arbitrary code within different steps of the deploy process.
There are 'before' and 'after' hooks for each of the following:
For example, say you want to let New Relic know that you are deploying and to disable your application monitoring.
# lib/tasks/deploy.rake namespace :deploy do desc 'Deploy app in production environment' task :production do .("amazing-production-app") do |config| config.add_callback(:before_setup) do |output| output.display("Totally going to turn off newrelic") system %Q[curl https://rpm.newrelic.com/accounts/ACCOUNT_ID/applications/APPLICATION_ID/ping_targets/disable -X POST -H "X-Api-Key: API_KEY"] end config.add_callback(:after_teardown) do |output| system %Q[curl https://rpm.newrelic.com/accounts/ACCOUNT_ID/applications/APPLICATION_ID/ping_targets/enable -X POST -H "X-Api-Key: API_KEY"] output.display("Aaaannnd we're back") end end end end
Or maybe you just want to run a rake task on your application. Since this task may take a moment to complete it's probably a good idea to throw up a maintenance page.
# lib/tasks/deploy.rake namespace :deploy do desc 'Deploy app in production environment' task :production do .("amazing-production-app") do |config| config.maintenance = true config.add_callback(:after_teardown) do |output| output.display("Running some task that needs to run") config.add_remote_task("rake some:task:to:run") end end end end
- Fork it
- Create your feature branch (
git checkout -b my-new-feature).
- Commit your changes (
git commit -am 'Add some feature').
- Push to the branch (
git push origin my-new-feature).
- Create new Pull Request.
- Rye Mason for the fantastic heading image.