What's CI/CD?
CI and CD are philosophies for building and deploying apps quickly and safely.
Last updated: March 3, 2025
The TL;DR
Continuous Integration (CI) and Continuous Delivery (CD) are philosophies and toolsets for shipping code: instead of big, infrequent releases, developers push and test code constantly in smaller batches.
-
Historically, it was expensive and risky to ship software, so updates were infrequent and bundled together
-
Cheaper servers and better tooling have changed the equation: now developers can ship frequently and test often
-
Continuous Integration means integrating and testing your code changes automatically, while Continuous Delivery means you deploy those changes often
-
Tools like CircleCI let developers write automated tests, monitor builds, and locate problems fast so they can iterate and fix quickly
CI/CD is quickly becoming the de-facto standard for how startups ship code, and is even (slowly) making its way into larger companies.
Terms Mentioned
Companies Mentioned
Big scary code changes
Not to sound like an old man screaming into the clouds , but software used to be a lot harder to write, for a lot of reasons – one of those reasons was the deployment process. There’s a big difference between getting software you’ve written to run on your laptop, and putting it on a server ready to support thousands (hopefully more) of users.
🧠 Jog your memory
Applications in the cloud are just a bunch of code running on big servers. Developers build software locally (on their laptops) and then push that code to servers when it’s ready to go.
A lot of the tools that developers take for granted today – think Github for managing version control , public cloud providers like AWS , high speed internet, and monitoring tools like Datadog – are actually pretty new. So just 10 or 15 years ago, if you were writing software, you’d need to:
-
Manage your remote repositories manually (no Github)
-
Run your own data centers, or rent someone else’s (no AWS)
-
Move code between locations slowly (no 1gbps internet)
-
Manually run tests and ping servers for monitoring (no Datadog)
In other words, deploying code used to be a real pain in the ass (it still is, but it used to be too). So it’s not surprising that developers would do it extremely infrequently: new features and bug fixes would get batched together and shipped as one monolithic unit (think: monthly timeframes or longer). This kind of sporadic integration and sporadic delivery helped avoid the annoying overhead of deploys, but came with its own baggage:
-
Infrequent releases mean products improve very, very slowly
-
Batching multiple features and fixes together made it difficult to isolate problems
-
Rolling back changes to fix a single problem meant eliminating an entire release
Over the past decade though, new tools and cheaper infrastructure have helped alleviate some of these core issues, and that in turn has enabled developers to integrate and ship a lot more often. That’s where CI/CD comes in; we’ll tackle each in a separate section, but the philosophy behind them is the same.
CI: integrate often
People often talk about CI as a tool or a framework , but it’s not: it’s a philosophy for how code should be written and shipped. Instead of developers working on self contained big features, they push code in modular increm...