What the Hell Is CI/CD?
A Plain-Language Guide for Everyone Who’s Nodded Along in Tech Meetings
Let’s turn back time to 9 years ago.
On October 04th, 2016, I was enjoying a playful orientation day at my new company.
The next day, I was suppressing a stroke trying to understand countless terms and even more abbreviations.
Two of those were destined to haunt me for the next couple of years:
CI/CD
Build Pipeline
Scary-sounding concepts, wrapped in intimidating tools.
But, as with most concepts, their scary masks crumble once we start understanding and using them.
Today, I’ll spare you from figuring out these concepts by yourself, using the voice of a non-techie.
The Agony of Late Realization
As we are already time-traveling, let’s rewind a bit further. Before Agile became the next big (s)hit, developers were developing monolithic monsters of code.
Imagine a mason. We’ll call him Jason (yeah, I know).
So, Jason the Mason, talks to his customer, Bustimer. Bustimer has a very specific picture in mind: A statue of a man raising his middle finger in triumph.
Bustimer has an ongoing feud with his neighbor and wants to install the statue in a place that is prominently visible from the neighbor’s lawn.
Jason has a sense of humor, so he scribbles an image, gets it approved by Bustimer, and immediately starts hammering away.
The statue will be 2 meters tall (for my US-friends: that’s 6,56168 feet). Jason will craft it out of a single big granite block.
The Totally Unexpected Story Twist
1 year of blood, sweat, and suspicious chuckles later, Jason is almost done. While he is polishing his newest monstrosity, Bustimer calls him.
“Jason, change of plans! I made peace with my neighbor. Turns out, he is a veteran! Go figure! Please change the arm with the middle finger into a salute. Oh, and can you change the facial expression into something more respectful?”
1 year of work, down the drain. Jason has to start from scratch.
This is what developers did before Agile and CI/CD.
Define your requirements for the next year or so.
Specify the features and User Interface with as much detail as possible.
Write the code for the whole thing.
Debug and test the whole thing.
Deliver it to the customer and realize you wasted a year of work on something not needed.
What is CI/CD?
So, CI/CD is a tool that allows masons and developers to create saluting statues?
Well, not quite. Masons have to be strong now: CI/CD probably won’t help you with that granite block (sorry, Jason).
Anybody else who is interested in a tech career: Keep reading.
CI/CD is short for Continuous Integration and Continuous Delivery, and contributes to one simple principle:
Instead of developing one big block of code, break down the monolith into smaller fragments.
Imagine Jason again. But instead of creating the statue from a single block, he chisels every body part individually and puts them together in the end.
Wouldn’t it be neat to just replace the head and the arm instead of starting completely from scratch?
Sprinting From Delivery to Delivery
Translating this to software would mean breaking down the product into small features. Each one of these features should be deliverable at the end of a short period of time, usually two weeks. Scrum masters call these periods Sprints.
At the end of each sprint, a development team specifies the feature, writes the code, tests the code, and delivers a usable part of the product.
The upside? Quick reaction times! Product managers and customers can use the features and provide feedback. Instead of waiting for a whole year, you receive feedback on the fly.
You adapt only the parts that don’t work - in the very next sprint.
And the main concept that enables such quick delivery efficiently?
Continuous Integration and Continuous Delivery!
What Does CI/CD Look Like in Practice?
How does the concept behind CI/CD come to life? After all, a principle alone will not get your product shipped quickly.
We need tools for that.
Continuous Integration
Continuous integration revolves around all the processes and automated tools that help you maintain high-quality code.
As we’ve already established, we want to create our software piece by piece. Hence, a complex software product consists of several software modules. Each software module is developed by its own development team.
When a developer starts implementing a new feature, a typical process looks something like this:
The code of Software module A is stored on a server.
All files and the folder structure are versioned. That means that whenever someone changes the code, the version number of each affected file is increased.
The folder of the entire software module under version control is called a repository.Greg wants to add a new feature. But to protect the code on the server from faulty additions, he cannot just change the code on the server directly.
Greg clones the repository to his computer and creates a separate branch to work on his changes. The original version is called main.
He does that by using a version control tool like Git or SVN.Greg changes the code on his computer. Once he is done, he wants to integrate his changes into the main repository on the server.
This process is called merging.
But he cannot just overwrite the existing main directly. For safety reasons, he needs to pass some quality measures first.Typically, his branch is automatically built (compiled) and tested on test servers, e.g., for bugs or interoperability with other features. When the compilation fails or the quality criteria for the automatic tests are not met, he is not allowed to merge his changes into main.
On top of these automatic tests, a merge usually requires a code review by another developer.
Only when all of these quality measures are met, Greg is allowed to merge his branch into the main.
Such vigilant safety measures are crucial for fast-paced deliveries. Imagine the chaos if every developer were allowed to make any changes directly to the master code?
These processes and tools make sure that the main repository is in a release-ready status — at all times!
Which brings us to the next phase.
Continuous Delivery/Deployment
With all of the various software modules kept clean and release-ready at all times, we are good to release the product almost at will.
Almost, because there are a few things left.
While the individual software modules work fine, we don’t know yet whether they are compatible with each other.
CD often includes integration testing and packaging of the full product. It ensures all modules still work well together, not just in isolation.
To ensure compatibility, tools for continuous delivery build the entire product with all of its software modules at specific times, e.g., every night or right before deliveries.
This allows the different development teams to fix broken interfaces and make sure the complete product works — not just its parts.
Next, we can finally ship the products. And this is where the difference between Continuous Delivery and Continuous Deployment becomes important.
They are often used like synonyms (just like I’ve done so far), but they aren’t.
Continuous Delivery is a concept in which the entire product is prepared for a release to the customer. But the final decision of going online with the product still lies with a human. Typically, a Product Manager would publish the product manually.
With Continuous Deployment, you mostly remove the human factor in the release process. Whenever a product passes all quality checks, it automatically goes online. Think of a website that is uploaded to the server the moment it meets all criteria.
And that’s the CD part of the equation.
Conclusion: Why CI/CD Is Not Just For Developers
CI/CD and the tooling that comes with it is a clever way of automating as many publishing and quality assurance processes as possible.
The goal is to
keep the code in a releasable state at all times and
release the product as efficiently as possible.
And that’s a crucial concept to understand, not just for developers.
Some other roles, like technical writers, product owners, product managers, UX designers, might get in touch with CI/CD tools.
Some, to maintain their part of the product, e.g., a technical writer creating a user manual in a Docs-as-Code environment.
Others may not directly use CI/CD tools. But even then, the significance of CI/CD makes it valuable for such stakeholders to understand at least the basics.
After all, you wouldn’t want to be the person whose feedback is dismissed simply because it is not aligned with the principles of CI/CD.
🚀 Coming soon: I’ll show you how to put all of this into practice using GitLab — from repo to working pipeline.
That hands-on tutorial will be available for paid members.
Why paid? Because it takes serious time to create step-by-step guides that are beginner-friendly and actually work.
If this free article helped you, consider upgrading — you’ll support my work and get access to more actionable content like this. 🙌
PS: I will use the Docs-as-Code sources we created in my last tutorial as a file base. If you want to catch up:
How to Build a Professional Technical Writing Environment (Using Free Tools)
Microsoft Word. We all know it, we all use it, we all either hate or love it.
Not an aspiring technical writer? No problem! While we will use user documentation as an example, the knowledge you’ll gain will transcend technical writing.