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.

Martin Fowler’s widely-accepted definition of Continuous Integration says: usually each person integrates at least daily The ambiguity around “usually” and “at least” leaves this somewhat open to interpretation, and the common question: Is my team really doing CI? Rather than dwelling on a specific definition of CI, I think it can be useful to focus on the reasons we care about CI. There are many benefits you might gain from CI, but let’s look at one of the big ones.

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.

“Hotfix” doesn’t have a single, specific definition, but Wikipedia describes one as “a single, cumulative package that includes information that is used to address a problem in a software product (i.e., a software bug).” When it comes to version control systems, we usually see a slightly different usage of the word. I’ve usually seen it used to describe any sort of “quick fix” that’s applied directly to an existing software release, rather than going through a team’s normal software release process.

Yesterday I explained that GitFlow is anti-agile, but what’s the better alternative? Trunk-based development is the core method I advocate. The one-line summary is: A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’*, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. main or master, in Git nomenclature There are a number of variations I use in specific situations, but the core practices of meaningful trunk-based development are:

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

After reeling against using a test code coverage percentage to measure the value of your tests, let me offer one small exception. There is one way in which I find test coverage to be useful: comparing the delta of test coverage against expectations. Strictly speaking, this doesn’t need to be a measure of coverage percentage. It can be a report of raw lines (or branches, or statements) covered. The idea is: I don’t generally expect this number to go drastically down (or for that matter, up).

Until recently, I was using the wrong definition of Continuous Integration. You probably are, too. This is a bit of an embarassing mistake, at least for me, because I’ve heard the proper definition many times. And I talk about, and advocate for, CI, all the time. If you had asked me, I probably would have said something like “Automatically test your code, before it’s merged.” Interestingly, the simplest definition of continuous integration says nothing about testing—automatic or otherwise.