Learn how to use XP (eXtreme Programming) techniques to improve the way you deliver software

In my book, "eXtreme .NET," I introduce a team of developers who are learning how to improve their ability to deliver great software. In this article, you'll follow this team as they learn about a new tool to help them develop software solutions using the .NET Framework. The tool they are going to explore is called Cruise Control and it helps the team continuously integrate their code.

Set up a tool called Cruise Control to do automated builds and provide feedback about the state of the build.

This team consists of the following members:

  • eXtreme Eddie: Eddie has been programming for more than 20 years. He has done everything from mainframe work through embedded systems. Eddie was an early adopter of XP techniques and has been using XP in Java projects for the past couple of years. Eddie embodies the XP spirit.
  • .NET Deepak: Deepak is a young, smart coder. He graduated last year but has been using the .NET Framework since it first went into beta. Deepak knows and loves .NET. Deepak represents all there is to love about .NET.
  • Skeptic Sue: Sue has been in software development for 10 years. She has mainly developed Windows software in C and C++. Sue was promoted in her previous job to project manager, which she hated. She left and joined this team so that she could get back into developing software. Sue carries the scars from many failed projects and doesn't trust new ideas.
  • Panic Pete: Pete is very bright and comes up with amazing solutions for problems. He is the clown of the team. Pete has been writing code for 5 years but has never finished a single project he started. Pete panics when the going gets tough and verbalizes this panic. When this happened previously, he quit.
  • Customer Chris: Chris is the internal customer for the team. He works with marketing and the customer support team. Chris once tried to write some code for a training course. He didn't enjoy it. Chris is a people person: he loves engaging in conversation.

The team has been not been together for long but they have learned a few things about XP from Eddie. When Eddie first arrived he insisted on removing the cube walls to allow the whole team to sit in an open plan space. Each developer has their own desk, but often you'll find only half of those desks being used. The team has adapted quickly to use a technique called pair programming. When they are pair programming (or pairing), two developers will sit at one desk and work together on a single piece of code. This allows the team to learn from each other more than they ever did before. The open plan space helps them to work much more closely as a team. One of the benefits of team programming is that conversations can be overheard and help more readily given to resolve issues.

Imagine yourself, CoDe Magazine reader, as a fly on the wall of the workplace. From this perspective, you can see how the team works together and learn the lessons they are learning. You might also spot some things they are doing wrong or that you would do differently.

Your task as the reader is to think about what thngs you would do the same or differently if you were on the team; maybe the team can change the way it is working and improve. Don't hold back?anything goes here. I want you to tell me your opinions and I'll use them in the next installment of this series. (There is an advantage to a publication that gets published every other month.) If you think that a team member should be fired, let me know. If you think they need to hire new people, let me know. If you think they should cancel the project, let me know! Send your ideas to ideas@extreme.NET.Roodyn.com. The best idea (in my opinion) will win a one-year subscription, or an extension to your subscription, to CoDe Magazine.

This team will also learn to use new tools through the course of their project. From your position as an observer, you will be in an excellent position to see how the tools might suit your own needs.

Let's join the team now as they meet to discuss their new project.

Customer Chris: Hi, everyone; how are you doing?

Team: Hey, Chris.

eXtreme Eddie: I think we're doing pretty well; we finished the last few tasks on the project yesterday and we are waiting for feedback on that now.

Panic Pete: (Laughs nervously.) Yah, I hope it's ok. I didn't do much work on that project and I'd be stuck if I have to do any maintenance on it.

.NET Deepak: Relax Pete, I know most of it quite well. I can help you.

Panic Pete: (Sounding a bit relieved.) Thanks man. So what's next? Is there a new project for us, Chris, or can we kick back for a few weeks?

Pete grins a wide cheesy smile to the whole team, knowing full well that Chris has got a new project lined up for them.

Skeptic Sue: Hey Pete, get with the program, this is serious. You know we've got the contract to develop a solution for SportSPeak.

.NET Deepak: Cool. Aren't they the life coaching and training company?

Customer Chris: Yes, they do a lot of things: outdoor adventure training, motivational training, personal life coaching.

eXtreme Eddie: So what do they want? Just a Web site?

Customer Chris: Well, sort of. They have grand plans for content delivery and also some smart client applications for their customers. I am meeting them tomorrow to discuss priorities and work out the best way to deliver the iterations to them.

