Let's dive deeper into CI. We’re going to look at what types of tests developers run in CI, how they integrate with version control systems, and where teams set up CI (on your own server, or in the cloud).
Refresher: What is CI?
Continuous Integration and Continuous Delivery (big words) are all about getting new code out into the wild as quickly and as securely as possible. CI is about the secure part – making sure that code is well tested and is going to perform on the stage exactly how you expect it to (or at least as close as we can get it).
Back in the day – especially before cloud delivered software became the norm – software upgrades were infrequent, difficult, and risky. It was hard to know if the new feature you built might cause something to break incidentally, and logistically, getting that new feature out to your users required some degree of coordination. Because of that, companies would batch new features and bug fixes together into big new releases.
As we started moving software to the cloud though, that all changed – upgrades started happening automatically and without notification. For example, when you’re using Gmail in your web browser, you’ll notice that Google is constantly changing and improving it, from how it looks to how you navigate around and even behind the scenes performance changes. You don’t click “update,” the stuff just continuously (see?) shows up.
🚨 Confusion Alert
Plenty of software still follows more traditional update models. For example, when you want to update iOS on your phone or MacOS on your laptop, you need to actively choose to download and apply the update. Plus, Apple bundles new features and bug fixes together. The same is true for updating the apps on your phone. For cloud software though – especially B2B – the standard is becoming this permissionless update cycle.
This shift was powerful for software companies – it let them iterate extremely quickly on the product, get new features out into the wild near instantaneously, and gather product feedback through experimentation.
What enables this lightning quick delivery is a new approach to testing and deploying software, or what you’ve been hearing about with this CI/CD stuff. In a nutshell:
- CI is the process of extensively testing every new unit of code you want to deploy, automatically and quickly
- CD is the process of getting your new, now-tested in the hands of your users automatically and quickly
Another way of thinking about CI/CD is as a process of automation: the manual testing and deployment that used to take so much engineer time is now making its way into code and SaaS. In this post, we’re going to dive deeper into both CI and CD, what they entail, and what engineering teams use to do them.
This post is going to go deeper into the CI part; but keep in mind that the two are intertwined.