What's CI/CD?

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. 

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.