Panic Pete: So what exactly is the point of this meeting?

Pete casts another grin around the room, to which Sue responds with a hard stare.

eXtreme Eddie: Ok guys, enough already!

Customer Chris: I want to make sure you are ready to start work on this project in a few days when I can sit down with you and go through the requirements.

.NET Deepak: Oh, so we have some time to kick back?

Deepak winks at Pete. Sue puts her face in her hands.

eXtreme Eddie: Actually we do have something to do in the next couple of days. We're at what is known as iteration zero. We can get our development environment set up, and make sure we are fully prepared to start work on the first iteration of the new project.

Panic Pete: I've already got Visual Studio .NET installed. What else do we need?

eXtreme Eddie: Well, what about a source code control system, automated build scripts, the build machine, task tracking, and all that stuff?

Panic Pete: (Sounding stressed.) Panic! We haven't had to do this before.

Skeptic Sue: I think what Eddie suggests makes some sense! We can get it all set up so we are ready to get started as soon as Chris has worked out all the requirements with the customer. Oh, and don't forget we'll need a bug database.

Panic Pete: (Sounding stressed.) Again, this is different than before.

Customer Chris: Sorry, did you say bug database? What do you need that for? Are you planning to write bugs?

Skeptic Sue: Of course we won't try to write bugs Chris, but they will occur and we'll need somewhere to record them and their solutions.

eXtreme Eddie: Actually I'm not sure if we will need a bug database yet; it depends on the scale of this project. I'd like not to have somewhere bugs can hide and be hidden. Bug databases can be abused. We should aim to fix bugs as soon as they discovered so we can move forward and deliver a zero defect solution.

Panic Pete: (Sounding more interested.) Cool, I've never written a zero defect solution before. Does that mean totally bug free?

eXtreme Eddie: It means it has no known defects or bugs. I believe it is possible to write bug free code if we don't let the bugs multiply.

.NET Deepak: Sounds ideal.

Skeptic Sue: Um... sounds a bit too ideal. But if Eddie thinks it can be done then I'll give it a go. If we get to a point where there are more bugs than we can fix, then we'll need a bug database.

Customer Chris: If you get to that point, you might not need a bug database! (grins) OK, I've got another meeting to go to, so I'll see you all soon.

eXtreme Eddie: Ok, I'd like to look at setting up a third-party tool I've been exploring called Cruise Control to do automated builds and provide us with feedback as to the state of the build.

Skeptic Sue: Can I pair program with you on this? I've never used Cruise Control before.

eXtreme Eddie: Sure, let's do it.

Exploring Cruise Control .NET

CruiseControl.NET consists of a number of small applications that help with automating the build and test process. At its core is the CruiseControl.NET server that monitors a source control database (SourceSafe for this team) and commences a build each time a new file (or files) get checked-in. Cruise control also provides tools to allow the development team to receive feedback on the current state of the build. This way if a build doesn't complete or tests are failing, the whole team can be aware of this and take action to correct the issue.

Publish the build results to a log in order for the Web application to read.

After a quick coffee break we find Sue and Eddie together at Eddie's development PC as they start working on setting up Cruise Control for the new project.

Skeptic Sue: What do we need to get Cruise Control up and running?

eXtreme Eddie: Let's start with the Cruise Control software. The latest version is 0.7 and we can get that from their Web site at http://ccnet.thoughtworks.com.

Skeptic Sue: Ok, got it. It's a zip file with a bunch of files in it. Where do you want to install it?

eXtreme Eddie: I'll create a directory on this computer to put all of our project files into. For the moment, put the zip file in a C:\Projects folder.

Skeptic Sue: Ok, now I'll create a subfolder for the SportSPeak files, so we'll have C:\Projects\SportSPeak\.

eXtreme Eddie: Great. I'll unzip the Cruise Control files into that directory.

Skeptic Sue: Ok, now what?

eXtreme Eddie: Well, from what I read in the product specs, I think there should be a server-side program to run. That program will carry out our build process. I expect it is called something like cc.exe or ccnet.exe.

Skeptic Sue: It's probably in the server directory that we just unzipped.

eXtreme Eddie: Yes, there it is: ccnet.exe. Let's run it.

Eddie double-clicks on the ccnet.exe file. A command window appears, some text scrolls down it, and then the command window vanishes.

Skeptic Sue: Oh, I guess it's done.

