Update: We have released a free ebook about our workflow: Efficiency in Development Workflows.
Last week we talked about how we review code, open pull requests and use Github issues to manage our development workflow.
This week I will show you every step that happens after a pull request is merged into our controller branch. We use an automated deployment pipeline for releasing our code into production. Feel free to read our documentation where we explain step-by-step how you can set up deployment to Heroku with Codeship.
Deployment Pipelines
A deployment pipeline lays out the whole process that your code needs to go through from your repository to production. It breaks the build into several parts (e.g. build, test and deploy) and all the associated steps that need to be taken. By defining a pipeline it is always clear which step needs to happen next. Martin Fowler describes it really well in his blogpost.
If you want to dig deeper into Deployment Pipelines I highly recommend Jez Humble and David Farley's book: Continuous Delivery. I also encourage you to read our Codeship documenation articles on deployment pipelines and wildcard deployments.
Configure deployments per branch
To automate deployment to different environments we have found that it works best to define actions for different git branches. If you always push the latest commit of your production branch to your production environment, it s very easy to determine what is currently deployed by just looking at the git branch. Git and other source code management systems only permit one commit at the top of a branch, so there can be no confusion.
At Codeship we deploy our controller branch automatically to production. Many of our customers deploy the controller branch to a staging environment and a production branch to their production environment. A simple git merge and git push, or a Github pull request, is their way of releasing their changes.
One problem with this approach is that branch names have to be meaningful. Having a development branch which is deployed to staging and a controller branch that gets deployed to production can confuse new team members. Naming branches that get deployed "production" or "staging" is more intuitive. "controller" is a convention in git and should be kept, but dedicated branch names are easier to understand in a deployment pipeline.
Deployment Strategy
As soon as the feature branch is merged into our controller, a new build is started on the Codeship. We run the same test commands again as we did on the feature branch to make sure there are no problems in the merged version.
When all tests pass for the controller branch the deployment starts. Before pushing to production we want to make sure that all database migrations work and that the app starts successfully.
First we deploy to staging. Then we run our current set of migrations. We copy our production database to staging once a day. Therefore, when we run migrations on staging, the database is very close to our production database. This allows us to make sure our migrations work, before deploying to production.
[caption id="attachment_360" align="alignnone" width="885"]
Deploying to staging[/caption]
The last step in our staging deployment is calling the URL of our staging site to make sure it started successfully. Wget and its retry capabilities make sure the website is up and running.
[caption id="attachment_359" align="alignnone" width="885"]
Deploying to production[/caption]
Then we run our migrations in a separate step after the deployment and clear our cache.
[caption id="attachment_358" align="alignnone" width="885"]
Running migrations[/caption]
Then we repeat the whole process for our production system. We push to the Heroku production repository and check that the site still works.
An enhancement would be to have tests that run against the deployed version, but so far we haven’t had any problems without these tests. Our extensive Cucumber/Capybara test suite has caught all problems so far.
There is one slight difference between our staging and production deployment though:
Zero Downtime Deployment
As we want to deploy several times a day without any downtime we use Heroku’s preboot feature. We started using it at the beginning of this year. Whenever we push a new release, it starts this release on a second server and switches the routing to it after about 3 minutes.
The downside is that zero downtime deployments require more care with database changes. As two versions of your codebase need to be able to work at the same time you can’t just remove or rename fields.
Renaming or deleting a column or table needs to be spread out over several deployments. This way we make sure that the application still works with every incremental change. We will go into more detail on database migrations for zero downtime deployments in a later blog post.
In the meantime, you can take a look at the blog posts in our "Further Info" section that explain Zero Downtime Deployments by Etsy, Braintree and BalancedPayments.
Conclusions
It is important to automate every step of the deployment. No matter if you want to deploy your code on every merge to controller or trigger it manually by merging the controller into another branch.
Now that we’ve gone from working on a feature to code reviews and finally pushing to production in our web application we will take a closer look at our test infrastructure next time.
In the next blog posts I will delve into Immutable Infrastructure and how we rebuild our test server infrastructure several times a week. Click the link to read about it!
Let us know what your strategies and lessons learned for deployment are in the comments.
Ship long and prosper