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

Author: Jez Humble, David Farley
All Stack Overflow 13
This Year Hacker News 3
This Month Hacker News 1

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


Review Date:


by vsupalov   2017-11-23
Good point. But that's not limited to automation. As with data engineering, or software development, you're likely to overdo it and build something which does not agree with reality if you "try to build the whole thing" at once. Building the smallest possible deployment pipeline (a skeleton pipeline, as it's called in the continuous delivery book (from 2010 but still the best thing on the topic out there) [1]).

You start covering the most essential needs just so they become useful and usable. Then you go ahead and iterate from there, building something which suits your team, company & product. Learning and adapting in the process.


by anonymous   2017-09-11
For safety and speed, you don't want your code history is stolen by hackers and want to speed up the whole build process. If you have intrest on continuous deploy, you could look [Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)): Jez Humble, David Farley: 9780321601919: Books]( This book has a good explanation about how to do it right.
by anonymous   2017-08-20

This topic itself is quite complicated and there is no general or standard approach available for this. I can highly recommend to read a book Continious Delivery, there you will also find a list of available tools and a proper explanation of how to do things correctly. Keep in mind this will take significant ammount of time, but from the other hand will make your life so much easier.

In a nutshell, you will need to have:

  1. List of all products (binaries, msi, dlls, etc) available within your company
  2. A list of all possible configurations for the products
  3. Versions available of any product
  4. List of environments (staging, UAT testing, production, etc)

You will also need to have a place where you can select a product of particular version, it's configuration and deploy it via one button click to the selected environment. This user interface shall also allow you to see which product (version and configuration) is deployed to which environment. Behind the scene, the tool will just call the scripts that you wrote to perform custom deployment.

In terms of tools, there are quite a few things that you will need:

  1. CI server(Go, TeamCity, TFS)
  2. Build managements scripts, such as MSBuild, NAnt, etc.
  3. Tools like Puppet or CMDB for configuration management
  4. Deployment scripts, like Powershell
by anonymous   2017-08-20

I think either strategy can be used with continuous development provided you remember one of the key principles that each developer commits to trunk/mainline every day.


I've been doing some reading of this book on CI and the authors make suggest that branching by release is their preferred branching strategy. I have to agree. Branching by feature makes no sense to me when using CI.

I'll try and explain why I'm thinking this way. Say three developers each take a branch to work on a feature. Each feature will take several days or weeks to finish. To ensure the team is continuously integrating they must commit to the main branch at least once a day. As soon as they start doing this they lose the benefit of creating a feature branch. Their changes are no longer separate from all the other developer's changes. That being the case, why bother to create feature branches in the first place?

Using branching by release requires much less merging between branches (always a good thing), ensures that all changes get integrated ASAP and (if done correctly) ensures your code base in always ready to release. The down side to branching by release is that you have to be considerably more careful with changes. E.g. Large refactoring must be done incrementally and if you've already integrated a new feature which you don't want in the next release then it must be hidden using some kind of feature toggling mechanism.


There is more than one opinion on this subject. Here is a blog post which is pro feature branching with CI

by anonymous   2017-08-20

(That is quite a few questions inside one big question.)

But I would refer to the Continuous Delivery book

Edit: (As commented you already read this book) Some suggestions which you may already do, but for others with similar issue:

But I have no solid solution to the inter-dependency auto-deploy strategy you actually ask for :|

by perlgeek   2017-08-19
For the build/test/integration/deployment cycle, there's "Continuous Delivery" by Humble and Farley:

I found that very good for understanding the principles and reasons. Implementing it was a very frustrating experience for me, which is why I wrote a (much shorter) book on how to do it practically, with worked examples:

by MalcolmDiggs   2017-08-19
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.
by jjmiv   2017-08-19
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.

by sciurus   2017-08-19
If you haven't read it already, read Continuous Delivery.