A book review of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Buy it now
One Minute Bottom Line
A must read for anyone who has to deploy or manage software deployments, especially those struggling with semi-automated or human controlled deployments. This book will save you time, reduce risk, improve trust and communication between project stakeholders and team members, and help you deliver better quality software to your clients
They say you never get a second chance to make a first impression, and this book’s hardcover binding makes a great first impression. When was the last time you saw a hardcover computer book, especially one with less than 500 pages? They also say not to judge a book by its cover, and this book’s value is far more than skin deep. Implementing continuous delivery will save you time, reduce risk, improve communication between project stakeholders and team members, and help you deliver better quality software to your clients.
Several ideas from this book really struck a chord with me smoke tests, configuration management and automated rollback procedures among them, most because they addressed problems I have experienced in the past. Have you ever deployed a web application, called up the main (static) page in a browser and seeing nothing wrong released it to production, but within minutes received a slew of calls saying it is broken? You start debugging in your head. Maybe the database or cache is down? Did someone make a configuration change (without your knowledge) that breaks your code or one of its dependencies (e.g. changed the location of the mail server)? What version of MS Office are they using? Did they get a new machine and not reinstall the barcode font? You then need to make a decision (without all of the facts) on whether to roll back the changes or not. As you can imagine this does not help to build trust and confidence in you or your code. This book includes several ideas which can help avoid these types of problems with your deployments.
Smoke testing is the idea of running a strategic subset of your existing test suite to insure that the system is working as you intended. Can it read and write from the database? Can it generate an email? Is it using the latest database schema? This single idea can go a long way to engendering trust in you and your software. In most cases a cancelled deployment is a lot easier to handle than a rollback, both from the client’s perspective and from a technology standpoint (e.g. how do you rollback the changes to the database’s schema and data).
The concept of automatic deployments is a complex one and the need to account for automated rollbacks may be the hardest part. How do you roll back changes to the data or to your database’s schema? The authors did a fantastic job of not only acknowledging the problems this can present, but of providing a range of possible solutions. While there may be times where no perfect solution exists, the authors give you the knowledge to make an informed well reasoned choice.
I also like the idea of treating the system configuration as part of the application, including versioning it. As the authors point out given access to the systems configuration they could bork an application even easier than if they had access to the code. While this topic, among several others in the book, could warrant a book of their own (and has <a href="http://www.amazon.com/Configuration-Management-Best-Practices-Practical/dp/0321685865/ref=sr_1_1?ie=UTF8&qid=1289158886&sr=8-1">Configuration Management</a>). I appreciate the authors’ inclusion of these related topics –they allow me to see the complete picture. Like many concepts continuous delivery touches many other development and operational topics. As someone who usually has no access to the machines where my code runs I haven’t always paid as much attention to this concern as perhaps I should have. I have been guilty of tossing my code over the wall and arguing that it works on my machine. I now have a better understanding of this issue, and the challenges faced by the operations teams with which I work. Again, these are the kinds of things that improve communication, efficiency, trust and end user satisfaction.
The only criticism I have of the book is that I found it a little redundant – especially the early chapters. Where the authors layout the foundation of a continuous deployment system and describe each component. This had nothing to do with the authors’ writing style or the book’s content, but rather was the result of them preaching to the choir or as Renee Zellwegger might say they had me “at hello.” As a one man consulting shop i don’t have a lot of bureaucracy or corporate hierarchy to convince when adopting new ideas. But I can see the value of the author’s well argued reasoning for those who are trying to introduce the concept of continuous deployment either from the top down or bottom up.
Some will argue that the author’s approach of describing what a continuous delivery system should accomplish, but not including a fully working example with code samples, easy to follow recipes and tool chain is a significant flaw. I disagree; which language would you choose Java, C#, C++, Ruby, PHP. The concept of continuous delivery and its’ benefits are language, tool chain and architecture agnostic.
This book is full of small, often deceptively simple, ideas that together are far more than the sum of their parts. As a result it is a book that you refer back to regularly as you implement each new component smoke tests, automated functional acceptance testing, pushbutton deployments to testing and production environments etc. As a result the choice of a hardcover binding was one of form follows function, and will keep the book in good shape for years to come.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)