In keeping with the theme of focusing on good engineering practices, Continuous Integration is a practice that development managers, project managers and others in agile teams should insist their teams follow.? Continuous integration (CI) is a good way to allow your team to have fully integrated code without a lot of integration work at check in.

Agile Engineering Practices

Let?s start with what are probably considered basic engineering practices that agile teams should adopt.? Usually these practices are from the eXtreme Programming (XP) space.? Below is a listing of important XP engineering practices:

[login]

• Test Driven Development (TDD)
• Continuous Integration
• Team Rooms
• Pair Programming
• Small Releases
• Refactoring
• Collective Code Ownership

I believe most serious development shops would consider the XP practices a stepping off point.? For those shops wanting to move ahead, there is also the Software Craftsmanship manifesto.? This movement focuses specifically on making better software.? Below are the principles of this movement:

1.????? Not only working software, but also well-crafted software

2.????? Not only responding to change, but also steadily adding value

3.????? Not only individuals and interactions, but also a community of professionals

4.????? Not only customer collaboration, but also productive partnerships

?

Other good practices include loosely coupling your design, SOLID principles, which are beyond the scope of this article.? What follows are good practices to help your teams put continuous integration into practice.

Introducing the Practice

Currently, one would not consider a development shop legitimate unless they use source control software.? Source control software is very common, with a lot of open source options, and commercial options available.?

It is hard to believe that less than 10 years ago, ?some ?legitimate? shops would consider developing software without a source control system.? As source control has become a hallmark of any legitimate shop, it follows that good practices for teams using these systems have developed.? Continuous Integration is a cornerstone agile practice in regards to source control and teams.

As with all agile practices, the team needs to adopt this agile practice into their normal development process.? ?As a project manager, development manager, team lead, or anyone with influence in an agile team, the team needs to understand the practice before a decision can be made.? Your job, should you choose to accept it, is to explain the practice in a way that allows the team to make a good evaluation of how to use it.?

Your team should be using source control with one mainline code base.? While there are many ways to ensure your mainline is integrated, the idea is that the team is committing check-ins to the same line frequently.? ?

For instance, let us consider a team that has a main source code line, with a branch off the main line for a new project.? All developers on the team would be committing check-ins to the new branch.? In this example, there should be a CI process on the new development branch, to ensure integration of the new development.? A more comprehensive investigation of branching and merging practices is beyond the scope of this article.

Continuous Integration policy dictates that your team checks in code frequently.? Some teams will institute a policy that they must check in code at least once a day.? Others will ask team members to check less frequently.? The generally accepted rule is at least once a day.?

The intent is that the code that each team member is working on is not stale.? With all team members checking in frequently, your team is not at risk of checking in breaking code.? You would need to spend a lot of time debugging that code.

Assuming your team uses CI, this means that it is easier to get the most up to date code for all team members.? As continuous integration has become an accepted practice, it has been expanded.? Now running automated acceptance tests as well as unit tests on check-in may be done.? Some source control packages, also allow teams to enforce other policies, like tying check-in?s to stories.

Introducing CI to the team

Now that you have an understanding of CI, how can this be introduced to the team?? The obvious answer is to just do it!? But what does just doing it mean?? Let?s walk through the steps of introducing CI to a team not familiar with the concept.

Research

When starting out, make sure to research how to implement Continuous Integration into your current source control environment.? There are commercial packages and open source options out there to use with most common source control packages.? For instance, Cruise Control originally developed by Thoughtworks is a package that works across source control repositories, and is open source.? Many teams use this, so that might be an option to pursue.

Coming from the .NET world, I am familiar with Team Foundation Server (TFS)which ?has some CI out of the box.? It can be point and click.? But TFS does cost something, and it is probably at the higher end of ALM products.?

Build Manager

Make sure to appoint someone on the team as your build manager.? Find someone who is passionate about builds, and is a good problem solver.? Be willing to give this person the time and space to create good builds.

If new to the build tool, before creating the build, allow time for the build manager to train, and once trained the time to work on creating the builds.? The build manager can create builds that conform to what your team wants to include in CI.? For instance, they can integrate unit testing to CI, so that a suite of unit tests fire whenever code is checked in.?

Build Managers can also create other automated builds to help with other tasks.? For instance assuming your QA process dictates a separate QA instance for QA testing, the Build Manager can create a QA build to deploy to QA every time this is needed.? These are the types of things the Build Manager would do for the team.

What does ?Our? CI do?

Now that the team is set to CI, before the build manager can create the CI build, we have to decide what should be included in our CI process.? Keep in mind that CI is supposed to help the team integrate code often, to help them have a cohesive well integrated code base.

The team at the very least should run the unit test suites when the CI Build happens.? Walk through the flow of the CI Build with the team.? Here is an example CI for a team.? When a developer checks his code into the repository, the CI build runs, compiling the code, and then running the unit tests (which run using mock objects or some sort of in memory function, not against DB?s, file system, or anything else which could slow the build down). This team could also run against a code coverage tool, and then run your automated acceptance tests.

Those are some examples of what could be run in your automated CI build.? These are not requirements, but an example of the possible.? Keep in mind that the key ingredient here is that anything running is quick.? The tests running are not intended to be end to end type testing, but to ensure that nothing that was checked in inadvertently broke tests.

The team can go down a checklist of things that could be included and experiment with some of these.?? Here is a sample checklist of what could be included in the teams CI build.

• Unit Tests
• Automated Acceptance Tests
• Code Coverage Tool
• Code Analysis Tool (nDepend or something else)
• Automated notification of broken builds

CI Should be Done by Every Team

This listing of how to implement CI on your team is intended to help you start the practice of CI or Continuous Integration.? As your team becomes more familiar with this practice, it should help make other parts of the process like deploying to staging areas become easier.? As your code is always integrated, that process becomes less scary to do the more frequently it happens.?

Resources

Cruise Control (an Open Source tool for CI)

Hudson (another open source CI)