An overlooked benefit of Continuous Deployment is the psychological change that developers feel when they know that "Merge" means "Go live".

In 2009, many thought 10+ deploys per day was inconcievable. Today it's boring. I call that progress!

Continuous Deployment is about Continuous Management.

Some projects obviously need automated builds. Others obviously don't. Where do you draw the line?

Even if we reduce defects to, one per year, if repar takes days, any gain is lost.

“Whether a human is involved in pressing the deploy button or not, you are going to deploy a bad update eventually.”

"Grant me strength to accept changes a week before a release" — But why aren't we using Continuous Delivery?

In this episode of Developers Eating the World, Chris sits down with Johnathan Hall, AKA the Tiny DevOps Guy. Johnathan is a DevOps expert and recently started focusing his efforts on tiny teams with big ideas.

Continuous Delivery and Continous Deployment are frequently conflated with each other. This is at least in part because they have the same common abbreviation: CD. And while thes concepts are technically related, it is important to understand their differences, and be clear about which one we mean when communicating. In short, Continuous Delivery is the practice of continuously and automatically building and delivering a software package whenever a code change is committed.

What if we could do Continuous Delivery without setting up a full, automated Continuous Integration pipeline first? This is the topic of my recent interview with Jacqueline Salinas on the Continuous Delivery Foundation’s podcast, The Pipeline. I first wrote about this topic back in 2019, and for those interested I have recently developed the Lean CD Bootcamp email course to walk you through the steps of setting up a CD pipeline without full CI.

In my dreams, every new feature I develop is amazing. Customers love it, and they receive great value from its use. Yesterday I explained why rolling back is dangerous in these situations. Today I present you with my preferred alternative: Rolling forward The idea is fairly simple. When a critical failure occurs, rather than rolling back to a previously-built version of the software, we revert the broken change in git (or other VCS), then build and deploy a new version of the software.