eXtreme Eddie: Hmmm. Something doesn't seem right. Hold on. Let's do that again in a command window.

Eddie opens a new command window, navigates to the C:\Projects\SportSPeak\CruiseControl.NET\Server folder and types ccnet.exe, then hits the Enter key.

Eddie and Sue see the screen shown inFigure 1.

Figure 1: Running CCNET.exe for the first time.

Skeptic Sue: Well that's still not so good, is it?

eXtreme Eddie: Nope, but it tells us that we need to have a configuration file.

Skeptic Sue: How do we know what that should look like?

eXtreme Eddie: Just a hunch, but I'll bet it is an XML file. Let's look in the Doc directory for some help.

Sue and Eddie browse through the HTML documentation files for a few minutes before coming across a file that looks like it has the information they need. It is located in C:\Projects\SportSPeak\CruiseControl.NET\Doc\CCNET\Configuring the Server.html. Using this information, they build a very simple configuration file, as shown inListing 1.

When Sue runs ccnet.exe in the command line, she and Eddie see the output shown inFigure 2.

Figure 2: First successful run of CCNET,

eXtreme Eddie: Cool!

Skeptic Sue: My guess is that we'd press Control-C to stop it.

eXtreme Eddie: Yeah, try it.

Sue presses CTRL-C and the application stops running.

eXtreme Eddie: Let's try that again.

Eddie runs ccnet.exe again and this time it doesn't build because no modifications have been detected.

eXtreme Eddie: It would be useful if we could get it to rebuild each time while we are setting this up so we can see the effects of the changes we are making.

Skeptic Sue: I guess we need to change something in the triggers section; let's see what the documentation says.

They read further.

eXtreme Eddie: Here it says that we can use the forceBuildInterval trigger. That should do it.

They change the triggers section to read:

<triggers>
      <forceBuildInterval seconds="60" />
</triggers>

When they run ccnet.exe again, it rebuilds. They leave the program running and it continues to rebuild the application about once a minute.

Panic Pete: How are you guys getting on?

Skeptic Sue: Pretty good, actually.

eXtreme Eddie: Yah, we've got a simple Cruise Control script running and rebuilding the application every 60 seconds.

Panic Pete: Can I see the build results? Are they available online somewhere?

eXtreme Eddie: Not yet, but we should look at doing that next.

Skeptic Sue: OK.

Panic Pete: Cool!

Deepak looks over at the group.

.NET Deepak: Pete! Are you going to help me with this menu control or what?

Panic Pete: Yah, I'll be right there.

Pete goes back to working with Deepak, leaving Sue and Eddie to carry on setting up Cruise Control.

Skeptic Sue: How do we set this up to display results in a browser?

eXtreme Eddie: I think we need to somehow get IIS to use the Web folder in our Cruise Control folder.

Skeptic Sue: I know how to do that. Go to Control Panel and in the Admin Tools folder, open the Internet Information Services application.

eXtreme Eddie: OK.

Skeptic Sue: Now, expand the local computer folders, expand the Web site's folder and right-click on the Default Web Site icon. In that popup menu, select New and then Virtual Directory.

eXtreme Eddie: There's a wizard for this. You've got to love those guys at Microsoft; there are wizards for everything!

Skeptic Sue: We'll need to set an alias for the virtual directory.

eXtreme Eddie: How about CCNET?

Skeptic Sue: Sure, that'll do. Then browse to the C:\Projects\SportSPeak\CruiseControl.NET\Web folder to use as the virtual directory.

eXtreme Eddie: OK, what about access permissions?

Skeptic Sue: The default ones are fine; we only need to read and run scripts.

eXtreme Eddie: Great. That's it? Hmmm. Seems too easy! Let's see what the page looks like.

Eddie opens a browser and navigates to http://localhost/CCNET. The page comes up withServer Error Can't Find Log Directory.

Skeptic Sue: (Frustrated.) It doesn't work.

eXtreme Eddie: Maybe we need to publish the build results to a log for the Web application to read.

Skeptic Sue: OK, that makes sense. I guess that is another section in the config file.

Sue and Eddie browse the online Help for a few minutes before finding that they need aPublisherselement in their ccnet.config file. They add a section to the file after the build element:

<publishers>
    <xmllogger>
      <logDir>
C:\Projects\SportSPeak\CruiseControl.NET\web\log
</logDir>
    </xmllogger>
</publishers>

