It's just one strategy that software development teams use to iterate quickly and ship new software.
The most popular software applications on the planet have a few things in common. They solve a real problem, they’re (usually) easy to use, and they offer a best-in-class customer experience. Sounds simple, right? Even if you’re just starting your career, you probably know that the opposite is true. In most cases, the “best” apps are often sophisticated projects that require ongoing testing and software updates.
This puts programmers in a tricky position. Business leaders really want to get their products to market as quickly as possible, but it’s virtually impossible to release stable code without a sustainable testing process in place. In response, many teams rely on continuous integration (CI), a software development practice in which individuals commit changes into a central repository multiple times per day. Although this idea was originally conceived in the early 1990s, CI has entered the mainstream over the last few years. A recent study by DigitalOcean found that 58% of developers reported using a CI process at work.
With so many companies using CI today, it’s important to understand its nuances as you begin your career. In this post, we’ll give you a high-level overview of how continuous integration works, as well as some best practices that will help you stand out from Day 1.
We’ve established that one of the key principles of continuous integration is that developers commit multiple changes per day to a shared repository. But what happens next? And what’s the point of all of this work? At first glance, CI sounds like a really good way to generate a lot of bad code from a team of developers. And to some degree, that’s true. But the basic mechanics of continuous integration are really interesting.
Let’s start with what happens after developers commit changes in a CI environment. A typical continuous integration involves a series of automated systems and tests. When a developer commits new code, that prompts the automated system to create a new build of the source code, which is then run through a series of tests. If the system detects any errors, the entire development team is notified.
OK, that sounds neat, right? But why does it matter? Ultimately, this reduces the need for a lot of manual work. Without a CI process, developers would constantly need to coordinate with each other to avoid working on the same feature and committing conflicting code. With a continuous integration process in place, multiple developers can work on the same feature at the same time. Not only does this reduce friction, but it makes it much easier for teams to resolve customer issues and ship software updates quickly.
Continuous integration is just one strategy that software development teams use to iterate quickly and ship new software. The word “continuous” can be found in a variety of software development practices. This can lead to a lot of confusion, especially since many teams practice all of them.
Before we go any further, let’s take a closer look at some of the strategies that are often associated with continuous integration. Many of the following definitions will look similar, but it’s important to understand their subtle differences as you begin your first job.
In 2006, Martin Fowler wrote one of the first whitepapers on continuous integration. Today, Fowler’s whitepaper is still recognized as an authority on the best practices of CI. Many of his guidelines are geared towards engineering managers that are considering implementing a continuous integration process, but there are also a few tips for individual contributors.
While we’ve talked through a lot of the technical nitty-gritty of continuous integration, let’s take a closer look at a few of Fowler’s suggestions for individual contributors in a CI working environment. We’ve gone ahead and distilled some of his thoughts for the sake of brevity, but you can also read his entire whitepaper here.
The concept of continuous integration is fairly straightforward, but it can seem like a daunting task for any new developer to adhere to. But with a strong understanding of the basics of CI and how developers prefer to work together, you’ll find it easier to get up to speed quickly and endear yourself to your new teammates.
That was a lot of information to digest. If this guide made continuous integration seem a bit intimidating, don’t worry—you’re not alone. Even some of the most experienced software developers shudder at the thought of committing changes so many times every day. While you’re bound to make a few mistakes along the way, here are a few tips for anyone doing CI for the very first time:
Above anything else, don’t forget that you were hired because you can write quality code. Although there’s a lot to know about CI, trust your instincts and jump right in. You’ll probably learn some tough lessons, but eventually continuous integration will become second nature to you. Plus, if you get lost along the way, you can always refer back to this guide.
Rich Moy is a freelance writer. You can find his work on AngelList, Stack Overflow, and The Muse.