Jonathan Hall joins the Adventure this week to discuss the advice he gives to clients to start continuous deployment before they have automated tests around their code.

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

Olaf Molenveld joins me to explain the concept of Progressive Delivery, when it makes sense, and what homework every team should do before getting started.

“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.

Broken code is inevitable. Despite our best planning, automated tests, code review, and everything else, sooner or later (probably sooner) you’ll find that you’ve deployed a broken feature into production, and users of the system are complaining. Our natural instinct in such a case is to quickly jump back to the last working version—a process we colloquially call a “rollback”. Today I offer two reasons not to do this. Tomorrow I’ll talk about an alternative.

GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.