Book Review: Continuous Delivery
Reliable Software Releases through Build, Test, and Deployment Automation #
Although I am reading a lot, this is my very first book review for my blog. Of course, I had to do plenty reviews in school, but I don’t count them, since I had little interest in most of those books. In contrast to the book I have read lately and am reviewing in this post.
Why did I buy this book? #
I was working at a software company that had a manual delivery process. I was responsible to get the product updates out to the customer and our support team whenever there was a hotfix or software change in general. Those updates happened quite often, but at a minimum of every two weeks.
After the build agents dropped the assemblies in a specific location, updating the test systems, testing and packaging everything up to ship to the customer was my task. I was hired to fulfill two roles. As a release-engineer I was responsible to ship updates in a timely manner. Additionally, I was hired as a tester. Unfortunately, shipping all those updates kept me busy as hell, leaving no time for tests. Thanks to an overall manual process.
I was looking for a solution, to free up time and to increase the quality of our deliveries. I was looking at many books. One that was supposed to clarify the whole application lifecycle management, others were more of a process related nature, but not a single one put all the bricks together in a hands-on manner. Until …
The book “Continuous Delivery” by Jez Humble and David Farley put everything together. It explained the big picture but also went into the details to deliver a clear and concise picture of the topic.
What is it all about? #
Actually, in an early version of this post, I was summarizing the content in several paragraphs. As you see, they are gone by now. There are dozens of pages out there that will give you a good picture of what is in that book. My focus is not on repeating all this, but more on communicating my own personal experience.
Check out those pages for a complete table of content and more information, but don’t forget to come back here.
- The official site of the book
- The publishers site of the book
- Nice table of contents at Safaribooks
- The book on Amazon
What were my key learnings? #
If I could choose three pieces from the book, the following three would be them and I will explain why. Thanks to the publisher that allowed me to use them here.
By the way, the publisher currently has a special promotion of many of their best-selling agile books, check it out.
The first picture that I have chosen shows a deployment pipeline from process perspective. It visualizes where all those little software changes are at a certain point in time and their health. By looking at that picture, a release manager can immediately determine the potential scope and quality of upcoming deliveries.
The term “deployment pipeline” brings up a lot of questions. How does it look like? How does it work? What do I need to build one? The below picture answers several of those questions. Yeah right, pictures say more than words.
Actually, you can have the whole chapter 5 of the book, called “Anatomy of the Deployment Pipeline”, for free. Cool thing!
“Where do you come from, where are you now and where are you going” could be a title for table below. It really helped me to understand in what situation I am in and to where I have to focus on.
| Practice | Build management and continuous integration | Environments and deployment | Release management and compliance | Testing | Data management | Configuration management |
|---|---|---|---|---|---|---|
| Level 3 - Optimizing: Focus on process improvement | Teams regularly meet to discuss integration problems and resolve them with automation, faster feedback, and better visibility. | All environments managed effectively. Provisioning fully automated. Virtualization used if applicable. | Operations and delivery teams regularly collaborate to manage risks and reduce cycle time. | Production rollbacks rare. Defects found and fixed immediately. | Release to release feedback loop of database performance and deployment process. | Regular validation that CM policy supports effective collaboration, rapid development, and auditable change management processes. |
| Level 2 - Quantitatively managed: Process measured and controlled | Build metrics gathered, made visible, and acted on. Builds are not left broken. | Orchestrated deployments managed. Release and rollback processes tested. | Environment and application health monitored and proactively managed. Cycle time monitored. | Quality metrics and trends tracked. Non functional requirements defined and measured. | Database upgrades and rollbacks tested with every deployment. Database performance monitored and optimized. | Developers check in to mainline at least once a day. Branching only used for releases. |
| Level 1 - Consistent: Automated processes applied across whole application lifecycle | Automated build and test cycle every time a change is committed. Dependencies managed. Re-use of scripts and tools. | Fully automated, self-service, push-button process for deploying software. Same process to deploy to every environment. | Change management and approvals processes defined and enforced. Regulatory and compliance conditions met. | Automated unit and acceptance tests, the latter written with testers. Testing part of development process. | Database changes performed automatically as part of deployment process. | Libraries and dependencies managed. Version control usage policies determined by change management process. |
| Level 0 - Repeatable: Process documented and partly automated | Regular automated build and testing. Any build can be re-created from source control using automated process. | Automated deployment to some environments. Creation of new environments is cheap. All configuration externalized / versioned. | Painful and infrequent, but reliable, releases. Limited traceability from requirements to release. | Automated tests written as part of story development. | Changes to databases done with automated scripts versioned with application. | Version control in use for everything required to recreate software: source code, configuration, build and deploy scripts, data migrations. |
| Level -1 - Regressive: Processes unrepeatable, poorly controlled, and reactive | Manual processes for building software. No management of artifacts and reports. | Manual process for deploying software. Environment-specific binaries. Environments provisioned manually. | Infrequent and unreliable releases. | Manual testing after development. | Data migration unversioned and performed manually. | Version control either not used, or check-ins happen infrequently. |
By the way, as a side note, I have also found a nice gist that also helps you driving into the right direction.
Conclusion #
This book widened my horizon as a software engineer that the world does not end after checking in the code. You could say, that software is never finished, but the most important step is when the client signs it off with a happy smile on his face.
In the role of a release engineer it showed me how to keep things efficient and reduce risk right from the start. Manual processes introduce risk with every step one has to do. I want to use my creativity and energy to solve a unique problem and deliver cool software, not for doing monkey work.
All in all, this was the most useful book that I have read lately. Thanks to the authors for writing it, for creating such an impact on my professional life and aligning my own perspective to this highly important topic.
Done for today!