Continuous Delivery by Jez Humble and David Farley
See a Problem?
Thanks for telling us about the problem.
Friend Reviews
Reader Q&A
Community Reviews
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.
...more
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.
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.
...more
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
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
...more
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 th
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.
...more
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 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. ...more
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 Comput
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.
...more
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 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... ...more
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.
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
Great Knowledge Through ExperienceI 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!
...more
Explains all there is to Continuous Integration and Continuous Delivery very thoroughly.
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
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.
...more 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
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.
...more
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 cont
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.
...more
- 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. ...more
The layout of the boo 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. ...more
My only feedback is to do a revision of this book with the latest tools and techniques or have a sequel book.
...more
I noticed lots of people complaining about the repetitiveness of the book. I do agree with part of it. Howe
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!
...more
This book contains many good practices and strategies around CI/CD process. Most of this knowledge is quite general without many details about implementation and tools, which is good because this way it is useful even many years after publishing.
For me, the most interesting chapters are those with strategies around automated tests and
Warning: Chapters in this book have repetitive information for those who want to read this book selectively. You can get bored when you read it from cover to cover.This book contains many good practices and strategies around CI/CD process. Most of this knowledge is quite general without many details about implementation and tools, which is good because this way it is useful even many years after publishing.
For me, the most interesting chapters are those with strategies around automated tests and data management during releases.
I can recommend this book for those who are new in CI/CD and for those who want to find how much of CI/CD the have in their projects.
...more
Some parts might not surprise you all that much, but are great to revisit - even old hands might learn a thing or two from the refreshing mix of theory and practice, and the very relevant real life examples. Some parts were completely new to me and touched areas I had previously little knowledge of. I feel thoroughly updated.
It is a long read, with some chapters written better than others, but r
Eye opening. Everybody in IT should read this book, be he programmer, tester or operations specialist.Some parts might not surprise you all that much, but are great to revisit - even old hands might learn a thing or two from the refreshing mix of theory and practice, and the very relevant real life examples. Some parts were completely new to me and touched areas I had previously little knowledge of. I feel thoroughly updated.
It is a long read, with some chapters written better than others, but reading everything in the order it was written was well worth it.
...more Definitely has me rethinking my use of Gitflow and moving towards more of a trunk-based model. Also has me thinking a lot about managing configuration of my various environments.
I will say it reads like a textbook. Lots of text, and not many graphics makes it a slow tedious read. It also repeats itself a lot, which is good to reinforce things,
Good Book. Lot's of good ideas in here. Slightly dated. It's about 10 years old now so the technology has changed but the ideas and principles still hold.Definitely has me rethinking my use of Gitflow and moving towards more of a trunk-based model. Also has me thinking a lot about managing configuration of my various environments.
I will say it reads like a textbook. Lots of text, and not many graphics makes it a slow tedious read. It also repeats itself a lot, which is good to reinforce things, but slows you down a bit.
...more
There are a couple things in there that I have never done on the job, but will definitely add to my pipelines / way of working.
Downsides: the "technologies" you can use to integrate the methods described in the book are a bit outdated (book from 2010) and sometimes no longer represent the available choices on this market that has since evolved. I had some episodes of: "yeah, I use to use this". Ex: Ivy in the .NET world.
This said, most of what is in there is still highly relevant
Excellent book,There are a couple things in there that I have never done on the job, but will definitely add to my pipelines / way of working.
Downsides: the "technologies" you can use to integrate the methods described in the book are a bit outdated (book from 2010) and sometimes no longer represent the available choices on this market that has since evolved. I had some episodes of: "yeah, I use to use this". Ex: Ivy in the .NET world.
This said, most of what is in there is still highly relevant today and worth reading about.
...more
The only drawback is that it is now twelve years old and needs a revision, mostly in its I used this book to develop questions for the EXIN DevOps Master exam and to find inspiration for an upcoming ISO standard on the integration of (Agile and) DevOps with Service Management. It served well in both cases. It is very practically-oriented and explains the main concepts of Continous Integration and Continuous Delivery very well. It even goes as far as presenting links with ITIL and Risk Management.
The only drawback is that it is now twelve years old and needs a revision, mostly in its listing of tools and platforms, but practices have evolved as well. ...more
great book for everyone that wants to understand CI and CD. Good for managers, Project managers; Product managers and also for any Technical role. I loved the real life samples and the way they describes how you can go from a 0 to a 4 level of CI in your organization. I think this is a must to learn if you want to start with CI no matter what your role is in the project.
Almost no mention to the cloud.
A bit more to the DVCS. Focus on mainline development which I think it has value today but it needs a different explanation from 10 years ago.
But the principles are there. So read it.
This is THE classic for continuous delivery. Worth reading. But it was written 10 years ago and sometimes that's obvious.Almost no mention to the cloud.
A bit more to the DVCS. Focus on mainline development which I think it has value today but it needs a different explanation from 10 years ago.
But the principles are there. So read it.
...more
Like most practitioner books, it is hard to understand the implications without some practical experience.
Goodreads is hiring!
Learn more »
Other books in the series
News & Interviews
Welcome back. Just a moment while we sign you in to your Goodreads account.
Source: https://www.goodreads.com/book/show/8686650-continuous-delivery
0 Response to "Continuous Delivery by Jez Humble and David Farley"
Post a Comment