Agile Principles —1 min read
The U-Shaped Cell

The Toyota Production System's U-Shaped Cell is a favorite DevOps analogy: Put all the tools within reach of a single developer.

Software Delivery —1 min read
The poor man's feature flag

How to use feature flags if you don't have feature flags.

Software Delivery —31 min listen
Jonathan Hall on Developers Eating The World

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.

Software Delivery —1 min read
What's the difference between Continuous Delivery and Continuous Deployment?

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.

Software Delivery —1 min read
Can we do CD without CI?

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.

Software Delivery —2 min read
How do we know if we're doing 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.

Software Delivery —2 min read
Roll with the changes

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.

Software Delivery —2 min read
The two big dangers of rolling back

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.

Software Delivery —2 min read
"Hotfix" is a dirty word

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

Software Delivery —1 min read
A case for trunk-based development

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:

Software Delivery —2 min read
GitFlow is anti-agile

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