CI/CD is FREEDOM

I post about three general areas that I am passionate about: systems engineering as it applies to organization design; excellence in software engineering practices; and, delivering great product to nail the user's and the business's needs. This post is about software engineering. Enjoy!

Act 1 - Setup

Picture, if you will, a Scotsman. Big, strong, hairy, pungent, and bent on independence for Scotland. Picture him sitting astride a great stallion, addressing a horde of assembled men ready to take on an English army.

Aye, fight and you may die. Run and you'll live -- at least a while. And dying in your beds many years from now, would you be willing to trade all the days from this day to that for one chance, just one chance to come back here and tell our enemies that they may take our lives, but they'll never take our CI/CD!!!

You might think that Mel Gibson, in portraying this scene in the 1995 blockbuster Braveheart, took some artistic license with William Wallace's enthusiasm for CI/CD. However, you would be mistaken in this position. Had Wallace in fact been a 21st-century DevOps practitioner, I am certain that he would have understood the vitally important value that CI/CD brings to our lives.

The picture below is an automated build light. A physical build status indicator, mounted on an office wall, connected to a CI/CD build system such that "green" represents a healthy build, and "red" represents an unhealthy "failed" build.

How does this picture make you feel? Does it give you the heebie-jeebies? If so, you might identify with some of what I am about to say.

Act 2 - Confrontation

What is CI/CD?

CI/CD stands for Continuous Integration/Continuous Deployment. It is implemented in standalone CI/CD systems like TeamCity and Jenkins, and is a key feature of broader DevOps delivery platforms like MS DevOps, GitHub, BitBucket.

CI/CD does a couple of important things.

Short Feedback Cycle

You know quickly if you broke it

Let's start with the big one. When you have a functional CI/CD system, you are informed quickly when something is broken. A light goes red, and you know right away which change caused the failure. That is a quick feedback cycle. Because you just broke it, you know exactly what the cause is, and it should be quick to fix.

The thought may have occurred to you "wait, I can achieve that locally without CI/CD". And maybe you can, for a while. You can set up some scripts that everyone runs before committing a change, maybe. But, unfortunately, it's incredibly likely that at some point, the team will have a lapse in discipline, and some of your nice green tests will go red, and... nobody will care. CI/CD is a much more robust solution, because it makes the failure immediately visible when someone else broke something.

Psychological Safety

You're not nervous about breaking something you don't understand

Once you have this in place, coupled with adequate test coverage you know that you can confidently make a change to your system. If the light is green, your change is good. Or at least, you haven't broken something fundamental. This relieves or lessens any anxiety you or your team might otherwise have.

This is best achieved by configuring your CI/CD build to run on every branch.

Pre-Tested Commit

The unbreakable build

With adequate architectural design and test orchestration, the pre-tested commit (or "gated" commit) pattern can be used to ensure that any commit (or branch, or PR) that would fail the build never makes it to production. This works by configuring the CI/CD system to run the build to completion on a merge-candidate branch (or PR), and then automatically rebasing, (often) squashing, merging the result if and only if all tests pass (green status).

It Runs On My Machine

Few "Gotcha" Dependencies in your Build System

This one is more of a side-effect than anything else, but it's a nice convenient one. Your CI/CD build ought to run on a "vanilla" build agent with very few system-installed dependencies. That has the benefit that any new member introduced to your team can come along on day one, check out your code, and execute build.sh (or build.cmd), and successfully build the project without spending three days configuring their tools.

Other Build-Time Checks

There are a bunch of other things you can do at build time that can be automated and enforced in a CI/CD system.

• Scan for security vulnerabilities in first-party components or third-party libraries.
• Run an automatic "linter" to tidy up your code.
• Perform any necessary regulatory or procedural checks enforced by your company.

Act 3 - Resolution

Just like Braveheart (1995), this story has a happy ending. By the time this article was published, all of the build lights were green again. This just goes to show how awesome a team of motivated, dedicated and productive engineers can be.

Because remember:

they may take our lives, but they'll never take our CI/CD!!!