Reliable Software Releases through Build, Test, and Deployment Automation
Although I read a lot, this is my first book review for my blog. I had to write plenty of reviews in school, but I don’t count them since I had little interest in those books. This review is different— I was genuinely interested in the book I read.
Why did I buy this book?
I worked at a software company with a manual delivery process. I was responsible for getting product updates to customers and our support team whenever there was a hotfix or other software change. Updates happened frequently, at a minimum every two weeks.
After the build agents dropped the assemblies in a specific location, updating the test systems, testing, and packaging everything to ship to the customer was my task. I was hired for two roles: release engineer (to ship updates on time) and tester. Unfortunately, shipping all those updates kept me extremely busy, leaving little time for testing— thanks to the overall manual process.
I wanted a solution to free up time and improve delivery quality. I looked at many books: some on application lifecycle management, others on process. None tied everything together in a hands-on way. Until…
The book Continuous Delivery by Jez Humble and David Farley did exactly that. It explained the big picture and went into enough detail to give a clear, concise view of the topic.
What is it all about?
In an earlier draft of this post I summarized the content in several paragraphs; I’ve removed that summary. Many sources already explain the book’s contents in detail. My focus here is on sharing my personal experience rather than repeating those summaries.
Check those pages for a complete table of contents and more information, but don’t forget to come back here.
- The official site of the book
- The publisher’s site of the book
- Table of contents at Safari Books
- The book on Amazon
What were my key learnings?
If I had to pick three highlights from the book, these would be them— and I ’ll explain why. Thanks to the publisher for allowing me to use these illustrations.
(By the way, the publisher currently has a promotion on many of their best-selling agile books— check it out.)
The first illustration shows a deployment pipeline from a process perspective. It visualizes where software changes are at a given time and their health. By looking at that diagram, a release manager can immediately assess the potential scope and quality of upcoming deliveries.
The term “deployment pipeline” raises questions: How does it look? How does it work? What do I need to build one? The image below answers several of those questions— pictures often say more than words.
You can actually read the whole chapter 5, “Anatomy of the Deployment Pipeline,” for free. Cool!
“Where do you come from, where are you now and where are you going” could be a title for the table below. It helped me understand my current situation and where to focus.
| 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. Reuse of scripts and tools. | Fully automated, self-service, push-button process for deploying software. Same process to deploy to every environment. | Change management and approval 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 recreated from source control using automated processes. | 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. |
As a side note, I also found a helpful gist that points you in the right direction.
Conclusion
This book widened my perspective as a software engineer: the work doesn’t end at check-in. Software may never be truly finished, but the most important moment is when the client signs off with a smile.
As a release engineer, the book showed me how to keep processes efficient and reduce risk from the start. Manual steps introduce risk at every stage. I want to use my creativity and energy to solve unique problems and deliver great software— not for repetitive manual work.
All in all, this was the most useful book I ‘ve read lately. Thanks to the authors for writing it and for the impact it had on my professional life and perspective.
Done for today!