eXtreme Eddie: Let's run Cruise Control again and check that the file is being created.

They run ccnet.exe from the command line again and check that a file is created in the log's folder.

Skeptic Sue: That looks good. Does the Web app work now?

Sue refreshes the browser but the same server error appears.

Skeptic Sue: Drat.

eXtreme Eddie: Maybe we need to tell the Web application where to look for this log file?

Skeptic Sue: Let's look in the Web.config file and see if it's in there.

eXtreme Eddie: Yes! Look in the appSettings element. If there is a logdir key, we should change that to the path of the log file we just created.

Skeptic Sue: Well spotted!

Once again, Eddie refreshes the browser and this time a simple page is displayed, showing the build results, as inFigure 3.

Figure 3: Build results in a browser.

eXtreme Eddie: Hey, Pete! You can browse to the CCNET folder on my computer to see the build results!

Pete does so on the machine that he and Deepak are working on.

Panic Pete: Cool!

Pete and Deepak open their browser and navigate to the CCNET folder on Eddie's computer.

.NET Deepak: That is cool, but do we have to look at the browser each time we want to see the build results? It would be cool if we could have an application that monitors the build results.

eXtreme Eddie: I think you can do that. There is an application called cctray that runs in your system tray and notifies you of the build results.

.NET Deepak: Cool; how do I run it?

eXtreme Eddie: Hold on. We'll find out and let you know.

Skeptic Sue: Let's run the cctray app and see what it does.

eXtreme Eddie: OK

Navigating to the C:\Projects\SportSPeak\CruiseControl.NET\cctray folder on his computer in File Explorer, Eddie double clicks on the cctray.exe icon. A CC icon appears in the system tray and a notification bubble appears statingMonitor started. A couple of seconds later, an error message box is displayed indicating a socket exception: No connection could be made because the target machine actively refused it.

eXtreme Eddie: Maybe we need to set up the Cruise Control server application? Let's look in the Help.

The two Cruise Control investigators discover that they need to have the Cruise Control server running for the cctray application to run. They also find out that they should add a line to the ccnet.config file to indicate the Web server URL. They add this to the project element under the name element:

<cruisecontrol>
  <project>
    <name>SportSPeak</name>
    <webURL>http://EddiesMachine/ccnet</webURL>

eXtreme Eddie: Ok, Deepak you can run the cctray executable and in the settings, point to my computer. You should then get the latest build results.

.NET Deepak: Great. Thanks. That is so cool. Does it give me the test results as well?

Skeptic Sue: No we haven't gotten to that yet. I think that's the next thing for us to do.

eXtreme Eddie: I agree. It's important that we get the tests running every time we rebuild the system.

Skeptic Sue: Right. Let's see how we run NUnit tests from Cruise Control.

Once more, the two Cruise Control sleuths search through the Help files. They discover that they can add a Tasks section to the ccnet.config file to run NUnit tests. After the Build element and before the Publishers element, they add the tasks element:

<tasks>
  <nunit>
    <path>
C:\Program Files\NUnit 2.2\bin\nunit-console.exe
    </path>
    <assemblies>
      <assembly>
C:\Inetpub\wwwroot\SportSPeak\bin\SportSPeak.dll
      </assembly>
    </assemblies>
  </nunit>
</tasks>

Eddie runs ccnet and refreshes his browser. Sue and Eddie both see that something in their project is amiss, as inFigure 4.

Figure 4: A failing test.

Skeptic Sue: Hey guys; we have the tests running and one is failing.

Panic Pete: (Defensively.) It wasn't me!

.NET Deepak: What test? My cctray application shows a successful build.

eXtreme Eddie: Yes, we should really be using a build script from NAnt or something, as running the tests directly from Cruise Control only displays the results in the Web page. Right-click on your cctray icon and select Launch Web page.

.NET Deepak: Ok, it's the test we are working to fix at the moment!

Panic Pete: (Sighs.) Phew...

Skeptic Sue: We have a running version of Cruise Control, so I guess we should get this running on the build computer now, rather than just Eddie's computer.

eXtreme Eddie: Yes and sometime later in the project we might move over to using NAnt.

Skeptic Sue: I agree.

The ccnet.config file that Sue and Eddie ended up with is shown in Listing 2. Now that you have seen this team get started with their project, what should they do next? What tools should they use? What tools would you like them to explore for you? Let me know and your suggestions will be considered for possible future articles.