Skip to content
August 13, 2010 / alausted

What is Continuous Integration?

We’ll start with a quote from Martin Fowler, who made the term Continuous Integration popular in a paper from the early 00’s.

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day.

He also states:

The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository.

As someone new to Continuous Integration, I did a bit of research and compiled it into this summary. Remember, that Continuous Integration is a practice and you don’t need to follow it to the letter. I do believe it is beneficial to think about these things in terms of: “Will it benefit my team/organization?”

Benefits of Continuous Integration?

Back in college I worked part time at the Juran Center for Leadership and Quality. I learned a bit about Quality, Continuous Improvement and began to believe in the ideas behind it. I would say that CI is one way to improve software quality on your team.

Continuous Integration helps:

  • improve quality and creates a stable build
  • errors to surface and be fixed quickly
  • reduce complexity of integration because it is done frequently
  • reduce defects and find them immediately while they are fresh
  • reduce the amount of time hunting down bugs caused by developers stepping on each other’s toes.
  • speed deployment
  • reduces integration risk
  • managers to know where you are, what works and what doesn’t
  • break down barriers between customer and development
  • measure progress daily

Key Practices for Continuous Integration as identified in Martin Fowler’s article:

  • Maintain a single source repository
  • Automate the build
  • Make your build self testing
  • Everyone commits to the main branch of code every day
  • Every commit should build the main branch of code on a build server/integration machine
  • Keep the build fast
  • Test in a clone of the production environment
  • Make it easy for everyone to get the latest executable
  • Make it easy for everyone to see what’s happening with the build
  • Automate deployment

Where to start with Continuous Integration?

If you’re like me, you’re new to this so where is a good place to start? First of all, have an understanding of the benefits and read an article or two. Once you’ve established it in your mind here are a few practical steps to start that shouldn’t overwhelm you or your software team.

1. Source Code Integration

Source code must be checked-in or integrated with a source control management tool. This is the place to start if the development team is not using a SCM.

2. Daily Check-in

Here we need to communicate to our team that at least once a day check-in is required and the source code repository should always be in a deployable state with no build errors.

3. Automated Build

Once your development team has source control in place and has communicated the idea of a daily build then it’s time to think about an automated build. An automated build can be done on each source check-in or it can be scheduled. Starting out, it is probably adequate to schedule your build nightly.

4. Automated Testing

Overtime, the team may want to start introducing unit tests that become part of the build process. Identify major areas where things go wrong or identify the most used code areas and write unit tests for them.

Feel free to leave me your comments and thoughts.

Sources:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: