Open Source .NET Development [Electronic resources] نسخه متنی

Introduction

After spending all the time required to create a repeatable, portable build that includes automated tests, you obviously want to use all that work to its fullest potential. Continuous integration helps elevate the all-too-common "It compiles on my machine"problem. It is meant to help in team development environments. The larger the team and the larger the project, the more useful this type of automated integration becomes. If you have ever wasted a weekend trying to "get ahead," only to find that the project state in source control is not even useable, then you unknowingly have longed for Continuous Integration.

What Is Continuous Integration?

Continuous Integration (CI) is a term coined by the Extreme Programming portion of the Agile Development movement. Every developer is all too familiar with the pains of integrating his or her code or portion of the system together with everyone else's. This is usually not a pleasant experience because so much time has elapsed since the last integration process. Software, like many other things in life, is high maintenance, and if you do not keep up on the maintenance, the costs in the end could be much higher than the maintenance would have been all along the way. Continuous Integration is meant to give instant feedback upon committing code to source control. This allows integration problems to be seen and corrected early in the coding process. Many times this may mean a redesign of the architecture. It's better to catch any problems now and not after much time has been invested in the code.

Continuous Integration also provides a complete and automated build system. Once a developer checks in the changes to the code, the build is automatically started, and the results are distributed to the development team. Alternatively, you can schedule a build on a recurring basis. Using a proven automated building system not only saves on the time required to roll your own, but oftentimes also provides greater flexibility and extendibility and a larger feature set than a homegrown system. Most Continuous Integration systems have been in use for a while and have the kinks worked out. Because most of the systems are Open Source, many different developers work on the projects. This ensures that a system works in multiple environments and provides a large enough feature set to please many different developers and companies.

What Are the Benefits of Continuous Integration?

We have already seen the following advantages of Continuous Integration:

• Ensures a buildable project state in source control

• Exposes integration issues immediately

• Enables automatic backups of each build

• Enables automatic installation of every build for testing purposes

• Equips you with a complete automated build system

Beyond these surface benefits, Continuous Integration has a lot to offer. It allows for faster development by giving instant feedback. This alleviates a developer's fear of getting the latest code from source control, which might be in a useless state and might not even compile. Having spent the time creating automated and unit tests now pays off big by preventing a bug from entering or reappearing in the code base.

While initially hesitant about spending time on something that does not generate revenue, management generally loves Continuous Integration. This is due to the fact that the status of the project is pretty visible. A manager can easily scan an email message output from the Continuous Integration system and see the progress of the team and the status of the project. While some developers may view this as a downside, it is really an all-around win because management will now see how many projects and how much code the product really requires. Most of the code of a large system exists below the presentation layer of the user interface and is often never even seen. Continuous Integration can be a great communication channel between management and engineering.

The best ideas always are the simple ones, and Continuous Integration is a simple idea.. However, the power of Continuous Integration is in the many different features it provides taken together as a whole. Taking one feature of Continuous Integration alone often justifies using the system, but this is really missing the point. For instance, whether you subscribe to the Extreme Programming/Agile Development mindset, every development team sees the need for an automated and repeatable build process. NAnt alone can provide this, but comparing Continuous Integration to just an automated build process is like comparing Instant Messaging to email; similar technologies with completely different usages. At the end of the day, Continuous Integration is even better than the proverbial "break the build and bring in the doughnuts" rule.

How Does Continuous Integration Fit with .NET?

Continuous Integration can certainly be useful with any programming language or platform, but .NET and Continuous Integration go very well together. This is in part due to the fact that .NET development is rapid (not necessarily "Rapid Development" but just plain rapid). It's also partly because of the other Open Source .NET Tools like NAnt and NUnit that use the reflection and attributed programming features of .NET heavily.

There are a few systems (Hippo.NET, Draco.NET, and CruiseControl.NET) that not only support .NET but also were built with .NET specifically in mind. These systems were themselves implemented using .NET. Before looking at each of these systems in detail, first we must set up some criteria for evaluating them.

How to Evaluate a Build System

Many Open Source and commercial products address the issue of a complete build system: FinalBuilder (http://www.atozedsoftware.com/finalbuilder), Visual Build Professional (http://www.kinook.com/VisBuildPro/indexl), X-Unity (http://x-unity.miik.com.ua/Default.aspx), and the SourceForge front end from VA Software (http://www.vasoftware.com). However, most of these systems fall short of true Continuous Integration. Many features of a system could be looked at, but the ones we focus on in this part of the chapter are meant to help determine which Continuous Integration system is best for your environment.

Build System Support

The biggest concern with a Continuous Integration system is which build systems it supports. Of all the features of a Continuous Integration system, this one is premier because it would be the biggest thing for you to change. If you are already using a build system that Continuous Integration does not support, it may be worth your while to look at a different system. Any of the build tools discussed in Chapter 4, "Build Automation," would be a good choice, but NAnt is definitely the predominant one. Ideally, a Continuous Integration system would work with multiple build systems, but because of the tight integration between the systems, this is rarely the case.

Source Control Support

Another highly visible feature of a Continuous Integration system is the Source Code Management (SCM) system that it supports. It would be a large undertaking to change the SCM once a company is already used to a specific system. However, this is not as difficult as changing the build system because most SCM vendors realize the fiscal importance of being able to automatically import a competitor's SCM repository, with complete history, into their system. Still, this directly affects the developer's everyday task and the overall development cycle and should be carefully considered.

Unit Testing Support

This is almost an assumed feature of Continuous Integration because without Unit testing, it is not really Continuous Integration. Chapter 6 discusses Unit Testing in .NET and of course features NUnit. Many times, the Unit testing platform is closely linked to the build system used. For example, if the Continuous Integration system supports NAnt, it gets NUnit support for free. If it used csAnt, then csUnit would be an obvious Unit Testing choice.

User Interface and Output Formats

The useability of the system is definitely a big factor in selecting the system, although once the system is configured and working, it rarely needs to be reconfigured. What are used day in and out are the build output formats. If the output is well laid out and easy to read, then the system will work well for communication. The delivery of the output is also important, whether it is a Web page, email, or XML file. Figure 7-1 shows a design overview of the Continuous Integration systems.

As you can see, the client Windows applications usually use .NET remoting for displaying real-time results. However, depending upon the product, some results can be reported via email or over the Web. This does not require any installation of software and is very popular with management teams.

Community Support

Here is the resounding theme throughout Open Source and this book. Choosing between two Continuous Integration systems, if all else is equal (code quality, products supported, etc.), should come down to which one is better supported and has a more enthusiastically development community surrounding it.

Conceptual Design Overview

You will notice that all of the systems listed in this chapter are very similar in their design (see ".NET Continuous Integration Quick Comparison Chart" at the end of the chapter). The basic design is that a person on the development team sets up a Continuous Integration server. This usually is not the same machine that contains the source control repository because depending upon your configuration the Continuous Integration can be intensive and can even install and test the results of the build. Normally this is not desirable on the machine that contains you source code repository. Once the Continuous Integration server is set up and configured with a build schedule and a watch on the source control management system, then anyone can check or receive the results.