Continuous Integration has been steadily growing in popularity after having been introduced as part of the Extreme Programming practice in early 2000. Martin Fowler and Kent Beck were the first ones to introduce the term. From Martin Fowler's seminal article we can get a concise definition for the term as applies to software development:

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. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

The idea here is that it should take very little time to know that the collective body of code that the team is working on is in a good state. Since the code will - and should - change frequently, the whole team should know frequently that the changes being introduced are not adversely affecting the state of the code. Everything is checked using an automated build process that includes automated testing of the code going in and the product coming out of the build. Doing it in this way ensures a continuous flow, or continuous integration of everyone's work. Wikipedia also identifies some of the more fundamental requirements for continuous integration, including source code control, automated build tools, and more.

As Owen Rogers describes:

The practice of continuous integration represents a fundamental shift in the process of building software. It takes integration, commonly an infrequent and painful exercise, and makes it a simple, core part of a developer's daily activities. Integrating continuously makes integration a part of the natural rhythm of coding, an integral part of the test-code-refactor cycle. Continuous integration is about progressing steadily forward by taking small steps.

Integration should happen continuously, and continuously is more often than you might think. The frequency of integration will vary from project to project, from developer to developer, and from modification to modification. However, as a goal and a good rule of thumb, developers should integrate their changes once every few hours and at least once per day.

Why is this important?

Continuous Integration is important for your team because it reduces the time, cost, and pain involved in ensuring that your software code base is in a fundamentally sound state. If you integrate once per week, then it probably takes a full day for several members of your team to sort out all of the issues that come up during the process and before you have a fully working build. If you integrate every hour, it probably takes only a minute or two for the single developer who introduced a problem to recognize, fix, and re-integrate the final code. For any business, this means more efficiency, and ultimately more communication among the team.

By adopting the practice of continuous integration you can leverage some key benefits:

• When unit tests fail, or a bug is discovered, it is easy to quickly revert the code back to a working state because the changes to the code base are relatively small.
• Integration problems are detected and fixed continuously - completely avoiding the time, cost, and pain involved in integration at the end just before a release to QA
• Early warning of broken/incompatible code
• Early warning of conflicting changes
• Immediate unit testing of all changes - ensuring that everything is tested as quickly and often as possible
• Constant availability of a "current" build for testing, demo, or release purposes

And ultimately, the immediate impact of checking in incomplete or broken code acts as an incentive to developers to learn to work more incrementally with shorter feedback cycles. This then influences your team culture and working style, increasing your fundamental rate of flow and efficiency overall.

Changing a team philosophy to integrate on a rapid basis requires both practice and discipline. At the level of the individual developer, integration decision can be made at any point when the code compiles and all the unit tests are passing. The core practice that must be internalized by the whole team is learning how to write software so that you never stray too far from this point. If your tests are focused enough and you have a practice of refactoring regularly, then you should be able to stay very close to this point. This means that each developer is always in a position where they can commit their code and launch a new integration.

What will it take to get my team there?

Continuous integration is a process that can be adopted fairly easily. It takes two important ingredients: tools, and your team.

In order to ensure that every change is integrated, and that all integrations work the same way with consistent, reliable, repeatable results, you have to implement automation with a continuous integration server like Zed Builds and Bugs. There are dozens of tools available on the market to help you automate your builds, from the granddaddy of CI build tools to more modern implementations. Some of the key things that you should look for are:

• Easily integrates with your team's working environment. It should run on your operating systems, work with your source control tools, handle your source code language and compile requirements.
• It should be easy to set up and configure. If your team is not familiar with XML, then you should look to the tools that eliminate XML editing for setup and configuration of your builds.
• It should be capable of running multiple builds in parallel and running multiple build steps on different machines. You'll often need source code compiled for different operating systems, and the ability to execute steps remotely on different platforms will be crucial for some teams.
• It should be able to monitor your source control system, or receive notifications from source control so that you can set it up to automatically trigger a build for every change that happens to source code.
• If it integrates with your bug tracking system, then it can also trigger builds based on updates to bugs or it can update bug information after successful builds.
• It should be able to keep a history of builds so that you can track progress, or quickly retrieve the results from previous builds for comparison.
• It should be able to notify your team when something goes wrong so that you can be proactive and quickly fix any issues that arise in the build.

Zed Builds and Bugs handles all of these requirements and more. It integrates seamlessly with your team, and expands the power of continuous integration by including built in bug tracking, discussion forums, and wiki collaboration. It takes continuous integration beyond the build, and brings it to everything that your team does. Zed is used for both Open Source projects and for commercial software teams. Try the free 60-day trial to find out more about how Zed can integrate your team.

Beyond the tools is your team. Your team already has a build process in place right now. That process should be transitioned over to the continuous integration server so that it becomes automatic, repeatable, and reliable. Without having to worry about the build process, the next step for your team is simply to increase the frequency of their commits to source control. Commit early, commit often, and let the CI build server handle the automation and notification.

Slowly and surely as your team receives accurate and timely feedback from the CI build server, they will come to rely on it and they will increase the frequency with which they commit their code. Small fixes and tiny changes should be in the repository minutes after they have been verified by the individual developer. Larger changes and projects should be committed every day or even every hour as progress is made on the task at hand.

With solid tools in place, maintenance of the build becomes a thing of the past and your team is freed up to concentrate on what is most important.