In a sense, you could call continuous integration the lifeblood of modern software development. So it stands to reason that you'd want to avail yourself of continuous integration tools. But before we get to the continuous integration tools themselves, let me explain why I just made the claim that I did. How do I justify calling continuous integration the lifeblood of software development? Well, the practice of continuous integration has given rise to modern standards for how we collaborate around and deploy software.

What Is Continuous Integration?

If you don't know what continuous integration is, don't worry. You're not alone. For plenty of people, it's a vague industry buzzword. Even some people who think they know what it means have the definition a little muddled. The reason? Well, the way the industry defines it is a little muddled.

The industry mixes up the definitions of continuous integration itself, and the continuous integration tools that enable it. To understand this, imagine if you asked someone to define software testing, and they responded with, "oh, that's Selenium." "No," you'd say, "that's a tool that helps you with software testing -- it isn't software testing itself." So it goes with continuous integration.

Continuous integration is conceptually simple. It's a practice. Specifically, it's the practice of a development team syncing its code quite regularly. Several times per day, at least.

Merge Parties: The Continuous Integration Origin Story

To understand why this matters, let me explain something about the bad old days. 20 years ago, teams used rudimentary source control tools, if any at all. Concepts like branching and merging didn't really exist in any meaningful sense.

So, here's how software development would go. First, everyone would start with the same basic codebase. Then, management would assign features to developers. From there, each developer would go back to his or her desk, code for months, and then declare their features done. And, finally, at the end, you'd have a merge party.

What's a merge party? It's what happens when a bunch of software developers all slam months worth of changes into the codebase at the same time. You're probably wondering why anyone would call this a party when it sounds awful. Well, it got this name because it was so awful and time-consuming that teams made it into an event. They'd stay into the evenings, ordering pizza and soda, and work on this for days at a time. The "party" was partially ironic and partially a weird form of team building.

But whatever you called it, and party favors or not, it was really, really inefficient. So some forward thinking teams started to address the problem.

"What if," they wondered, "instead of doing this all at once in the end, with a big bang, we did it much sooner?" This line of thinking led to an important conclusion. If you integrated changes all of the time, it added a little friction each day, but it saved monumental pain at the end. And it made the whole process more efficient.

The Simplest of Continuous Integration Tools

So far, this really just sounds like a policy. "Let's all make sure to deliver our changes multiple times per day, and also pull down everyone else's changes." How does this translate into tooling?

To understand that, let's do a thought exercise. We'll build the simplest imaginable continuous integration setup.

As you write your code, you commit your changes regularly. To pull other people's changes, you write a little shell script that updates/pulls changes from the team's source control. You just kick it off in the background while you work, ensuring that you have the latest code every hour or so.

That's it. You now have the world's simplest continuous integration tool.

The Evolution of Continuous Integration Tools

Of course, full-featured continuous integration tools do a lot more than this. I just laid that example out to help you understand the core principles of the practice of continuous integration and then automating it.

Actual, modern continuous integration tools add something important on top of the simple concept of frequent integration. They layer on the concept of the build. Continuous integration as a practice just keeps everyone's code in sync. Continuous integration tooling keeps the code in sync, but also builds that in-sync code, packing it into something that you can deploy.

In this fashion, the continuous integration practice has evolved a lot with the tooling that supports it. Developers deliver code frequently, and, when they do, their continuous integration tool builds the software and executes other activities as well, such as running automated tests and static analysis.

Continuous integration tools thus ensure that the software stays in sync and also that the software remains in a perpetually deployable state (theoretically, anyway). It does this by responding to compilation or test failures with the concept of a failed build. If a code commit triggers a build failure, the team leaps on it quickly, getting the build back to a passing state (green).

Let's now take a look at some popular continuous integration tools. Many such tools layer on other features as well, but this concept lies at the core of all of them.

Jenkins

Jenkins is arguably the most well-known tool out there. It is an open source tool, and it bills itself as an "automation server." Make no mistake, though. Continuous integration lies at the absolute heart of its value proposition, notwithstanding other capabilities that it offers.

Jenkins is a Java-based tool, and it will run on Windows, Mac, or Linux (and other NIX) operating systems. But you can use it for all sorts of tech stacks -- not just Java. It's easy to install, has a nice web interface, and has an extremely rich plugin ecosystem. This means that you can use it to automate all sorts of tasks that you might need as part of your build.

Oh, and it's free.

Travis CI

If you're wondering, the CI in Travis CI stands for continuous integration. So that should give you some insight into the tool's bread and butter.

Travis CI has been around for a long time and it offers a hosted solution as well as something you can install onsite if you don't want them hosting your code. It caters to the enterprise and it sports some nice integrations, such as with Slack and HipChat.

You can use Travis for free if you have an open source project, and it's trivial to get started if you store your code on Github. If you want to use it for your private repo, you can have 100 builds for free, but then you will have to pay.

Team City

Team City comes from popular dev tools company JetBrains, and it bills itself as a "hassle-free CI and CD server" (CD standing for continuous delivery). Since it comes from JetBrains, it is both a mature product and one for which you can expect support.

Like Jenkins, Team City is a Java-based tool, but it is well known for offering excellent support for .NET projects as well. This combination of tech stacks tends to make it popular in enterprise environments.

Team City is quite customizable and extensible, and it comes in free and paid versions.  You can use it for free for relatively lightweight build scenarios, but after that, it has a paid licensing model.

Team Foundation Server

Microsoft has a suite of tools called Team Foundation Server (TFS). TFS has evolved over the years, and it actually provides a lot more than just a continuous integration server. It also includes source control, deployment technologies, issue tracking, and a number of other tools besides. But it does offer CI.

Team Foundation Server really shines in a heavily integrated Microsoft environment. So if you have a shop that uses Microsoft technologies exclusively, this may be the choice for you (though TFS does now support other tech stacks as well).

TFS is a paid tool, though its licensing is somewhat complicated. You can buy it outright, or you can take advantage of licensing models that include other Microsoft offerings, such as MSDN subscriptions.

Getting in the Continuous Integration Game

I've honestly just begun to scratch the surface of tools available to you. This is a space with a lot of different tools competing for your business, which should say something to you about its importance and prevalence.

But if you're new to continuous integration and continuous integration tools, I'll leave you with this advice. The set of tools can be overwhelming, but it's more important to pick one and to get started than it is to pick the perfect one. As I said at the beginning of the post, continuous integration is the modern lifeblood of our industry.  So just make sure you get started and realize the efficiency and professionalism that you'll get from doing it.