In recent years (and in some cases, for many years), Continuous Integration (CI) has been taking off. Almost any open source project you look at is using some kind of CI tool like Jenkins, TravisCI, or CodeShip. In the simplest cast, the CI server is just running unit tests. In more complex cases, the CI server runs unit and integration tests, produces a build, and maybe even deploys the software.

Some people are quicker than others to add CI tooling to their own workflow. To see the value in CI tools like these, you need to understand the problem they are solving. Fundamentally, CI tools are solutions for risk management. That is, they help engineers reduce the risk associated with developing and deploying code.

There are several different approaches to risk management. Perhaps the most basic is, “if it ain’t broken, don’t fix it.” In other words, if the code is stable and you don’t change it, you don’t need to take on any additional risk. And in that case, you probably don’t need CI either since you won’t be changing the code very often. This methodology works pretty well… Until it doesn’t. Essentially, it will continue to work well as long as the software doesn’t need to change (too much). Unfortunately, it breaks down when the software does need to change. And in the world of modern web applications, the software always needs to change. There’s always more traffic coming, APIs changing, or a competitor who’s innovating. Thus, avoiding change in order to avoid risk is not a viable strategy. In fact, after avoiding change for too long you start adding risk as the software “falls behind”, and changes become more difficult and complex.

Continuous Integration, essentially, is the solution to this problem. A CI pipeline is designed to enable rapid changes in the safest way possible. It does this by preventing code from being merged without passing unit tests. It does this by producing a deployable build in a repeatable manner. It does this by testing a build and ensuring that there are no regressions in functionality. And it does this by deploying the build to production in a safe and repeatable manner. A CI pipeline provides a pathway for developers to get their code into production in the safest manner possible. In doing so, it provides developers a way to quickly deploy changes to a code base with a minimal amount of risk.

When developers are afraid to make changes to a codebase, the code rots. Rotten code is more difficult, time-consuming, and risky to work with. Good CI prevents code rot by reducing the risk associated with any code change, which allows developers to make improvements and add features to a codebase with minimal risk, and therefore minimal fear. This is incredibly valuable, both to open source projects and to organizations.