Every change should trigger the feedback process.
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation is a book that popularized continuous delivery and deployment practices from 2010 by Jez Humble and David Farley. The book is about automating the build, tests, and deployment process. The book is more focused on why we should automate and not that much on technology. That's why it is as relevant today, as it was when it was published (if not more).
The book is for Developers as well as DevOps. Developers must understand the deployment process and hosting, all intertwined with code writing. DevOps needs to understand the process required when writing code, such as fast feedback. Come to think of it, this book is for QA, too. QA must understand that the testing process never ends, even when the code is in production. If testing is left to the end, it will almost certainly be too late.
In Software, when something is painful, the way to reduce the pain is to do it more frequently, not less.
Personal experience with Continuous Delivery
It should be possible for a new team member to sit down at a new workstation, check out the project's revision control repository, and run a single command to build and deploy the application to any accessible environment, including the local development workstation.
Interestingly, continuous delivery ideas came to me fairly early in my software career because I worked in (web-based) startups. At that time, there was no need to consult management, marketing, etc., about what and when features would be deployed. It was simpler times, and much less profitable times (maybe those pesky managers know something developers don't). We did not have a name for our process, but we did publish features as soon as they were finished, without any schedule. Releases to production were not automated but were frequent, sometimes several times a day. It was not something we thought about; it was just logical - when you finish something, publish it immediately! The idea of having a major release would be too troublesome; you would have to track what has been done and then there would be many things to test. Why would you want to do that!?
When I started working in a traditional corporation, I was confused by the complexity of releases. It took several months to see your code and features in production. When I asked, "Why?" I was told it is "too complex" and that I no longer work on "simple applications"; we need "proper testing." The funny thing is that we actually wrote unit and integration tests on our "simple applications", but the "complex applications" had none.
Now, I have a much stronger stance. I believe continuous delivery is the only "proper way" to do the software. From my perspective, having a big bang release has always been an unnatural way of doing software. When you have taken time to properly set up a development environment, including builds, running tests, etc. writing code is a fantastic experience! To be able to write code and tests and not think about anything else is a dream for every developer. Whatever you finish, even partially, you deploy to production. And, it just works! (Most of the time.)
Conclusion
There is no "80% done."
I loved the book, but I have not learned a lot.
I was already sold on the idea of Continuous Delivery because, as someone who loves automating and running tests, this was the logical next step -> automate everything. When I read the book, I already had a lot of experience with continuous delivery and the authors through their other books, YouTube channels, and lectures. The book was everything I had expected it to be. However, I may have a few blindspots regarding the book because I was familiar with the authors' work.
Although it's unreasonable to check your operating system into version control, it's certainly not unreasonable to version-control its configuration.
- Forecasting the Docker?
The book may be "old," but the core ideas are still relevant, and some of them, I would say, are prophetic. Keep in mind that the book is a few years older than Terraform, Docker, and Kubernetes, tools that are very often used with modern continuous delivery setups, and still, the book explains the concepts and ideas behind these new tools reasonably well.
Some are somewhat disappointed with the book: not enough examples, not enough graphs, not enough specifics and technology talks, etc. That may be true, but I have never seen this book as a complete solution for my Continuous Delivery journey, but a step in the right direction.
Unfortunately, even almost 15 years later, we still do not follow these ideas nearly enough. Most software companies have the same problems, even with much better build tools, infrastructure such as code (IaC), Cloud offerings, etc., that they still, deploy manually with evergrowing checklists.
Authors
Jez Humble
Jez Humble is a prominent speaker and author known for his work on continuous delivery and DevOps.
Some of Jez Humble's presentations:
Other Books:
- Lean Enterprise: How High Performance Organizations Innovate at Scale
- The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations
David Farley
Dave Farley is a software engineer and consultant with extensive experience in continuous delivery. He is one of the most prominent "old school" developers with a popular active YouTube channel. He talks mainly about continuous delivery but covers various other software topics. He frequently has famous developer guests.
- YouTube Channel: Continuous Delivery
- Other Books:
- Modern Software Engineering: Doing What Works to Build Better Software Faster