The Details: CI

Standardized testing for your code

Hello there, lovely subscribers. This week’s post is going to 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).

The first “Details” post covered ETL, and the most recent one covered data warehouses. As a reminder, if there are any topics you want to see me write about, just let me know! These details posts are for paid subscribers only.

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.