Oops, I did it again! (CI/CD)

@here and @far #112

The Gnu Image Manipulation Program being Continuously Integrated

Continuous Integration and Continuous Delivery, collectively known as CI/CD has transformed software development.

This is a very technical topic, but I’ll do it in as non-technical terms as I can. And for those that are technical, know that I am knowingly leaving a lot of depth out.

This technique is about getting software to users faster. When used, the frequency of release goes up between 10 and 1000 times, depending on what the previous test and release process was. This means users can experience updates many times a day.

That’s phenomenal. In my opinion, CI/CD is one of the most important (recent) tech innovations.

But before I explain why it’s so great, let me answer what it is.

CI (Continuous Integration) is a technique where, as soon as code has been changed in an application, a full test suite is run. On every single change it is immediately clear if the change worked (because the tests pass) or not (the tests fail). Once the change has passed and been approved, then the change immediately becomes part of the main code base.

CD (Continuous Delivery) is the second part of CI/CD. Here, as soon as that code has passed the CI step and has become part of the code base, that new codebase is released automatically. Users start using it right away.

So why is this so great then? In fact, it seems like a lot of work.

Well, CI/CD allowed us, in my previous role, to release about 50 to 80 times a week for each application we supported. That was the limit because our CI/CD automated process took about an hour (and we worked in two time zones). (As an aside, I’ll note this was for a financial services application where compliance and reliability are extremely important).

In fact, our releases were on the slow side for CI/CD. Go-lives can happen as fast as the build and tests can run, which can be as little as seconds.

Here’s the thing about CI/CD. You might argue that small releases are no big deal. You could say: just release the bigger thing at one time; it’s the same amount of code.

But small releases eliminate the QA cycle of the big release model where all the changes have to be tested together. And any problems found have to be tracked down to the exact change that caused the problem.

With small releases, each change can be deployed immediately, and if there’s a problem, rolled back immediately. And because releases are small, they rarely have problems. Each team member can independently (depending on review and approval rules), create their own release. This means they aren’t waiting for others. Also, there are (almost) never code freezes (this is when no one is allowed to put changes live, for fear of something going wrong). The application is always in a releasable state with everyone sharing joint responsibility for the state of the code base. There are also no maintenance windows (when the application has to be turned off so changes can be deployed). Your application is always live.

All of these benefits stem from the Lean principles of small batches.

I call CI/CD the pinnacle of software team performance. It’s really hard to get there (for example, if your automated test coverage isn’t good enough, CI/CD is impossible). It’s also hard to stay there (if people get scared of releasing, the whole process grinds to a halt). However, if you are able, as a team, it provides a sense of freedom and fluidity that is not possible with a more traditional release process.

Currently CI/CD is mostly used for web sites and hosted infrastructure where deployment to live can happen with no one noticing. And it’s not used on apps, smartphones and computers. This is because downloading to a device and installing is typically a manual burden on the user. If users had to download each update, it would never happen.

But the productivity benefits of CI/CD are so great that I predict it will come to operating systems and applications. Platform providers like Apple, Android (Google) and Microsoft will find ways of rolling out tiny upgrades continuously. It will be hard (nobody wants a bricked phone every few days, meaning reliability will be key). But it will speed up software greatly.

I see a future where your smartphone is updating its operating system 15 times a day, just like many of the web apps you use (example facebook). And you won’t even notice.

My advice to software teams: if you are able to adopt CI/CD, do it. If you are doing it and thinking about bailing, don’t.

Why don’t Brit’s skip the queue? They don’t want a 25 letter alphabet.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lukas Oberhuber

A CTO who writes. A writer who codes. A coder who jokes. A joker who innovates. An innovator who CTOs. Co-Founder and CTO at https://hiphops.io