Hunt down buggy .NET code faster
Wednesday, January 04, 2006 01:48 PM
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.
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.
There are currently no comments for this post.