Sunday, April 5, 2015

Continuous Delivery vs. Continuous Deployment

A Typical Manual Release Process

Let's say we had a process where the development team was branching, writing unit tests, committing code, and then merging into a mainline trunk. Once a week, they'd cut a release candidate branch off of develop and hand off to QA. After QA sign-off, the features could then be released into staging for post-release testing, before being deployed to production.

Prerequisites: Read up on Continuous Integration, CI with Travis, and this merge-based release strategy.

Now, you'll find a lot of manual steps from what I've described as a fairly linear workflow. That's on a good day. Most days, you're going to be compensating for bugfixes, patches, failing tests- each one of these adding to multiple points of failure that delay the launch and negatively impact morale. So how do you address some of these pain points?

The short answer is deploy early and often, and automate as much of the process as possible. If this sounds similar to you, it's very close to the same mantra that Continuous Integration encourages- test early, test often.

With Continuous Delivery, you're ensuring the following:

  • A proven ability to deliver software to any given environment, at any given time, as needed
  • A delivery system to maintain, not a set of manual steps to execute
  • More time for developers to allocate towards developing features and bugfixes

Speaking of bugs, Continuous Delivery allows you to diagnose them in a shorter amount of time. Not just deployment bugs, but problems with the software, itself. To understand how, it helps to take a step back and look at all the different environments your software will run on. Take a look at the following table and the users that are impacted at each stage of the release pipeline.

Environment User Description
Local Developer Developer's local machine
Development Developer Sandbox server for bleeding-edge technology and experimentation. This can exists on a separate server instance or on the local machine, as long as the developer has access to all of the necessary dependencies.
Integration Developer An environment for integration tests to run, ensuring that all current releases are compatible with each other.
Test / QA QA For functional tests, regression tests, benchmarking, and general QA.
UAT Internal End User User acceptance testing environment to act as a final verification of the business requirements and needs of the end user.
Staging Internal End User A mirror of the production environment, provided to ensure that potential production issues are caught early.
Production / Live External End User The environment that serves the product directly to the customer / end user.

Now, to run on all of these environments in a way that makes sense, your software has to be built with different configurations. In the development environment, you're running the application against the source code and are most likely hitting an API that returns mock data. For the QA environment, you have to cut a release candidate and provide a way for QA to test not only the software but its integration with all services. And finally for staging and production, you've built and tagged a release. Continuous Delivery allows you easily configure / provision the software for each environment so that when a bug is found in the in production you can quickly reproduce the issue, in a more controlled environment.

The system executes on the following:

  • Provision the environment which has the same version of the software
  • Reset that environment to more accurately represent the production environment
  • Deploy the software and then jump right into testing

"Continuous Delivery process diagram" by Jez Humble - http://continuousdelivery.com/2010/02/continuous-delivery/. Licensed under CC BY-SA 1.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Continuous_Delivery_process_diagram.png#/media/File:Continuous_Delivery_process_diagram.png

Continuous Deployment

Now, you may have heard of another term known as "Continuous Deployment". This is often confused with Continuous Delivery. The key difference is small, but critical[1]. Continuous Delivery means you have the capacity to deploy changes at any time, whereas Continuous Deployment means every change that passes the automated tests is deployed to production automatically.

Unlike Continuous Delivery, this system is completely automated from commit to production and may not be right for every company.

References:


No comments:

Post a Comment