Why CI?

Monday June 19, 2017
Software Development

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.