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.
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.
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).
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.
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.