Why Automate Builds?
Why would you want to automate your software development? Does automation offer anything beyond the "gee-whiz" factorlook, no hands! Companies like Microsoft have been using the practice of daily builds for years now. The process of integrating the components that go to make up a software product can be a complex, difficult, and frustrating ordeal. Development teams that are still using the manual approach will integrate infrequently, often only at release time. Developers work on their own machines and then copy files around the network to a central build folder or such like. The build engineer has the unenviable task of making sense of all the madness. Its all too common to see software that worked like a charm on Joe's PC falling into a heap when combined with the rest of the team's bits. Integration is painful, so the answer is to treat it like a trip to the dentistavoid it until you simply have to do it!
The trouble is, the longer you leave integration, the greater the pain when it finally comes around. Trust me, I know about this from my dental experiences (or should I say trauma). Prevention is better than having your mouth turned into an open-cast mining site. So, if we could automate the process, we could integrate or build whenever we wanted. At the very least, we could build daily and maybe more than thatcontinuous integration. Figure 1 illustrates how the number of source code changes increases over time.
Figure 1 Source code changes over time.
This is all well and good, but you may still be wondering why your customer should care about the pain aspects of integration. In one way, they aren't concerned about the team's journey into the inner circles of misery, but they do care about their software. Getting the software into a known good state and then keeping it there is one of the best indicators to the health of the project. The customer can see working software, albeit a bit rough around the edges, and the team has a benchmark. Integrating the software, running the tests, and getting the green bar of success from NUnit give the team the confidence to move forward.
Automating development is vital because it allows the team to integrate frequently and ensures the customer that the product has life. In the past, development teams have used a combination of script and make files to run daily builds. The last few years have seen the development of an XML-driven build tool: Ant. Ant is part of the Jakarta project and runs under Java. (We'll discuss more about how you can use Ant with .NET in an upcoming article.) As you might have guessed by now, Nant is a .NET port Ant.
Without further ado, let's meet Nant.