What do you think?
Rate this book
Martin Fowler Signature Book
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Winner of the 2011 Jolt Excellence Award! Getting software released to users is often a painful, risky, and time-consuming process.
This groundbreaking new book sets out the principles and technical practices that enable
rapid, incremental delivery of high quality, valuable new functionality to users. Through
automation of the build, deployment, and testing process, and improved collaboration between
developers, testers, and operations, delivery teams can get changes released in a matter of hours—
sometimes even minutes–no matter what the size of a project or the complexity of its code base.
Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-risk
delivery process. Next, they introduce the “deployment pipeline,” an automated process for
managing all changes, from check-in to release. Finally, they discuss the “ecosystem” needed to
support continuous delivery, from infrastructure, data and configuration management to governance.
The authors introduce state-of-the-art techniques, including automated infrastructure management
and data migration, and the use of virtualization. For each, they review key issues, identify best
practices, and demonstrate how to mitigate risks. Coverage includes
• Automating all facets of building, integrating, testing, and deploying software
• Implementing deployment pipelines at team and organizational levels
• Improving collaboration between developers, testers, and operations
• Developing features incrementally on large and distributed teams
• Implementing an effective configuration management strategy
• Automating acceptance testing, from analysis to implementation
• Testing capacity and other non-functional requirements
• Implementing continuous deployment and zero-downtime releases
• Managing infrastructure, data, components and dependencies
• Navigating risk management, compliance, and auditing
Whether you’re a developer, systems administrator, tester, or manager, this book will help your
organization move from idea to release faster than ever—so you can deliver value to your business
rapidly and reliably.
This groundbreaking new book sets out the principles and technical practices that enable
rapid, incremental delivery of high quality, valuable new functionality to users. Through
automation of the build, deployment, and testing process, and improved collaboration between
developers, testers, and operations, delivery teams can get changes released in a matter of hours—
sometimes even minutes–no matter what the size of a project or the complexity of its code base.
Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-risk
delivery process. Next, they introduce the “deployment pipeline,” an automated process for
managing all changes, from check-in to release. Finally, they discuss the “ecosystem” needed to
support continuous delivery, from infrastructure, data and configuration management to governance.
The authors introduce state-of-the-art techniques, including automated infrastructure management
and data migration, and the use of virtualization. For each, they review key issues, identify best
practices, and demonstrate how to mitigate risks. Coverage includes
• Automating all facets of building, integrating, testing, and deploying software
• Implementing deployment pipelines at team and organizational levels
• Improving collaboration between developers, testers, and operations
• Developing features incrementally on large and distributed teams
• Implementing an effective configuration management strategy
• Automating acceptance testing, from analysis to implementation
• Testing capacity and other non-functional requirements
• Implementing continuous deployment and zero-downtime releases
• Managing infrastructure, data, components and dependencies
• Navigating risk management, compliance, and auditing
Whether you’re a developer, systems administrator, tester, or manager, this book will help your
organization move from idea to release faster than ever—so you can deliver value to your business
rapidly and reliably.
484 pages, Kindle Edition
First published July 27, 2010
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 166 reviews
July 21, 2014
I'm a bit torn on this book: on the one hand, it is a very thorough look at a number of important, but often overlooked topics; on the other hand, the book is not a very effective teacher of this important material. The biggest problem is the lack of real world examples. Chapters are mostly huge blocks of advice: the advice is good, but not memorable or actionable in the way it is presented. There need to be far more examples of real world systems with both good approaches and bad approaches discussed and compared in detail.
Moreover, the book is very very repetitive. Perhaps it's from an attempt to make each chapter standalone, but while trying to find the new and interesting info in a new chapter, you have to wade through tons of info you read many times in earlier chapters (or even earlier paragraphs). There are many sentences, paragraphs, and even pages that can be skipped because they are obvious or just a rehash of something earlier (or both).
In short, this is a VERY important - perhaps even required - read for anyone working on medium and large software projects, but this book desperately needs a tldr companion with lots of examples.
A few good quotes from the book:
If It Hurts, Do It More Frequently, and Bring the Pain Forward
Done Means Released
In our experience, it is an enduring myth that configuration information is somehow less risky to change than source code.
Without continuous integration, your software is broken until somebody proves it works, usually during a testing or integration stage. With continuous integration, your software is proven to work (assuming a sufficiently comprehensive set of automated tests) with every new change—and you know the moment it breaks and can fix it immediately.
For the software delivery process, the most important global metric is cycle time. This is the time between deciding that a feature needs to be implemented and having that feature released to users. As Mary Poppendieck asks, “How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?”
Errors are easiest to fix if they are detected early, close to the point where they were introduced.
To paraphrase, performance is a measure of the time taken to process a single transaction, and can be measured either in isolation or under load. Throughput is the number of transactions a system can process in a given timespan. It is always limited by some bottleneck in the system. The maximum throughput a system can sustain, for a given workload, while maintaining an acceptable response time for each individual request, is its capacity. Customers are usually interested in throughput or capacity.
When we talk about components, we mean a reasonably large-scale code structure within an application, with a well-defined API, that could potentially be swapped out for another implementation. A component-based software system is distinguished by the fact that the codebase is divided into discrete pieces that provide behavior through well-defined, limited interactions with other components.
Moreover, the book is very very repetitive. Perhaps it's from an attempt to make each chapter standalone, but while trying to find the new and interesting info in a new chapter, you have to wade through tons of info you read many times in earlier chapters (or even earlier paragraphs). There are many sentences, paragraphs, and even pages that can be skipped because they are obvious or just a rehash of something earlier (or both).
In short, this is a VERY important - perhaps even required - read for anyone working on medium and large software projects, but this book desperately needs a tldr companion with lots of examples.
A few good quotes from the book:
If It Hurts, Do It More Frequently, and Bring the Pain Forward
Done Means Released
In our experience, it is an enduring myth that configuration information is somehow less risky to change than source code.
Without continuous integration, your software is broken until somebody proves it works, usually during a testing or integration stage. With continuous integration, your software is proven to work (assuming a sufficiently comprehensive set of automated tests) with every new change—and you know the moment it breaks and can fix it immediately.
For the software delivery process, the most important global metric is cycle time. This is the time between deciding that a feature needs to be implemented and having that feature released to users. As Mary Poppendieck asks, “How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?”
Errors are easiest to fix if they are detected early, close to the point where they were introduced.
To paraphrase, performance is a measure of the time taken to process a single transaction, and can be measured either in isolation or under load. Throughput is the number of transactions a system can process in a given timespan. It is always limited by some bottleneck in the system. The maximum throughput a system can sustain, for a given workload, while maintaining an acceptable response time for each individual request, is its capacity. Customers are usually interested in throughput or capacity.
When we talk about components, we mean a reasonably large-scale code structure within an application, with a well-defined API, that could potentially be swapped out for another implementation. A component-based software system is distinguished by the fact that the codebase is divided into discrete pieces that provide behavior through well-defined, limited interactions with other components.
November 18, 2013
This is the best book about Deployment I've read so far.
Filled with lots of good advice for improvement and automation of a deployment process.
I loved the concepts about deployments with no downtime and also found their maturity model a good guideline for improvement.
I definitely recommend the reading for software development folks.
Filled with lots of good advice for improvement and automation of a deployment process.
I loved the concepts about deployments with no downtime and also found their maturity model a good guideline for improvement.
I definitely recommend the reading for software development folks.
Read
October 25, 2019Must-read for every dev.
June 14, 2017
This book is considered a cornerstone of the DevOps movement. In my opinion, it might be that in the very beginning, but currently most of the concepts that it presents are obvious and outdated.
I will recommend it to be read to someone who's new in the DevOps community, but if you've got a few years of experience in the area under your belt I would not.
It's nice to have all good concepts under one cover, but reading a 400-pages long book that will tell you the history of GIT and SVN is pointless in my opinion. Most of the ideas presented in the book could be wrapped in one long yet succinct blog post.
My score 3/5
I will recommend it to be read to someone who's new in the DevOps community, but if you've got a few years of experience in the area under your belt I would not.
It's nice to have all good concepts under one cover, but reading a 400-pages long book that will tell you the history of GIT and SVN is pointless in my opinion. Most of the ideas presented in the book could be wrapped in one long yet succinct blog post.
My score 3/5
February 19, 2013
It IS a very good book and its content is essential for anyone interested in CI / mature devops processes. Why just 4 starst then? It's faaar too wordy - you could easily put the same content (in terms of meaningful information) in less pages. I just could not get rid of a feeling that I'm reading the same sentences for hundredth time... But regardless of that, this is A-MUST-READ for anyone deeplyn involved in producing professional software on enterprise level.
April 21, 2023
Accelerate kitabında da “High performance organization and system” için en önemli adım olarak “deployment pipeline” - “devops” süreçleri ele alınır. Şu elimde görmüş olduğunuz 2010 basımı kitap, evet yanlış duymadınız 2010 bas��mı kitap, bugün hala geçerli olan, “Continuous Delivery“ süreçlerini şahane bir şekilde işlemektedir. Neredeyse 5 yılda bir tüm teknoloji baştan değiştiğini göz önünde bulundurduğumuzda, teorik altyapısının ne kadar kuvvetli olduğu sanırım daha net anlaşılacaktır kitabın. Zamansız kitapları seviyorum. Pratiğini nasıl icra edeceğin sana, o günün teknolojilerine kalmış olsa da işin özü, felsefesi değişmeyecek. Sadece 5 yılda bir popüler olan markalar & anahtar sözcükler değişecek. Ama yine bu işin mantığını bilmeyen, anlamayan sadece modanın peşinde koşanlar yine yalan yanlış uygulayıp boku teknolojisine atacaklar. Accelerate’de de üzerinde durulan sürekli gelişim bu 5 yıl muhebbetini de kıracak bir tutum oluşturacaktır. Burada da önemli vurgulanmaktadır “Continuous improvement”. (Son bölümde anlatılan “Maturity Model”de kendinin organizasyonun nerede olduğunun farkına varmak için faydalı.)
Kitabı devops’lara tavsiye etsem mi? Kitap devops’un, garibimin tek başına altından kalkacağı bir resim çizmiyor. Yani al oku şunu da bizi uçur gibi bir durum yok. En kral süreci de kursan önemli olan bunu kimlerin nasıl uyguladığı. İş clean code, tdd, hexagonal, microservice pattern, acceptance test, continuous integration, lean management, team topology gibi yapılara çıkıyor. Bunları birlikte ele almayınca ferrari’ye lpg takıp geziyorsun işte. Olan o oluyor, 5 yıl sonra da yeni modele…
Neyse ben “team topologies” ile devam edeyim. Oraya da beklerim…
Not: Yazarlarımızdan Dave Farley youtube kanalında da döktürmekte. Orayı da tavsiye ederim. Çoğu zaman ezber bozuyor.
Kitabı devops’lara tavsiye etsem mi? Kitap devops’un, garibimin tek başına altından kalkacağı bir resim çizmiyor. Yani al oku şunu da bizi uçur gibi bir durum yok. En kral süreci de kursan önemli olan bunu kimlerin nasıl uyguladığı. İş clean code, tdd, hexagonal, microservice pattern, acceptance test, continuous integration, lean management, team topology gibi yapılara çıkıyor. Bunları birlikte ele almayınca ferrari’ye lpg takıp geziyorsun işte. Olan o oluyor, 5 yıl sonra da yeni modele…
Neyse ben “team topologies” ile devam edeyim. Oraya da beklerim…
Not: Yazarlarımızdan Dave Farley youtube kanalında da döktürmekte. Orayı da tavsiye ederim. Çoğu zaman ezber bozuyor.
October 26, 2016
Some years ago, I had the fortune to attend Jes Humble's workshop on continuous delivery. It was a good workshop, well delivered, and I learned a lot.
I was, therefore, surprised that it turned out to be such a struggle to read this book. It's not that I disagree with the contents, but it's so boring!
Each page is mostly a wall of text, with no diagrams, sidebars, illustrations, or even bulleted lists. Even when there's an occasional diagram, it seems strangely unhelpful. While it could be that the material simply doesn't lend itself easily to illustrations, I don't think that's the case.
As an example, on page 354, the authors discuss the diamond dependency problem, but they use only text. If that isn't an opportunity for an illustration, I don't know what is. This particular problem is named after a shape (the diamond shape), so it'd be a simple matter to add an illustration. The opportunity is missed, here, and many other places.
It's not that I'm afraid of books without diagrams; I read lots of fiction. In a textbook that attempts to teach, on the other hand, I think the reader needs all the help (s)he can get to get through dry material. Such help is absent here.
Show, don't tell.
I was, therefore, surprised that it turned out to be such a struggle to read this book. It's not that I disagree with the contents, but it's so boring!
Each page is mostly a wall of text, with no diagrams, sidebars, illustrations, or even bulleted lists. Even when there's an occasional diagram, it seems strangely unhelpful. While it could be that the material simply doesn't lend itself easily to illustrations, I don't think that's the case.
As an example, on page 354, the authors discuss the diamond dependency problem, but they use only text. If that isn't an opportunity for an illustration, I don't know what is. This particular problem is named after a shape (the diamond shape), so it'd be a simple matter to add an illustration. The opportunity is missed, here, and many other places.
It's not that I'm afraid of books without diagrams; I read lots of fiction. In a textbook that attempts to teach, on the other hand, I think the reader needs all the help (s)he can get to get through dry material. Such help is absent here.
Show, don't tell.
February 2, 2015
A very good overview of the topic. Although given it's 500 pages thick, the book could be more specific about dealing with credentials in production environments and data migrations. The companion website is another missed oportunity. Still 4 stars for the lack of a better alternative.
October 20, 2019
It took me almost two years to finish the book, but I am happy that I did it today. 😊
This book is, IMO, the best book about DevOps practices ever. It explains why the best practices are the way they are now and what problems they solve. The book is also a thorough toolbox of everything you need to know about implementing continuous delivery successfully in your own project and company, from deployment automation to configuration management to data management and even to compliance and auditing.
I am so lucky to have it by my side and know that whenever I need know how to do something right in DevOps I can count on it.
This book is, IMO, the best book about DevOps practices ever. It explains why the best practices are the way they are now and what problems they solve. The book is also a thorough toolbox of everything you need to know about implementing continuous delivery successfully in your own project and company, from deployment automation to configuration management to data management and even to compliance and auditing.
I am so lucky to have it by my side and know that whenever I need know how to do something right in DevOps I can count on it.
June 25, 2017
В книге описана методика построения конвейера по доставке изменений от разработчиков к клиенту. Сейчас об этом говорят как о DevOps, небольшой исторический экскурс. Термин DevOps начал активно пиарится с 2009, а книга вышла в 2010. В книге используется термин CI/CD как предтеча DevOps.
Стоит ли ее читать спустя 7 лет после выхода?
Да - если вы занимаетесь процессами, в книге детально описаны именно процессы: процессы доставки изменений, процессы контроля над изменениями, процессы управления зависимостями.
Нет - если вы хотите познакомиться с технологиями. В техническом планет книга безнадежно устарела.
Что еще хочется отметить. Перевод очень тяжелый, книга читается с большим трудом. Через некоторые абзаца и главы просто приходится продираться.
Пройдемся чуть подробнее по частям из которых состоит книга.
В первой части авторы поверхностно рассматривают фундамент для построения конвейера, а именно стратегию управления конфигурациями, непрерывную интеграцию и стратегию тестирования. Несмотря на то, что в первой части много очевидных вещей, именно их игнорирование приводит к проблемам. Авторы предпочитают работать на мастере(магистрале) и не любят активное ветвление.
Во второй части описаны процессы построения конвейера. Описано все достаточно п��дробно, с хорошими примерами почему так надо делать, и к чему приводит не следование этим простым советам. Естественно не обойден процесс тестирования(автоматизированного) и процесс развертывания готового приложения. Приведены несколько стратегий, также даны рекомендации по тому, как надо проектировать приложение для того что бы иметь возможность откатить изменения в случае проблемы. Но повторюсь, эта книга про процессы, а не про конкретные решения.
В заключительной части, авторы рассматривают процессы управления изменениями в данных, в инфраструктуре, в коде, в зависимостях. Авторы ратуют за полное автоматизированное развертывание инфраструктуры, с использованием любых автоматических средств, но с большой ненавистью говорят об и использовании интерфейса пользователя для настройки. Если что то можно положить на версионный контроль, то это надо положить.
Авторы показывают, как можно встроить виртуализацию в конвейер непрерывного развертывания, сейчас, это выглядит вполне разумным и даже обязательным. Тогда это было на самом переднем краю. Процесс управления изменениями данных, на мой взгляд спорен, но он правилен. Всегда должна быть возможность откатить любые изменения. Все остальное в разделе, достаточно банально. Процесс управлениями компонентами и зависимостями, описан просто отлично, со всеми возможными шаблонами и подходами. По разделу видно, что авторы много и долго ходили по граблям. Про управления версиями, добротно, подробно, хотя очень сильно устарело технически. Но, только после прочтения раздела, я осознал всю мощь ClearCase и насколько он серьезный продукт. Шаблонов ветвления авторы приводят, но крайне куце, скажу больше, авторы большие фанаты работы на транке(main для git).
Последняя, 15 глава. На мой взгляд, самая главная. В ней подводится итог всего того, о чем написано в книге и самое главное, что она для процессников. Это глава о процессах и рисках, и о зрелости. Представленная в главе матрица зрелости процессов по CMMI, истинный бриллиант. Да, сейчас она уже немного устарела, но это не умоляет ее ценности. Особо хочу обратить внимание на то, что в модели присутствует уровень -1. Процессы могут деградировать и об этом никогда не стоит забывать. Так же в главе, очень сжато и емко описан жизненный цикл проекта, сравнивается предложенный авторами подход с подходом описанным в ITIL. Что приятно, кратко описано управление рисками. На мой взгляд лучшая глава из всей книги.
Стоит ли ее читать спустя 7 лет после выхода?
Да - если вы занимаетесь процессами, в книге детально описаны именно процессы: процессы доставки изменений, процессы контроля над изменениями, процессы управления зависимостями.
Нет - если вы хотите познакомиться с технологиями. В техническом планет книга безнадежно устарела.
Что еще хочется отметить. Перевод очень тяжелый, книга читается с большим трудом. Через некоторые абзаца и главы просто приходится продираться.
Пройдемся чуть подробнее по частям из которых состоит книга.
В первой части авторы поверхностно рассматривают фундамент для построения конвейера, а именно стратегию управления конфигурациями, непрерывную интеграцию и стратегию тестирования. Несмотря на то, что в первой части много очевидных вещей, именно их игнорирование приводит к проблемам. Авторы предпочитают работать на мастере(магистрале) и не любят активное ветвление.
Во второй части описаны процессы построения конвейера. Описано все достаточно п��дробно, с хорошими примерами почему так надо делать, и к чему приводит не следование этим простым советам. Естественно не обойден процесс тестирования(автоматизированного) и процесс развертывания готового приложения. Приведены несколько стратегий, также даны рекомендации по тому, как надо проектировать приложение для того что бы иметь возможность откатить изменения в случае проблемы. Но повторюсь, эта книга про процессы, а не про конкретные решения.
В заключительной части, авторы рассматривают процессы управления изменениями в данных, в инфраструктуре, в коде, в зависимостях. Авторы ратуют за полное автоматизированное развертывание инфраструктуры, с использованием любых автоматических средств, но с большой ненавистью говорят об и использовании интерфейса пользователя для настройки. Если что то можно положить на версионный контроль, то это надо положить.
Авторы показывают, как можно встроить виртуализацию в конвейер непрерывного развертывания, сейчас, это выглядит вполне разумным и даже обязательным. Тогда это было на самом переднем краю. Процесс управления изменениями данных, на мой взгляд спорен, но он правилен. Всегда должна быть возможность откатить любые изменения. Все остальное в разделе, достаточно банально. Процесс управлениями компонентами и зависимостями, описан просто отлично, со всеми возможными шаблонами и подходами. По разделу видно, что авторы много и долго ходили по граблям. Про управления версиями, добротно, подробно, хотя очень сильно устарело технически. Но, только после прочтения раздела, я осознал всю мощь ClearCase и насколько он серьезный продукт. Шаблонов ветвления авторы приводят, но крайне куце, скажу больше, авторы большие фанаты работы на транке(main для git).
Последняя, 15 глава. На мой взгляд, самая главная. В ней подводится итог всего того, о чем написано в книге и самое главное, что она для процессников. Это глава о процессах и рисках, и о зрелости. Представленная в главе матрица зрелости процессов по CMMI, истинный бриллиант. Да, сейчас она уже немного устарела, но это не умоляет ее ценности. Особо хочу обратить внимание на то, что в модели присутствует уровень -1. Процессы могут деградировать и об этом никогда не стоит забывать. Так же в главе, очень сжато и емко описан жизненный цикл проекта, сравнивается предложенный авторами подход с подходом описанным в ITIL. Что приятно, кратко описано управление рисками. На мой взгляд лучшая глава из всей книги.
September 28, 2012
Technologists operate in a fast-moving environment. Languages rise and fall. Application strategies constantly shift across new hardware. Presentation layers move between thick and thin client across desktop, laptop, tablet, and phone architectures. For that reason, technology writers produce materials that have a relatively short shelf life.
Every now and then, books are published which make a lasting contribution to the field of computer science and software delivery (i.e. Knuth's Art of Computer Programming or Brooks' Mythical Man Month) and find interested readers regularly pulling them off their shelves. Continuous Delivery by Farley and Humble is one such book.
Combining an uncanny vision for emerging technology trends, awareness of available delivery tools, massive experience in the realm of software delivery, and well articulated delivery strategies, the authors offer a relatively vendor-agnostic discussion of the delivery pipeline that ensures code quality, quick time-to-market, and painless release processes.
This book is highly relevant for anyone involved in the field of technology: developers, testers, project managers, scrum masters and product owners, as well as CTO's / CIO's.
Every now and then, books are published which make a lasting contribution to the field of computer science and software delivery (i.e. Knuth's Art of Computer Programming or Brooks' Mythical Man Month) and find interested readers regularly pulling them off their shelves. Continuous Delivery by Farley and Humble is one such book.
Combining an uncanny vision for emerging technology trends, awareness of available delivery tools, massive experience in the realm of software delivery, and well articulated delivery strategies, the authors offer a relatively vendor-agnostic discussion of the delivery pipeline that ensures code quality, quick time-to-market, and painless release processes.
This book is highly relevant for anyone involved in the field of technology: developers, testers, project managers, scrum masters and product owners, as well as CTO's / CIO's.
March 23, 2015
Awesome. 10/10.
January 5, 2024
Well, it took me a bit more time than I expected to read this classic. In the end, I liked it. Nevertheless, I found some aspects that were not perfect.
Let's start with those imperfections:
- The book is too long IMO. I don't deny the massive knowledge it contains but I feel that it could be defragmented and compressed better. I think the reason is absolute lack of any teaching tools and methods. Wall of text everywhere. The diagrams or tables that we can encounter from time to time are mostly not too helpful.
- Some chapters could be shortened or even omitted. I think that quite large introduction to CVS/SVN or packet managers didn't age too well.
- I was missing a little more modern software perspective. Of course I understand the power of patterns and analogies. I also accept the possibility of translating the described solutions (e.g. in the context of components or data) into other technologies and architectures. It would be just sweeter if it was written based on the current tech stack and standards (more cloudy, SaaS and distributed) :)
The strong points:
- It actually covers the whole process of CD - from A to Z. From the technical to the management perspective. Powerful reference sources on this topic.
- The Deployment Pipeline part was really concrete and valuable. Each stage (build, commit, tests, deploy) had its own chapter with a pretty detailed descriptions.
- A strong emphasis and concentration on testing. It's not just a couple of mentions of how testing is important. It's actually a whole essay on how to test, when to do it, how to embed it in pipeline, how to treat test data, how to decompose/unfold tests into different area, GUI tests against API tests etc.
- Touching non-obvious topics like managing data in the Zero-Downtime releases process or developing on mainline in the Version Control System.
One star removed for being a bit outdated. Another star removed for being too verbose. Three stars from me in the end.
Let's start with those imperfections:
- The book is too long IMO. I don't deny the massive knowledge it contains but I feel that it could be defragmented and compressed better. I think the reason is absolute lack of any teaching tools and methods. Wall of text everywhere. The diagrams or tables that we can encounter from time to time are mostly not too helpful.
- Some chapters could be shortened or even omitted. I think that quite large introduction to CVS/SVN or packet managers didn't age too well.
- I was missing a little more modern software perspective. Of course I understand the power of patterns and analogies. I also accept the possibility of translating the described solutions (e.g. in the context of components or data) into other technologies and architectures. It would be just sweeter if it was written based on the current tech stack and standards (more cloudy, SaaS and distributed) :)
The strong points:
- It actually covers the whole process of CD - from A to Z. From the technical to the management perspective. Powerful reference sources on this topic.
- The Deployment Pipeline part was really concrete and valuable. Each stage (build, commit, tests, deploy) had its own chapter with a pretty detailed descriptions.
- A strong emphasis and concentration on testing. It's not just a couple of mentions of how testing is important. It's actually a whole essay on how to test, when to do it, how to embed it in pipeline, how to treat test data, how to decompose/unfold tests into different area, GUI tests against API tests etc.
- Touching non-obvious topics like managing data in the Zero-Downtime releases process or developing on mainline in the Version Control System.
One star removed for being a bit outdated. Another star removed for being too verbose. Three stars from me in the end.
January 14, 2024
"Continuous Delivery" by Jez Humble and Dave Farley is a definitive guide for teams striving to revolutionize their software delivery process. This book skillfully navigates the landscape of continuous delivery, offering a clear roadmap for transforming development into a reliable, efficient, and automated workflow.
The authors, drawing on extensive experience, present a compelling case for continuous delivery and provide practical insights into its implementation. Emphasizing the pivotal role of automation, the book covers every aspect, from continuous integration to deployment, making complex concepts accessible to both novices and experts.
An outstanding feature is the focus on cultural and organizational changes essential for successful adoption. Humble and Farley advocate for collaborative efforts between development and operations teams, underlining shared responsibility for the software lifecycle. Real-world case studies further enrich the content, offering inspiration and practical insights.
In conclusion, "Continuous Delivery" is an indispensable read for anyone in software development. It serves as a guiding light, providing a blueprint for achieving software excellence through reliability, speed, and innovation. Highly recommended.
The authors, drawing on extensive experience, present a compelling case for continuous delivery and provide practical insights into its implementation. Emphasizing the pivotal role of automation, the book covers every aspect, from continuous integration to deployment, making complex concepts accessible to both novices and experts.
An outstanding feature is the focus on cultural and organizational changes essential for successful adoption. Humble and Farley advocate for collaborative efforts between development and operations teams, underlining shared responsibility for the software lifecycle. Real-world case studies further enrich the content, offering inspiration and practical insights.
In conclusion, "Continuous Delivery" is an indispensable read for anyone in software development. It serves as a guiding light, providing a blueprint for achieving software excellence through reliability, speed, and innovation. Highly recommended.
February 17, 2020
This book honestly took me quite a while to get through. The content is really useful knowledge for most software developers, who would like to get insight into the best practices of a delivery pipeline!
The slow repetitive phrasing of the book, which was in my mind quite like most American text books (where the payment is linear to the amount of words...), just made it a long haul for me to get through it. I do however want to say that I took some great notes from the content, but many of which are best practice today anyway, regarding releasing and version control management...
The slow repetitive phrasing of the book, which was in my mind quite like most American text books (where the payment is linear to the amount of words...), just made it a long haul for me to get through it. I do however want to say that I took some great notes from the content, but many of which are best practice today anyway, regarding releasing and version control management...
May 25, 2022
Continuous Delivery has become quite the buzz word lately. Hoping to start to better implement it at the office, I dug into this book.
This book goes through every single phase and offers examples and tips. I would consider this book an important theoretical read for every team attempting to implement this process.
This book goes through every single phase and offers examples and tips. I would consider this book an important theoretical read for every team attempting to implement this process.
January 11, 2019
Great Knowledge Through Experience
I can’t put enough stress on how valuable this book is! Whether you are a developer, operations or manager, you will find essential knowledge to improve your work an expand your comfortable zone. I personally found some ever-missing pieces of the puzzle that baffled me on past projects and now I can easily give competent answers to what went wrong and how we could have improved. The vast experience of the authors, seen as advices and examples throughout the book, is valuable lesson both for working on existing project or realizing a start-up idea! One of the must-read books!
I can’t put enough stress on how valuable this book is! Whether you are a developer, operations or manager, you will find essential knowledge to improve your work an expand your comfortable zone. I personally found some ever-missing pieces of the puzzle that baffled me on past projects and now I can easily give competent answers to what went wrong and how we could have improved. The vast experience of the authors, seen as advices and examples throughout the book, is valuable lesson both for working on existing project or realizing a start-up idea! One of the must-read books!
October 3, 2022
Great resource!
Explains all there is to Continuous Integration and Continuous Delivery very thoroughly.
Explains all there is to Continuous Integration and Continuous Delivery very thoroughly.
February 20, 2017
Indispensable.
December 30, 2014
Excellent book, clean and to the point.
December 1, 2016
There's much wisdom in this book, but it's buried in boring writing.
December 19, 2019
I read this book of and on, and it took me 6 months to finish this book so my review may not be the best because it's hard to remember the stuff that I read 6 months ago.
A lot of programming books seem to point out things that I already knew to be true, but it either wasn't in the forefront of my brain, or I didn't realize that I knew the things in them, if that makes sense. It's good to have these things pointed out, and it makes me better able to explain the concepts to other people, but it's not as helpful as it could be if it were new concepts that were being cobbled together from building blocks of what I already know. This book did have a lot of this in there, but it also had some completely new concepts, or concepts that I don't completely agree with.
An example of something that I didn't know to be true, but makes sense when I thought about it was manual deployment documentation. It's essentially only an aide to the person who wrote the documentation and probably isn't clear enough for anyone else to really pick up and use. It also discusses how manual deployments are tedious and boring, but at the same time requires a lot of skill. Something that I experienced a lot at my previous job migrating from mostly manual deployments in a static environment to using AWS and continuous integration. By the end, I could do it in my sleep but it was tedious and boring, but did require a lot of skill as a lot of the sites were slightly different and being able to identify and react to these slight differences.
I could be wrong, but it looks like this book came out in 2010, and there hasn't been a significant revision since. Maybe this contributes to some ideas that don't seem to have aged well or taken hold, at all. They seemed completely foreign and strange that they would be considered. The most glaring example of this is the authors' very strong and continuous push that all programmers should always do all of their commits directly on the master/head branch. They do explain their reasoning very well and give some good reasons why it would be beneficial: programmers don't have to rebase their branches (unless someone is working in the same area); makes sure that the branches are always production ready and deployable (unless someone messes it up); code doesn't get stale; and so on. There are two biggest reasons that I don't think that it's a good idea however: 1) I commit VERY frequently, it's not surprising for me to commit over 10 times in a day. Having all these commits without being squashed/rebased would make the revision history VERY long and tedious and difficult to find things. Of course you could do a force push and rebase the master branch, but then everyone else's branches would be out of sync and everyone would hate you. 2) It discourages committing frequently if you know that your change is going to be pushed out to the wild if it doesn't break anything. Either you're encouraging people to not care that the pipeline is broken, or to not commit until you know you haven't broken the pipeline. If you're doing test driven development, you're purposely breaking the tests until everything is fixed, which means that you're putting off all deployments until you finish your ticket (or you don't commit until you're done) 3) Since I thought of a third issue while I was writing the other two... If there is an emergency fix that needs to be pushed live immediately and the pipeline is currently not working, you either have to: a) Revert the code that broke the pipeline b) Fix the code that broke the pipeline c) Force the pipeline (perhaps tests) to pass/ignore some failures. None of which is ideal.
Another complaint I have about this book is that there aren't enough concrete examples, especially in regards to automated testing. As an area that I personally struggle with and hope to improve in my career, I was hoping that with all the talk this book had about automated tests that they could help me with my issues. I understand (now even better) the importance of automated tests, but I am just not good at writing them. They point out the exact issues I have with my automated tests, that I write them too close to the code and changes to the code break my fragile automated tests, but doesn't really give examples of how to fix it or how to do it correctly. I also haven't written a good integration or acceptance test, and I now know even more so their importance, but alas, I don't know how to write them. Granted, this may have been outside the scope of this book, but would have been nice to be included.
With all my complaints, I did enjoy reading this book. It helped me to not only solidify some of what I understood regarding DevOps best practices, but also taught me a lot that I was not aware of. At the same time however, it was not keeping me up at night because I was so excited to make it through the book, it could be use as a college text book after all.
A lot of programming books seem to point out things that I already knew to be true, but it either wasn't in the forefront of my brain, or I didn't realize that I knew the things in them, if that makes sense. It's good to have these things pointed out, and it makes me better able to explain the concepts to other people, but it's not as helpful as it could be if it were new concepts that were being cobbled together from building blocks of what I already know. This book did have a lot of this in there, but it also had some completely new concepts, or concepts that I don't completely agree with.
An example of something that I didn't know to be true, but makes sense when I thought about it was manual deployment documentation. It's essentially only an aide to the person who wrote the documentation and probably isn't clear enough for anyone else to really pick up and use. It also discusses how manual deployments are tedious and boring, but at the same time requires a lot of skill. Something that I experienced a lot at my previous job migrating from mostly manual deployments in a static environment to using AWS and continuous integration. By the end, I could do it in my sleep but it was tedious and boring, but did require a lot of skill as a lot of the sites were slightly different and being able to identify and react to these slight differences.
I could be wrong, but it looks like this book came out in 2010, and there hasn't been a significant revision since. Maybe this contributes to some ideas that don't seem to have aged well or taken hold, at all. They seemed completely foreign and strange that they would be considered. The most glaring example of this is the authors' very strong and continuous push that all programmers should always do all of their commits directly on the master/head branch. They do explain their reasoning very well and give some good reasons why it would be beneficial: programmers don't have to rebase their branches (unless someone is working in the same area); makes sure that the branches are always production ready and deployable (unless someone messes it up); code doesn't get stale; and so on. There are two biggest reasons that I don't think that it's a good idea however: 1) I commit VERY frequently, it's not surprising for me to commit over 10 times in a day. Having all these commits without being squashed/rebased would make the revision history VERY long and tedious and difficult to find things. Of course you could do a force push and rebase the master branch, but then everyone else's branches would be out of sync and everyone would hate you. 2) It discourages committing frequently if you know that your change is going to be pushed out to the wild if it doesn't break anything. Either you're encouraging people to not care that the pipeline is broken, or to not commit until you know you haven't broken the pipeline. If you're doing test driven development, you're purposely breaking the tests until everything is fixed, which means that you're putting off all deployments until you finish your ticket (or you don't commit until you're done) 3) Since I thought of a third issue while I was writing the other two... If there is an emergency fix that needs to be pushed live immediately and the pipeline is currently not working, you either have to: a) Revert the code that broke the pipeline b) Fix the code that broke the pipeline c) Force the pipeline (perhaps tests) to pass/ignore some failures. None of which is ideal.
Another complaint I have about this book is that there aren't enough concrete examples, especially in regards to automated testing. As an area that I personally struggle with and hope to improve in my career, I was hoping that with all the talk this book had about automated tests that they could help me with my issues. I understand (now even better) the importance of automated tests, but I am just not good at writing them. They point out the exact issues I have with my automated tests, that I write them too close to the code and changes to the code break my fragile automated tests, but doesn't really give examples of how to fix it or how to do it correctly. I also haven't written a good integration or acceptance test, and I now know even more so their importance, but alas, I don't know how to write them. Granted, this may have been outside the scope of this book, but would have been nice to be included.
With all my complaints, I did enjoy reading this book. It helped me to not only solidify some of what I understood regarding DevOps best practices, but also taught me a lot that I was not aware of. At the same time however, it was not keeping me up at night because I was so excited to make it through the book, it could be use as a college text book after all.
October 31, 2018
This was a hard read for me. I started reading the book when I never had any real world experience with Continuous Integration and hands-on experience with deployment pipelines/ infrastructure tools. Initially, the concepts made sense but I found it hard to apply them without project experience.
I stopped at around chapter 9 and after having around 6 months of experience on a project that uses deployment pipelines and tools (e.g. Ansible/ CI server) to enable automated deployment into different environments, I picked up the book again. This time, I have a better appreciation of the concepts that are discussed in the book since I am able to compare them to what we are doing in the project. (At this point, I have also read "The Phoenix Project", which might also have helped with understanding the discussion on management and change control.)
While the book has many gems, important principles and concepts, I think it might not be a suitable introductory book to Continuous Delivery, unless you have more experience with software development or have already worked on a project that has done some form of automation/ building of deployment pipelines. It would be more useful to read some introductory articles (on Continuous Integration, Continuous Delivery, DevOps), have some hands-on experience with infrastructure tools/ pipelines before reading this book for a more in-depth discussion/ comparison. That said, it won't hurt to skim some of the earlier chapters to get a rough idea of some of the principles to supplement the introductory articles on the net.
I stopped at around chapter 9 and after having around 6 months of experience on a project that uses deployment pipelines and tools (e.g. Ansible/ CI server) to enable automated deployment into different environments, I picked up the book again. This time, I have a better appreciation of the concepts that are discussed in the book since I am able to compare them to what we are doing in the project. (At this point, I have also read "The Phoenix Project", which might also have helped with understanding the discussion on management and change control.)
While the book has many gems, important principles and concepts, I think it might not be a suitable introductory book to Continuous Delivery, unless you have more experience with software development or have already worked on a project that has done some form of automation/ building of deployment pipelines. It would be more useful to read some introductory articles (on Continuous Integration, Continuous Delivery, DevOps), have some hands-on experience with infrastructure tools/ pipelines before reading this book for a more in-depth discussion/ comparison. That said, it won't hurt to skim some of the earlier chapters to get a rough idea of some of the principles to supplement the introductory articles on the net.
November 18, 2019
Being more and more interested in the topic of Continuous Delivery I decided to get myself a copy of a mentioned book. Looking at its size (over 440 pages) I was expecting to not only get the knowledge from it but also to get some solid tips on how to implement and maintain CD in different projects.
You will find plenty of knowledge in this book, that’s for sure: starting with ‘why continuous delivery?’, going through configuration management (do you keep your server’s configs in the version control?), testing strategies (E2E tests, smoke tests and other kinds of automated tests), configuring your deployment pipeline (is your staging really a copy of your production environment?) to deploying an application (blue-green deployments, canary releasing, zero-downtime releases) and monitoring its performance (via logs, dashboards and alerts).
Will this brook provide you with the exact tips, the ready-made plan for your project’s migration to continuous delivery? Not really. Why? Because there is no one-size-fits-all in this case. The last chapter was an absolute BLAST for me and I couldn’t stop myself from marking at least one sentence on each page.
One of the most useful tips in this chapter was a Maturity Model for Configuration and Release Management. This helps to identify where your project stands in terms of the maturity of the process and practises and what is the next improvement you should aim for.
This book definitely isn’t an easy read, has its ups and downs and also might be too wordy for some of you. Nevertheless, I think its a great resource to either begin your journey towards Continuous Delivery or to refresh yourself with the core concepts.
You will find plenty of knowledge in this book, that’s for sure: starting with ‘why continuous delivery?’, going through configuration management (do you keep your server’s configs in the version control?), testing strategies (E2E tests, smoke tests and other kinds of automated tests), configuring your deployment pipeline (is your staging really a copy of your production environment?) to deploying an application (blue-green deployments, canary releasing, zero-downtime releases) and monitoring its performance (via logs, dashboards and alerts).
Will this brook provide you with the exact tips, the ready-made plan for your project’s migration to continuous delivery? Not really. Why? Because there is no one-size-fits-all in this case. The last chapter was an absolute BLAST for me and I couldn’t stop myself from marking at least one sentence on each page.
One of the most useful tips in this chapter was a Maturity Model for Configuration and Release Management. This helps to identify where your project stands in terms of the maturity of the process and practises and what is the next improvement you should aim for.
This book definitely isn’t an easy read, has its ups and downs and also might be too wordy for some of you. Nevertheless, I think its a great resource to either begin your journey towards Continuous Delivery or to refresh yourself with the core concepts.
July 13, 2017
Interesting to see the book hasn't lost any relevance despite being written in 2010. This is definitely not an easy ready but rather a fundamental work on the subject. It's kind of like bible on continuous delivery that I'm sure I'll be referring back to as certain aspects of it become important in my work. I like how the book repeats over and over its core idea of having automated pipeline that makes feedback to developers faster and shorten the delivery cycle of working software. It covers wide range of topics to support this idea. Few things really stick in my mind:
- building binaries only once and using them to deploy everywhere till production
- automate everything from build and deployment to setting up environments and keep the configuration in source control
- build performance test suite by scaling up acceptance tests to model realistic load on the system
- minimize branching to avoid delaying integration pain
- 'branch by abstraction' and do even big refactorings by small steps while keeping the system releasable at all times
This is definitely not a groundbreaking work and you most likely know most of what is written in the book. But it brings all practices together in structured and coherent way.
- building binaries only once and using them to deploy everywhere till production
- automate everything from build and deployment to setting up environments and keep the configuration in source control
- build performance test suite by scaling up acceptance tests to model realistic load on the system
- minimize branching to avoid delaying integration pain
- 'branch by abstraction' and do even big refactorings by small steps while keeping the system releasable at all times
This is definitely not a groundbreaking work and you most likely know most of what is written in the book. But it brings all practices together in structured and coherent way.
December 25, 2022
There was an occasional typo, missing comma, or missing dash that made sentences harder to understand. Some technical terms would be used and their explanation wouldn't be given until much later in the book. The authors repeated material multiple times. That said, the book gives a thorough and extensive overview of CI/CD pipelines and practical advice to develop a pipeline in one's own projects: it's better to implement CI/CD from the beginning of projects and to catch and fix bugs early especially before releasing to production; developers, testers, and users should collaborate on requirements and tests; all non-production environments should be as close as possible to the production environment; do hard parts of the pipeline until they become easy; automate as much as possible especially the repetitive error-prone steps; always look for ways to improve the process. The concepts discussed are central to GitOps and to Kubernetes as the book talked about having a central repository for configuration files and rebuilding environments instead of repairing one. Lastly, I noticed that much of the advice can be applied to one's personal life.
May 7, 2019
A set of ideas about how to manage large scale software development. This makes a convincing case that a systematic approach can efficiently deliver high-quality software. In its time this was absolutely a great book, I'm not sure people are asking the same questions today. The authors are very knowledgeable and have remarkable foresight in particular about the significance of cloud systems. At the same time, cloud deployments make some parts of the book feel a bit outdated.
The layout of the book helps it make a convincing case that continuous delivery is an important and completely viable goal. It has advice applicable to a very broad range of situations related to implementing continuous delivery.
The book is not particularly outdated. It could serve as a good introduction to the subject. I just suspect it will no longer move a large number of people forward the way it would have a few years ago.
The layout of the book helps it make a convincing case that continuous delivery is an important and completely viable goal. It has advice applicable to a very broad range of situations related to implementing continuous delivery.
The book is not particularly outdated. It could serve as a good introduction to the subject. I just suspect it will no longer move a large number of people forward the way it would have a few years ago.
April 22, 2020
If you're serious about continuous delivery in an enterprise, then this is a must-read. This book talks about the philosophy of continuous delivery rather than specific techniques and tools. Even in a few areas where the authors talk about tools, you can see how the tools and technologies have been outdated, but the underlying philosophy is the same. One of the most important areas that many teams overlook for continuous delivery is testing automation. The authors detail the various stages of testing automation like commit tests, acceptance stage tests, etc. Also, I really appreciate the pragmatic approach of authors in introducing the exploratory testing concept for enterprises and how to address them in continuous delivery.
My only feedback is to do a revision of this book with the latest tools and techniques or have a sequel book.
My only feedback is to do a revision of this book with the latest tools and techniques or have a sequel book.
August 7, 2024
"Continuous Delivery" is a book that's an essential foundation for the modern Software-Delivery-Lifecycle (SDLC) and what many organizations take for granted.
Jez Humble, one of the authors of this book, is also a co-author in the "Accelerate book." My thoughts about it at https://www.goodreads.com/review/show... . 👈
It's important to note that the DORA metrics, which we now use to evaluate technical organizations, are a direct result of this book, published over a decade ago. Its impact is undeniable and deserves our appreciation. 👏
Re-iterating the whole book is redundant. It's already a good enough reason to read this book based on what it gave to the industry and the high expectations it set. You will only gain from reading it if you're thirsty for knowledge! 😉
Jez Humble, one of the authors of this book, is also a co-author in the "Accelerate book." My thoughts about it at https://www.goodreads.com/review/show... . 👈
It's important to note that the DORA metrics, which we now use to evaluate technical organizations, are a direct result of this book, published over a decade ago. Its impact is undeniable and deserves our appreciation. 👏
Re-iterating the whole book is redundant. It's already a good enough reason to read this book based on what it gave to the industry and the high expectations it set. You will only gain from reading it if you're thirsty for knowledge! 😉
September 2, 2018
It's a great book to take a perfect grasp of software release strategies. I would recommend this book for both experienced software engineers or the engineers who just started. If you are in big software teams, you most probably do most of the guidelines in the book, but still, the book provides a good perspective of the issues and possibly a complete checklist when you face the situation!
I noticed lots of people complaining about the repetitiveness of the book. I do agree with part of it. However, this is a case for a book on this subject as the author needs to set up a context in order to explain a point. So be cool with it and enjoy the reading!
I noticed lots of people complaining about the repetitiveness of the book. I do agree with part of it. However, this is a case for a book on this subject as the author needs to set up a context in order to explain a point. So be cool with it and enjoy the reading!
Displaying 1 - 30 of 166 reviews