What is CI/CD?

As a combined acronym I think CI/CD entered common usage around 2018. The CI part stands for Continuous integration (CI) and the CD part stands for continuous delivery (CD). Both of which have been around for a long time.

To understand CI/CD lets break it down:

So what is Continuous Continuous (CI)

Let’s try and explain CI for non-technical / non-development staff. A software product can be thought of in a similar way to a large complex storybook. The book might be written by one author over a number of months of years but if there’s commercial pressure on getting the book published it may be written by a team of authors who collaborate on the work.

In the case of a book, the work may be shared out between the authors, illustrators and editors. These might be split into separate teams, with one team responsible for the architecture of the story (ie the plot, characters, setting etc) and other teams assigned to various chapters.

The publishing house could wait until each team says they have finished work and then ask each team to send in their chapters and illustrations and then give some poor editor the job of trying to merge it all back together again.

The merge process would likely take days or weeks of pasting text together which wouldn’t be very efficient or these days commercially viable. However worse than this, the likelihood is that when pasted together the chapters no longer make a coherent storyline. For example, a key character needed in chapter 10 may never have been overlooked and not introduced in the earlier chapters or might have been dramatically murdered with pages and pages of text devoted to this scene.

If this sounds like a nightmare way of writing a book then you’ll be horrified to learn that this is precisely the way programmers/developers work together on large software development projects. The more developers that are involved the greater the risk of misunderstanding and error. Teams of more than 6 or 7 developers actually get less efficient but the management response to a project which is running late or which needs to deliver by a fixed date is usually to throw more people at it. (Developers joke about inexperienced project managers asking 9 women to have a baby in a month. )

In the case of a book written by teams of authors, the publisher could try and avoid these problems by having each author submit their latest text each day or even work in an online shared document. The editors can then see how the work is going and immediately jump on any mistakes while it’s easy to put them right. In fact, it may not even need the editors to spot the mistake, the chances are the authors, being able to see each other’s work will read the chapters others have written and spot continuity errors for themselves.

I’m sorry to say that software is more complex than writing a book. A continuity error in a book isn’t going to cause the financial failure of a company or kill someone but software does break companies and can kill when it goes wrong.

In software development, we, therefore, ask developers to ‘check in’ the code they are working on daily into a central repository which all the other developers then sync with. The master code in the repository is then compiled (turned into machine executable code) in a process known as the ‘build’.

To spot structural errors and continuity errors in the code the build process can include static analysis of the source code to spot frequently recurring errors and breaches of house style and automated tests.

Automated tests are scripts which run parts of the codebase with known input and test to see if the code generates the expected outcome. For example, in an accounting system, a test might post a debit and a credit and then test the account balance is correct. The same test might be run with different scenarios for example what happens if the debit takes the account overdrawn or what happens if a very large amount is deposited. In any case if one of these automated tests fails then the build fails and the team focus on fixing the error before continuing with any other development work.

So what is Continuous Deployment (CD)?

Going back to our book analogy for a little while, lets say the publisher merges together all the text, and maybe automates a spell check and grammar check over the document. If these don’t find any errors then they might choose to automatically deploy a draft version of the new books in eBook form to readers who they know are interested in the forthcoming title and who would be willing to provide constructive feedback. This then is continuous deployment of the book on a daily basis.

The publisher could employee someone to manually send the draft of the eBook or upload it to a website each day, but doing this manually would be inefficient and error prone. If the publisher decides to move from daily updates of the ebook to hourly updates, around the clock doing the work manually become even less viable. 

The publisher will look for ways to automate the deployment process of the eBook initially to the proofreaders and ultimately to the eBook stores on Amazon and Apple. This means the task will be performed consistently and can be performed frequently very efficiently. 

The same thing happens with software. Instead of letting a group of readers have access to the book, the software is deployed into a user testing environment. Depending on the size and scale of the project this might be a UAT (User Acceptance Test) environment or a Staging Environment or indeed another entirely separate testing environment for the project. 

The process for deploying software into a test or production environment can be very complex, one mistake can be the difference between success and failure. It’s not something you want to be doing manually especially when you consider that many leading organisations will be deploying software updates hundreds of times as day. Thankfully there are tools which allow the whole process to be scripted. This can cover everything from defining the virtual environment that the application runs on through to the software itself.

CI/CD Summary

In business today success is often governed by how quickly the organisation can produce the next iteration of their product, it’s so important it has its own technical term called cadence. Let’s be clear, if two organisations are identical other than for their rate of cadence, the one with the fastest cadence will win.  This can be tracked back to the laws of evolution and the ability to react and respond the (commercial) environment.  

This has been a non-technical explication of CI/CD for executives, directors and managers. If you’d like to learn more about this there are a number of good books on the subject.  The best place to start is Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.