Willy-Peter Schaub's Cave of Chamomile Simplicity

Rosario April 2008 CTP Investigation (Part 5) - Build

Continued from http://dotnet.org.za/willy/archive/2008/06/02/rosario-april-ctp-investigation-part-4-version-control.aspx.

I am hoping that my colleague Zayd will brief us on the Team Build environment and enhancements, which includes a new automated build system based on Windows Workflow Foundation (WF), dynamic build machine allocation and distributed build functionality.

Let's have a brief peek at the build environment improvements ...

Distributed Build

We select "New Build Definition" to see where the new features are hiding:

1. Define a unique build name
   
2. We set the source control folder to point to the release 3 folder, ensuring that only the one branch is pulled into the workspace of the build machines.
   
3. Selecting the next step, Build Defaults, reveals some of the exciting new features. The build controller is responsible for managing a pool of agents.
   
   If we select manage, we can manage the controller, defining more agents, number of concurrent builds and enable|disable the agent status.
   
   If we select an agent and its properties, we see the next exciting feature. "Tags" are used to match build processes to the agents. If you require a special build environment you can create a special tag, i.e. "Java Interop" and tag agents capable of building the special builds.
   
   ... and there is more!
4. Selecting the Process tab, we are faced with a completely new environment. I must admit that I was "gob smacked" when I first saw this dialog, because the days of tedious XML build config file fiddling seem to coming to an end.
    
   The next steps defines the next steps we have to do, i.e. select the solutions and/or projects to build, and the tests to run. When we select the hyperlinks, we are beamed over to the relevant property field, in this case BuildProjects and TestProjects, where we define the solutions and/or projects and the vsmdi file containing the test configuration.
   
   We then select the "Select an Agent and Build" node, where we expand the ReservationSpec node. We can now define the tags that this build requires, i.e. x86 and .NET 3.5, for example.
    
    
   From the toolbox we can now drag activities and actions to our build template. For example, we drag a ParallelActivity just after the Update the Build Number and Drop Location activity ...
    
   ... which allows us to define parallel activities.
    
   We would typically move the "Select and Agent and Build" node to the one "Do in order" node, then copy and paste the node to the second "Do in order" node, creating parallel elements of the distributed build. One element could build a debug version of the solution, while the other builds a release version of the solution.
   ? We stumbled across an error when trying to copy a node in the build process editor. Keep an eye on our Q&A post, in which we will report on a resolution when available. (Fixed ... se Q&A Post)
   
5. The build definition is the same ... thought I would spot a new build type ... watch the space in future CTPs.
   
6. The Retention Policy is also as per 2008 build definition.
   
7. And there is even more ... you can select "Edit Build Definition" by right-clicking the build definition and return to the same configuration environment. In the past this was the point where we had to checkout the build definition, then use tools such as the Build Sidekicks or in worst case the notepad editor to edit the XML definition file.

Queue Build

As the error in the build creation caused some headaches, we will proceed to queue and analyse another build, created using Brian's hands-on-lab notes.

The queuing of build also looks very similar ...
 

Build Log

... as does the build log.
 

If you are an analytical person, you would have noticed the "detailed report" link in the previous screen dump. Selecting this link opens the browser, loading a detailed build report, which displays a hierarchical view of the execution of the build, supporting the parallel activities.

Conclusion

Team Build has always been a scary environment for anything but the simple console application. Over time it has and is continuing to stabilise and grow in terms of features and productivity. Slowly but surely Team Build allows us to implement the automated build and testing processes and project teams should seriously consider the value of the "daily" build, the "solution pulse", indicating health and life of a solution.

My personal rating for the Team Build improvements in Rosario at this stage is:  / 5 smiles.

Next

... part 6 will look at Team Developer.