CI/CD Ingredients for Success

The obvious and the not-so-obvious information about Continuous Integration and Continuous Delivery

Let’s take that pipeline from a Pendolino to a Japanese Bullet Train

Continuous Integration and Continuous Delivery (CI/CD) is a staple of any software house worth it's salt. It is a practice that has become so foundational in the industry that many of us can no longer imagine working without it. CI/CD is as basic as tests and every bit as useful, and yet, I’ve seen such a great variation of pipelines out there, some bad, some good, and some insane.

I’ve been working with CI/CD systems for several years now and in my time, I’ve amassed a plethora of my own failures. Failures that have resulted in a little wisdom and a lot of grey hairs.

In this piece, I’ll cover some basic capabilities that your pipeline should have. I’ll mark both the essentials and the luxuries, then we’ll talk about your non-functionals, namely speed, logging, and error handling.

Just what the hell is CI/CD?

Before we get into the meat of this piece, a quick overview. Back in the glory days of 1997, when Oasis were going strong and dressing like an undertaker was cool, Kent Beck and Ron Jeffries came out with Extreme Programming. XP listed out a set of practices, principles, and values that they believed would usher in a better world of software engineering. It was a sensational change.

First, CI

While Continuous Integration (CI) had been proposed by Grady Booch in 1991, it was Kent and Ron that pushed it forward. In short, CI is taking all of the code and testing it constantly. The aim? To ensure the team isn’t drifting away from one another and to nip integration issues in the bud.

And CD

Continuous Delivery (CD) was popularised by Jez Humble and David Farley. This is a two-pronged principle:

1. The code in the trunk (the master branch or the SVN trunk) should be deployable.
2. Those deployments should be completely automated and should not require any manual steps.

Together, they’re awesome.