HN Books @HNBooksMonth

The best books of Hacker News.

Hacker News Comments on
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Jez Humble, David Farley · 11 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))" by Jez Humble, David Farley.
View on Amazon [↗]
HN Books may receive an affiliate commission when you make purchases on sites after clicking through links on this page.
Amazon Summary
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.
HN Books Rankings
  • Ranked #17 this year (2022) · view

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
May 18, 2022 · theptip on Thoughts on OKRs
> OKRs don't fix dysfunctional organisations.

Very true.

However -- note that the process of implementing OKRs has caused the leadership team to write down their expectations, which previously might have been unspoken. This is a first step towards resolving the problem. The next step is for the CTO to push back, hard, on the bits of these that aren't actually realistic, and hopefully get the leadership team aligned on what can actually be done. And so, the process of OKRs potentially has value here in flushing out unrealistic or mismatched expectations between different parts of the org.

This is one of those rare "my way or the high way" moments in leadership; as CTO at this company it's your job to either get the leadership team to realize that they are asking you for more than you can be expected to deliver, or quit. You can't stick around and put your name on a plan that you know is impossible; otherwise you're going to be the one that failed for every quarter to come. And even worse, you can't sign your team up for this BS. It's your job to shield them from this kind of shit.

> Half the Objectives were outside the scope of the engineering team.

Shared OKRs are difficult, but sometimes they are unavoidable. The most difficult business problems usually are cross-functional. At their best, OKRs can help to make these cross-functional dependencies more explicit, and foster communication and collaboration around them.

If they are trying to have engineering take full ownership of a shared OKR, that's a big problem. But if you clearly call out the shared ownership, and consider both parties responsible for implementation, then I think that's OK.

> We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources.

As a tangential point, increasing release cadence can definitely decrease your long-term rate of issues (see "Continuous Delivery" by Humble[1]) -- this forces you to automate manual processes, and manual processes are one of the main places that errors creep in. Though I think "count of issues" is a very poor metric, you're better off with an uptime metric. And "100%" is the only strictly-incorrect number to pick for uptime, because it is literally impossible; my (super-unscientific, don't hold me to this) rule of thumb for business people is "every extra 9 costs you 10x". So do you need 99.9% uptime or 99.99%?


I’m glad you mentioned this, yes the CTO quit 6 months later.
I'm not sure there is one really, because deployment varies a lot depending on your technology stack, your architecture, your deployment model, your product. You sort of learn the fundamental concepts and then pick out the pieces that fit your use case.

Everyone should read Continuous Delivery to start ( It's 10 years old but it's still the canonical reference for how most people should be deploying in the modern age.

A book on containers would be the next thing I'd learn very thoroughly. Whether you run them in Docker on a single host, or run them in a cloud orchestration system, doesn't matter really. Just having an app in a container provides the abstractions you want to enable rapid, reliable deployment on multiple platforms. Most deployments should be dead simple: pulling and starting a new container, pointing traffic at the new container, stopping the old one. Rollback is the same in reverse order of container. There should be a billion different services to manage this for you, but you can also do it yourself on a single Linux box easily.

Then a book on database migrations, which isn't really complicated once you get the jist of it. This teaches the idea that if you're using a database, you have to think hard about how you're using it in context of your code deployments, and gives you a model for how to handle both reliably.

Next, the tools Terraform and Packer are very useful for handling the "infrastructure" side of deployment. If you manage an actual VM that runs your apps, build the image with Packer and deploy it with Terraform. It's much better to use some managed provider that just runs your containers so you don't need to deal with this. But if you do need to manage a host OS, this will make it seamless and reliable to do the inevitable maintenance in a way that you can test first, and recover easily from failure.

Ensuring your app works along the methods of the 12 Factor App (it's just a website, no book) will make sure it fits into all the tools and methods. If you just look for the deployment piece of every part of 12FA, you'll build a very robust deployment system.

Finally, learn Bash and how to set up a web server like Nginx (and how to use it as a reverse proxy) and you will have basically all the skills you need to do modern best practice deployments.

devops is more of a principle than a job. that's my opinion though.

i've been reading through this book and it does a decent job of covering the principles for CICD, builds, tests releases:

you'll run across various "thought leaders" in devops and its important to remember that a) each employer treats devops and cicd differently and you'll want to learn their practices as you bring about your own ideas to the culture and b) form your own opinions, just b/c thought leaders and books are out there its important to learn what you like to do and improve how you like to do it.

If you haven't read it already, read Continuous Delivery.

Continuos Delivery by Jez Humble and Dave Farley

Just started reading "Continuous Delivery" by Jez Humble, et al. Really wish I would have grabbed this years ago, great primer on what (for me) is a confusing topic.
One of my most popular blog posts (by a long shot) ended with the words "is dying" I love figuring out ways to get people to click on my articles.

With that said, we also do a read only branch called stable that we only push to once unstable gets the OK in Jenkins. I would not say that it is dead, but just an extra safe guard. I do appreciate that book recommendation on I have not heard of that before.

You really should be starting your titles with 'why', for that extra punch.
In my opinion, this book[1] is the authority on continuous integration and continuous deployment.

Continuous Integration is fundamentally about creating a tight feedback loop between your developers and your code. When you program in your IDE, the instant you write uncompilable code, you get red squigglies, so you're getting an instant feedback loop on something you just wrote.

CI is the same thing, but at a higher level. The instant you commit your code, some automated process should take over and start analyzing / compiling / testing your code and look for things to give you feedback on. If your code doesn't even compile -- one of the first milestones of CI, you should know that immediately.

Since you just committed it, making the fix is easy. This is compared to a developer who downloads your code the next day, can't compile, comes and bugs you about it, etc...

As far as some real world use cases, we just setup Jenkins for a new Java project we're writing. It does an automated build test that compiles and executes all unit tests automatically on any commit to GitHub on any branch. It's a little slower than I like -- our still growing app takes a full 3 minutes to compile and give feedback.

But, it's been great. For example, the GitHub client on Mac OS X doesn't recognize when I change uppercase letters to lowercase and vice versa, so while my local compiles worked fine, my repo actually had a failing build. Once I committed, I got an automated email within 5 minutes telling me the build failed, and I fixed it. Without CI, I may not have found about that issue for weeks, making the change more difficult.

For production deployment, we're still in alpha, but we've got a 1-button push to deploy. Again, slower than it should be -- in this case 5 minutes -- but the automation is awesome and makes doing any deployment -- whether hot fixes or new releases that much more pleasant.

Regarding the performance, I see it as a win just to get anything automated, however slow it may be. Because once you're there, you can always look for ways to optimize it. For example, our current build process, re-downloads dependencies every single time. This could clearly be cached. When it's a priority for us, we'll do it.


> [1]

Did you just put your Amazon associates referral code in a link on HN? lol

No, I didn't. I don't even have an Amazon associate's referral code, so I must have pasted someone else's. Hoping 1 person on Hacker News will buy a book I linked to in one comment so I could earn $0.25 does not strike me as a great earnings strategy.
I thought the continuous delivery book was written by Jez Humble and David Farley. Fowler provides a foreword for it Other than that I totally agree with you comments - Lean Continuous and Agile are not orthogonal to Quality.
You're right, sorry. It's in the "Martin Fowler" Addison Wesley series of books, it's not written by Fowler. I've had the book on my shelf and read a good bit of it, and should have caught that!

"Martin Fowler" is on the cover in two different places, plus it looks just like the cover of Patterns of Enterprise Application Architecture, which he did write, so I've had that misconception in my brain for a while. Failure to test assumptions...

Easy mistake to make. I believe Jez works for ThoughtWorks too and I'm guessing Fowler had some input in the idea.
If you are specifically interested in this kind of continuous deploy process then "Continuous Delivery[1]" is a decent book on the subject. The IMVU post "Doing The Impossible 50 Times A Day[2]" is another good place to start reading.



thanks a lot
HN Books is an independent project and is not operated by Y Combinator or
~ [email protected]
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.