Most Read This Week
Efficiency in Development Workflows: Deployment Pipelines
Learn how to set up Deployment Pipelines and how to deploy to production servers with Zero Downtime Deployment
By: Manuel Weiss
Sep. 2, 2013 01:45 PM
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 master branch. We use an automated deployment pipeline for releasing our code into production.
If you want to dig deeper into Deployment Pipelines I highly recommend Jez Humble and David Farley's book: Continuous Delivery.
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - Jez Humble and David Farley
Configure deployments per branch
At Codeship we deploy our master branch automatically to production. Many of our customers deploy the master 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 master branch that gets deployed to production can confuse new team members. Naming branches that get deployed"production" or "staging" is more intuitive. "Master" is a convention in git and should be kept, but dedicated branch names are easier to understand in a deployment pipeline.
When all tests pass for the master 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.
Deploying to staging
The last step in our staging deployment is calling the URL of our staging site to make sure it started successfully. This has saved us twice over the last years, as we would have pushed a change to our unicorn configuration that broke the server. Wget and its retry capabilitiesmake sure the website is up and running.
Deploying to production
Then we run our migrations in a separate step after the deployment and clear our cache.
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
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.
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.
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads