Continuous Delivery

Recently I read Continuous Delivery by Jez Humble and David Farley. Authors have gone to lengths to describe the benefits and best practices for continuous delivery and how to create a setup around continuous delivery with respect to configuration management, testing strategy, deployment pipeline and finally infrastructure and environments management. While continuous integration (CI) is about integrating finished code into existing stable code base, continuous delivery (CD) is about deploying working software into production environment regularly. Some of the key takeaways mentioned under software delivery principles are:

1. Create a repeatable, reliable process for releasing software.
2. Automate almost everything.
3. Keep every thing in version control.
4. If it hurts, do it more frequently, and bring the pain forward.
5. Build quality in.
6. Done mean released.

On continuous integration (CI), authors suggest that it represents a paradigm shift. Without CI, software is broken until proven that it works, which is usually during a more formal testing phase. With CI, software if proven to work with every new change where entire application is built and tested with comprehensive set to automated tests cases. CI essentially is two step process:

1. Compile the software, run suite of unit test cases and create a deployable binary which is termed as the ‘commit’ stage.
2. Take binary from previous step and run acceptance / integration / performance tests.

Here the meaning of ‘build quality in’ comes in where build process itself can be made more comprehensive to take care of test coverage, code duplication, adherence to coding standards, cyclomatic complexity, and other health indicators. Some best practices hav been mentioned for CI such as:

1. Never to check in on a broken build.
2. Always run all commit tests locally first.
3. Wait for commit tests to pass before moving on.
4. Time-box fixing before reverting to last known good build.
5. Last but not least, bring visibility into the release process for the entire team.

There is reference to ‘Continuous Integration on a Dollar a Day’ which is quite helpful if one wants to quick start on CI.

A deployment pipeline has been defined as automated manifestation of the process of getting software from version control to end users. This can be looked at here.

Some of the deployment pipeline best practices mentioned in the book are:

1. Build binaries only once.
2. Deploy the same way to every environment.
3. Smoke test deployments.
4. Deploy into a copy of production.
5. Each change should propagate quickly thought the pipeline.
6. If any part of the pipeline fails, stop the line.

Besides these, authors have also covered other topics such as testing strategy, infrastructure and environment management, advanced version control etc. in detail.

Related to this topic is the concept of ‘daily build and smoke test’. Although continuous delivery doesn’t necessarily mean to have this practice of daily (or nightly) builds, however the intent is same. As put by Jim McCarthy in his book Dynamics of Software Development, if just one thing that Microsoft has to contribute to the world in terms of software development, it is the practice of daily build and smoke test which should be treated like heartbeat of the project. If there is no heartbeat, the project is dead. Daily builds are good way to enforce discipline in the projects for that matter.

I have yet to see all such principles applied in one project elegantly.

Overall a good and definitive read on this topic.