What's CI/CD?

CI and CD are philosophies for building and deploying apps quickly and safely.

devops

Last updated: July 4, 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

UI

Open Source

Server

Cloud

Framework

Compile

Integration

Production

Continuous deployment (CD)

Continuous integration (CI)

Deploy

Version control

React

Companies Mentioned

AWS

$AMZN

Datadog

$DDOG

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 increments that are unlikely to break things and help isolate where (if!) things go wrong. This is what the integration in CI means: integrating your new code with the existing codebase.