One aspect of team development is allowing individual
developers (or groups) to develop and build features locally before merging
with a central repository that incorporates all changes. Developers test and
debug locally with the latest version, and they still cross their fingers to
ensure everything works okay with everybody else’s work. They can manually test
it, but a better approach is automating the process to provide instant
feedback. One excellent solution is continuous integration.

Continuous integration

There are various philosophies for improving the production
and efficiency of application development teams. One such approach is called
continuous integration. A basic premise of continuous integration is instant
feedback. The simplest form of continuous integration is a developer working by
themselves because all changes are immediately visible. Thus, the individual
developer is aware of problems as soon as they manifest themselves. The same
approach is applied to a team environment, so problems are discovered in a
timely manner.

Weekly .NET tips in your inbox

TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET.

Automatically sign up today!

The best feature of continuous integration is cutting out
the time developers spend hunting down bugs when other developer’s check in
their work and problems arise. These bugs are normally very hard to track down
since the problem results in the integration of new code; integration bugs can
be inserted weeks or months before they make their first appearance. The time
spent tracking down these bugs may be better applied to other project tasks.
The key is finding problems sooner rather than later.

With continuous integration, the majority of bugs are
discovered when introduced and the culprit (i.e., the developer’s code) is more
obvious since they checked in the code that raised the errors. So, less time is
spent tracking down the error and other developers are free to tackle their own
issues. The net result is an increase in productivity, but this does depend on
frequent builds to provide valuable feedback to the developers.

When do you build?

I can remember working on projects a few years ago, and the
time and energy required to perform a build was extensive. Developers had to be
reminded to check in their code and the manual build process was intense.
Naturally, errors reared their ugly heads while building the code from the development
team. Time was required to track down and (hopefully) address the problems on
the path to success. The time required for this process led to less frequent
builds, but more frequent builds make it easier to take advantage of continuous
integration.

If you’re wondering what constitutes a successful build, the
answer depends on your project and environment, but I usually define it as all
source files compiling successfully, deployed, and a suite of tests execute
successfully against the system. You need to utilize a suite of tools to put
this to work, and automated testing is not required but highly recommended
(that is a topic for another time).

Tools

The following basic list of tools is necessary to get up and
running with continuous integration in a .NET environment:

  • Source code control: This allows
    multiple developers to work on application code by checking source files
    in and out and adding new files. Visual SourceSafe is a popular choice,
    but there are much better options available such as Subversion, IBM’s Rational ClearCase, CVS, and SourceGear Vault among others.
  • Compiler: You may utilize the .NET
    Framework’s command-line compiler, Visual Studio .NET, or another IDE.
  • Continuous integration server: This
    is the master controller of the build process; it monitors the source code
    repository for developer check-ins. When new code is added, the latest
    version is retrieved and the build process is kicked off. The final step
    in the process is notifying the team of the build status via e-mail, Web
    pages, and so forth. There are various products available, but I prefer CruiseControl.NET.
    Another option is the freely available Draco.NET. You’ll need a
    dedicated server for this piece of the puzzle.
  • Build automation tool: A tool is
    necessary to automate building of the source files. An excellent option is
    the freely available NAnt, or you can utilize a Make file. If you
    utilize CruiseControl.NET, its most recent version can talk directly to
    Visual SourceSafe so a build automation tool like NAnt
    may not be necessary.
  • Optional unit testing: Applying
    unit tests during the integration process helps verify proper functioning
    code. An excellent tool is NUnit, which is free and has a vast amount of
    information available online.

Note:
Installation and setup of these tools is beyond the scope of this article, but
each product’s documentation from the Web community provides the information
you’ll need to utilize these tools.

Are you ready to use continuous integration?

Continuous integration isn’t a cure-all for buggy code, but
it can definitely free up your time to tackle more pressing issues. Developers
still need to write solid code and good unit tests help. In addition, code
should be checked in on a regular basis (I prefer daily check-ins). However,
utilizing continuous integration can help validate the quality of your code,
tests, design, and so forth. While it will free up time normally allotted for
regular builds, you will need to set up and manage the server dedicated to the
continuous integration server.

Miss a column?

Check out the .NET Archive, and catch up on the most recent editions of Tony Patton’s column.