Managing releases and rolling back

What do we do if disaster strikes and our newly released code breaks our application? Luckily for us, Heroku keeps a copy of every deploy and configuration change to our application. This enables us to roll back to a previous version while we work to correct the errors in our latest release.

Note

Heads up! Rolling back only affects application code and configuration variables. Add-ons and our database will not be affected by a rollback.

In this recipe, we will learn how to manage our releases and roll back code from the CLI.

How to do it...

In this recipe, we'll view and manage our releases from the Heroku CLI, using the releases command. Let's open up a terminal now and navigate to one of our Heroku projects by performing the following steps:

1. Heroku tracks every deploy and configuration change as a release. We can view all of our releases from both the CLI and the web dashboard with the releases command:

   $ heroku releases
   === load-tester-rails Releases
   v33 Add WEB_CON config vars coutermarsh.mike@gmail.com 2014/03/30 11:18:49 (~ 5h ago)
   v32 Remove SEC config vars coutermarsh.mike@gmail.com 2014/03/29 19:38:06 (~ 21h ago)
   v31 Remove VAR config vars coutermarsh.mike@gmail.com 2014/03/29 19:38:05 (~ 21h ago)
   v30 Remove config vars coutermarsh.mike@gmail.com 2014/03/29 19:27:05 (~ 21h ago)
   v29 Deploy 9218c1c vars coutermarsh.mike@gmail.com 2014/03/29 19:24:29 (~ 21h ago)
   

2. Alternatively, we can view our releases through the Heroku dashboard. Visit https://dashboard.heroku.com, select one of our applications, and click on Activity:
   
3. We can view detailed information about each release using the info command. This shows us everything about the change and state of the application during this release:

   $ heroku releases:info v33
   === Release v33
   Addons: librato:development
    newrelic:stark
    rollbar:free
    sendgrid:starter
   
   By: coutermarsh.mike@gmail.com
   Change: Add WEB_CONCURRENCY config vars
   When: 2014/03/30 11:18:49 (~ 6h ago)
   
   === v33 Config Vars
   WEB_CONCURRENCY: 3
   

4. We can revert to the previous version of our application with the rollback command:

   $ heroku rollback
   Rolling back load-tester-rails... done, v32
    ! Warning: rollback affects code and config vars; it doesn't add or remove addons. To undo, run: heroku rollback v33
   

   Note

   Rolling back creates a new version of our application in the release history.

5. We can also specify a specific version to roll back to:

   $ heroku rollback v30
   Rolling back load-tester-rails... done, v30
   

   Note

   The version we roll back to does not have to be an older version. Although it sounds contradictory, we can also roll back to newer versions of our application.

How it works…

Behind the scenes, each Heroku release is tied to a specific slug and set of configuration variables. As Heroku keeps a copy of each slug that we deploy, we're able to quickly roll back to previous versions of our code without having to rebuild our application.

For each deploy release created, it will include a reference to the git SHA that was pushed to master. The git SHA is a reference to the last commit made to our repository before it was deployed. This is useful if we want to know exactly what code was pushed out in that release.

Note

On our local machine, we can run the $ git checkout git-sha-here command to view our application's code in the exact state it was when deployed.