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.

Today I’m announcing the expansion of my professional social networking. I’ve been active on Twitter for over a year. That’s nice. I’ve been on LinkedIn quite a bit longer. So yesteryear! I keep Facebook for strictly personal things, and political infighting with distant relatives. I also have profiles on GitHub and GitLab, but that’s not hipster enough anymore. This is why today, I’m happy to invite each and every one of you to connect with me with on my new favorite professional social network… Untappd!

This week I started helping a small startup evaluate and streamline their prototype application. Every time I start one of these projects, I’m struck in the face by how many common anti-patterns I see repeated on practically every project. Today I want to talk about the over-use of configuration. Here’s an (anonymized) snippet of the configuration for the application I’m working on (extracted from the docker-compose configuration): - S3_LOCAL_PATH=./static/ - EMAIL_TEMPLATE=.

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.

Something has gone terribly wrong. You and all the king’s men have risen to the occasion, and put Humpty Dumpty together again. What next? You’ve heard of postmortems, and you think doing one could help you, but where to begin? This guide is for you! With literally no preparation, you should be able to run a successful postmortem. Even if you found this via google after assembling in the conference room!

In the first of what may become a semi-regular feature of my daily list, I’m going to make a book recommendation. Regular readers likely already have a sense that I like find inspiration in unusual places, so I’m not recommending an IT-related book. Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb provides an interesting look at systems that are antifragile. Taleb contrasts “antifragile” against the more intuitive concept of robustness or resiliance.

A couple of years ago I was working with a team responsible for an eCommerce platform undergoing a platform migration. When I joined the project, it was already behind schedule and over budget. For several months, the migration project was continually “80% done”. The new platform was getting closer and closer to “ready,” meanwhile the legacy platform was becoming harder and harder to maintain. What’s worse, every functionality change on the legacy platform had to be re-implemented on the new platform, too, so that the eventual switch wouldn’t represent a regression.

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.

My wife and I recently started re-watching Star Trek: The Next Generation. One episode in particular jumped out at me as demonstrating some really bad engineering management practices. I decided to turn my thoughts into a YouTube video, and a postmortem. I hope you enjoy. All feedback is welcome!

Johathan Hall is a DevOps coach and consultant based in Netherlands. He has almost 3 decades of experience in the IT industry out of which 2 decades were spent in leadership roles. Jonathan is focused on helping small teams do amazing DevOps.

I’ve been thinking a lot lately about the relationship between manual tasks and automation. In this process, I’ve found myself describing how to move from one to the other in various contexts, and a pretty clear pattern has popped out at me. Here I want to distill the pattern down to the steps necessary to automate practically any process. Document all the steps. If the process is baking cookies, your list might look something like: