Continuous Delivery: The Right Way to Deploy Your Software

This article was sponsored by Codeship. Thank you for supporting the sponsors who make SitePoint possible! How do you deploy your web site or application to your live server? Does this process sound familiar?

1. Get a copy of the latest codebase
2. Add, edit and remove code as necessary
3. Test the update
4. Copy all/changed files to the server using FTP
5. Rinse and repeat

It’s a simple workflow used by many developers. A proportion of developers will also manage updates without source control such as Git or SVN. The process may be good enough for small projects with infrequent updates. Unfortunately, it breaks down the moment your site or application reaches any level of complexity.

Problems With a Traditional Workflow

1. Testing is not robust

Is your local system an exact match for your server environment?

2. It’s error prone

A missed file or failure to update a database record could bring down the whole application.

3. You’re deploying to a live system

Users could encounter access issues even when the process is successfully completed within a few minutes. Would Amazon, Gmail, Facebook or Twitter users put up with frequent unreliability?

4. It’s difficult to revert back

Your mistakes are live; undoing the changes is not always easy, even if you’re using source control.

5. Source control may not cover every eventuality

You could lose database data or other assets which aren’t stored as files.

6. It’s not future proof

The workflow will become increasingly difficult as more developers join the project or additional servers are added.

7. Shipping is slower

Manual deployment is painful, so releasing bug fixes and updates is done less often.

8. Development is unpredictable and failure may not be your (direct) fault

A new version of Ruby, Node.js update, framework upgrade or database change on your live server could bring your application to a halt. We rarely consider other software on our stack but even an operating system or infrastructure update could be risky. Do you avoid updates to minimize the hazards despite the speed, stability and security benefits they bring?

The main problem: the process is laborious

You could be doing far more productive work. Why should you endure manual updates when software and services can complete the tedious tasks for you? You may already be using build tools such as Grunt, Gulp, make or Rake — so why not complete your workflow process with automated continuous delivery?

Continuous Delivery in a Nutshell

Continuous Delivery allows you and your team members to rapidly, reliably and repeatedly deploy fixes, enhancements and new features to your live server. The aim is to reduce risk and manual intervention. You’ll also encounter the term Continuous Integration which refers to the test-driven development part of this process. That said, the two terms are often used interchangeably. Continuous Delivery can be imagined as a deployment pipeline through which software flows from developers to the live server. The flow can be stemmed if any person or system notices a critical error. The process generally follows these steps although policies will differ from team to team:

1. A developer writes automated software tests and code before testing and validating their updates locally. Any number of developers could be working on different updates, each having created their own branch of the current application.
2. The branch is pushed to a central version control repository such as GitHub or BitBucket. Typically, this results in a pull request which can be reviewed by another developer before being merged into the main software branch.
3. The Continuous Delivery system automatically pulls the updated software, runs build processes and executes automated tests again. This happens on a staging server which has an identical environment to the live server. Developers are notified if any failures occur.
4. Additional user acceptance testing and evaluation can now be performed on the staging server by the product owners and/or clients.
5. On final approval, all changes are deployed to the live server quickly and painlessly, without any effort from the developer.

Continuous Delivery is often used in agile development environments but you can adopt it regardless of the processes you use. The process comes with a host of benefits:

• The deployment process is robust. You’ll have confidence that an update will work before it’s installed on the live server.
• There are fewer risks. The process is less prone to human error and, in the event of catastrophic failure, you can roll back the application to a working state.
• Quality control is maintained. Only approved code should be put live.
• Your team becomes more productive and development costs are reduced. The initial set-up time investment will be repaid within a matter of days now that developers do not need to be involved in manual deployment processes.

But the benefits of Continuous Delivery are significantly greater when you don’t need to manage the software yourself.

Automated Continuous Delivery Services

Installing, configuring and managing a suite of Continuous Delivery software products can be daunting, time-consuming and expensive, with some products being difficult to work with. While apps and services like Slack, Crashlytics and Pusher make other developer tasks simpler, others are doing the same for Continuous Delivery. One such example is Codeship, a UX-focused product that can take care of the Continuous Delivery process for you. Their systems are designed to be user-friendly, but you can get assistance and advice from a real person should you require it. The average set-up time? Four minutes. That’s quicker than a single FTP session and you need only do it once! They also have a free plan, offering up to five private projects and 100 builds per month. To learn a bit more about Continuous Delivery, Codeship offers a five-day email “crash course” on the subject — there’s a link to sign up at the bottom-left of their homepage. Continuous Delivery is a great way to leave the drudgery of FTP deployment behind, hopefully forever, and worth investigating. Have you given Continuous Delivery a try? What are your tips for managing deployment?

Frequently Asked Questions on Continuous Delivery and Software Deployment