Lazy Developer : Agile

CI In TFS Orcas - Short Review

Jimmy — Tue, 12 Jun 2007 08:30:00 GMT

Last month I'm focusing almost only on Continuous Integration. Number of hours spent on that subject allows me to pretend be advanced. So far all my CI experience was limited to CruiseControl.NET (95%) and a bit of Team Foundation Server. A problem with setting up CI using TFS is well known and there is no need to talk about once more. That's makes me very frustrated as I'm pure Micfosoft-fobic (is that correct word?) and I feel dirty when I have to use something non Microsoft in my development. I exaggerate actually.

Anyway, when I've read about changes in TFS that are coming with Orcas, my first thought was "at least". Unlucky too many duties on my head doesn't allow me to try those new features till last month. Finally, when part of my daily job became setting up CI, I had time to sit down and see what's going on in Orcas TFS. After few hours of downloading Virtual Machine image and unpacking I've end up with 14 (yes, fourteen) gig virtual disk (and few gigs of base disk) and I was ready to run.

What is coming out of the box? I do presume that the same components will installed when one will do clean install. However because I'm lazy I'm using ready to use VM. First of all I didn't notice any big differences versus previous TFS version. I was expecting something shiny new that will be just "wow", not at all. I don't have previous TFS to make deeper compare at the moment, maybe will do that later. We can find new service, Team Build Service which is likely to be responsible for continuous builds, nice. We can also find a lot of stuff in SQL. Nine (9) databases in total are working as a data store for version control, build reports and who know what else. Of course we have also TFS itself.

After that brief check what's on board I was ready to play with. I took one of existing test projects, set up new project on TFS and added it to source control. Setting up build, agent and general TFS configuration to work as CI server was a piece of cake. Orcas provide us nice GUI which is something I definitely like in. Setting up build requires filling only a few fields including name, workspace we want to use, project file and of course trigger. What is a bit strange, we cannot select project file we want. Well, actually we can, it can be any file as long it is TFSBuild.proj. As you can see on the image somewhere around, there is a few options to set up trigger. However it's impossible to set up delay between commit and build. If one want to force a new build has to add it to the queue.

After first builds has come I went to project portal and problems has started. All build data collected during build processes are stored in a separated database or databases. Reports are using TFSWarehouse database and were not working at all. From the very beginning I've got security error from SQL Reporting Server. Resolving that takes me few hours. Probably one who is Reporting Server guru would be able to do that in 5 minutes, I'm not. When finally I've got reporting working, there was nothing on report. Since that moment I've made a few builds but none appear on report. Like I said, I'm not Reporting Server guru; moreover I've never used that, so forgive me ignorance here. Finally some builds appears on the report, but not all of them. Finally I was able to see all my builds on report after few hours. I was trying to find where this delay come from. I've checked all settings I could with no result. Today, when I was writing this post, I've started another build. Screen bellow shows comparison information provided by GUI from Orcas and report from project portal.

As you can see, there are some differences on that picture. Some builds are just missing. Latest one "On Commit_20070612.1" will probably appear on report tomorrow, if at all.

At this moment I gave up. I had some work to do and after two days of playing with TFS I've got nice but not working CI. In our projects we are using NUnit, NCover etc. With regret I had no idea how to integrate those with TFS. Of course one can say that we can migrate to orcas and start using VSTS testing and coverage but that's not the point. I also want to integrate other stuff I have in my CI such as Symian or FxCop. I do believe it can be done with a bit of work, writing some tasks, adding data to correct database and so on, but that's not what it is about. I was expecting solution that will allow me to use all the best from TFS, source control, work item integration, project portal and management with flexibility and expandability of CC.NET. So at this moment I was really disappointed.

As a summary. I think Microsoft done nice job with TFS, but I have feeling that it's just first part of project. For me seems to be some response for criticism about difficulties with setting up CI on TFS. So now it's available but not fully. Like something that has been added just to add something. I do believe that further release will be much more flexible and will allow setting up CI we all want to do. Then one can think about migration from other solutions to TFS.

I gave up at the moment, however I know I will return to that topic and I know I will do anything I can to prove that TFS can be CI I want to be. One day.

Continuous Integration #2: Versioning and deployment

Jimmy — Thu, 15 Mar 2007 11:32:00 GMT

Here we are in the second part of the cycle. In the first part I show basic concepts and first, simple build script that allows us to build our project on server. This time I will show how to configure automatic versioning and deploying the application to the test site.

Versioning

First of all let me explain what I mean by versioning. There are two projects in the solution I have created for purpose of the cycle and both of them have AssemblyInfo.cs files. Good practice is to set correct version numbers both for assembly and file. The default value 1.0.0.0 is a kind of things that screams that developer didn't care about versioning at all. Nevertheless, editing these files every time we are going to build application is even worse way around, especially when an application is built every time we commit sources. And even if not that, we can have a number of projects in a solution so it is just boring work and waste of precious time that can be spend much, much nicer, in pub with friends or so. From the other side, knowing the exact version number is also nice help during bug fixing, when we know in which version which bug has been fixed.

What then we can do, is to force our build server to set the correct content of AssemblyInfo.cs for us. Before we start that, I will add some extra code to our project that will display version of running assembly. So I have to add the following line in my only page in the web application I created so far:

And a bunch of lines in code behind so my code behind looks like below:

Similar code can be added to the library used by the web application, but I will stay on that one. As a result of that we can see version number, build type and build time displayed on the page.

Before we will start doing anything in our build script, let me write a few considerations about versioning.

Basically, version number consists of four part numbers: major, minor, build and revision. The major and the minor numbers are completely up to us and these not change so frequently to bother, whereas the build and the release numbers change every build. One of the popular schemas of setting version number is:

Major.Minor.yyMMdd.Release

Where YYMMDD means date when the application has been built and Release is a number of the release. These two values can be easily determined during the processing of the build script. First of them, date of the build, need some additional explanation. It's well known problem that when you will try to build application with version number set to something like 1.1.071121 you will get an error CS0647. Reason is that numbers in version are limited to 16 bit, which is pretty silly today. However this is separate problem and as mgrzeg mention on his blog, there are different ways to solve that. Personally I'm using date format ddMMy pattern instead yyMMdd but you can use any pattern you want. I saw also some idea to count the number of days from the project start date, or even distance from start date expressed as the number of full months and days (similar to mmdd). Anyway, in further examples I will use my standard ddMMy pattern.

The release number is much easier as there is no special pattern in common use. Instead of that we will take release number from the source control.

With that introduction we are ready to write target to our build script that will set up correct information for assemblies. MSBuild.Community.Tasks comes with help here with AssemblyInfo task. However, before we will be able to use this task, we need to prepare and gather all data for setting version information.

First let's set up a new property group to store all data in one clear form:

Then, we need to retrieve release number from the source control. We will change existing SvnCheckout task in the Checkout target we created in the first part of the cycle. Here is the snippet:

Only thing I change is one extra line that will take value of task's property "Revision" and insert it into Revision variable in the script.

Now we can create new target named VersionSetup where all information will be written to AssemblyInfo. Whole target code you can see on the snippet below.

We are doing a few things there. First of all we have to set this target depend on the checkout target because we need the actual revision value. Then we have to set up the build number according to the pattern described before using Time.Get task. This task is pretty simple and takes time formatted according to specified pattern and returns that to the script Build variable.

The Time.Get task I used comes from the Microsoft.Sdc.Common.Tasks set. This is another great set of MSBuild tasks. There are some tasks that are the same in both sets, but generally it is good to have both of them installed and included into the build script. You can find these tasks on the same page where the MSBuild.Community.Tasks are located (see resources at the bottom of the article).

Having all the data we can execute the AssemblyInfo task. There is number of attributes that allow us to set every aspect of the AssemblyInfo including COM visibility, the assembly description or all copyright info and other we could want. As the required parameters we have to specify the language we are using (CodeLanguage attribute) and location of AssemblyInfo.cs file (OutputFile attribute). Important is that this task will replace existing AssemblyInfo.cs file, so we have to specify all information we need in the build script. And small hint here, Guid number can be just copied by hand from the original AssemblyInfo.cs file created by Visual Studio. As you can see on the snippet, AssemblyVersion and AssemblyFileVersion attributes are composed of variables defined before in the property group. And finally I'm repeating the same task for second project in the solution. If there will be more projects we will have to add more tasks into this target to serve them all.

When we will place this target in execution order between the checkout and build we will have AssemblyInfo.cs created with information we want. To prove that we should run application on the server but ... we don't have application there. Yes, we have built solution that can be used and deployed manually to virtual server but we are building script to avoid that. So let's deploy now.

Deploying (simple way)

Right, deployment, we have two ways here to deploy application and make it available for testers or whoever we want to be able for. First way is the easy one and I will use that. In the first part of the cycle, when I was describing folder structure on build server I have created myproject\testsite folder. I made this folder as a home directory of the virtual directory on local IIS. In this situation I have to create deployment files and copy them to that folder.

Second, more complicated way is to use tasks to create virtual directory under IIS and configure all web server to point on correct location. If there will be need expressed in comments (*) I will describe that later in the cycle.

Ok, we have to prepare content to deploy before we actually do that. Let's add web deployment project to the solution we have. Then we can create the next target named Deploy that depend on the Build target of course. This target is pretty simple. With a Folder.Copy task (from Microsoft.Sdc.CommonTasks) we can copy all directory content including subdirectories. It's much easier than doing that with tasks included in the MSBuild by default. Only what we have to specify id source and destination locations.

Here, on the snippet above, we are copying content of the deployment project build to deployment directory, which is defined at the beginning by adding the following line to the property group right after the WorkingOutputs.

Putting all together

Now we can put all the pieces together and change the "All" target, which is target we are building, by adding new calls. Finally this target looks like on the snippet below.

After successful build we can browse to the url we have assigned to the deployment directory and see how our build script works. If everything has been done fine, we will page with nice version number and we will have the newest release available online every time build will be successful.

In the next part I will show how to add unit tests to build server. We may have to put some small modification for the tasks that ships with one of the sets. It will be some nice there so stay tuned.

Hope that helps

* – if there will be any comments

Resources

Microsoft.Sdc.Common.Tasks

Continuous Integration #1: The environment and the first build

Jimmy — Sat, 10 Mar 2007 00:45:00 GMT

Introduction

Before I start, I want to turn your attention for not well know product named CI Factory. It's a continuous integration tool (or server) created by Jay Flower. It's quite interesting alternative for those who don't want to set up and configure everything on his own. The CI Factory is using CC.NET and Nant and number of packages. I've never try that tool myself, so if there is somebody who did, I will appreciate some extended comment or review to publish.

When I introduced this cycle I wrote a few words about the target and assumptions. Generally speaking, I'm not going to write about installation of CruiseControl.NET or Subversion, as there are a lot of resources and help for those tools. So let us assume, that we are starting at the moment, when we have Subversion and CC.NET installed on the server along with the IIS and .NET 2.0, everything is configured and works properly, source control is accessible from the network and the same is with CC.NET web interface. From other, non standard tools, we will need a set of MSBuild tasks names MSBuild Community Tasks which should be installed and MSBuild itself which is part of .NET 2.0.

As I mention in introductory post, I'm using MSBuild as a solution for a build script, but there is no reason why you shouldn't use NAnt, however I will not be able to help with details here. If you want to know why I have selected MSBuild there is a few reasons. First of all I want to be able easily extend my build script by adding new tasks which is fairly simple with MSBuild. Of course, MSBuild itself will be much worse option than NAnt, but with a number of additional tasks is, in my opinion, competent alternative.

Last thing I want to remember is that everything I will be doing during the cycle is regarding web application project (not web site, you will see later in the cycle why). Nevertheless all this can be easily adapted to other types of application. Only what you need is to remove site deployment parts.

Setup

For the very first steps we are going to create very simple build server that will take our project from the repository and build it. Some kind of "Hello World" form CI (Continuous Integration) where I want to show generic concept how I server and scripts are organised.

Whole configuration is stored by set of two scripts:

ccnet.config – CC.NET configuration script located in by default in C:\Program Files\CruiseControl.NET\server\
project.proj – MSBuild script for our project.

The first file, ccnet.cfg configures CC.NET and defines what to do and when. One of my biggest concerns when I've started my first CI server was if I should use ccnet.cfg or MSBuild to do all work. There is some functionality, which exists in both solutions, such as subversion checkout or NUnit tests. Finally I've decide to use MSBuild for all building process including checkout, unit testing, code analysis and other. In that situation CC.NET has been used only as a wrapper for my project file. As I saw on the web, using CC.NET to do more work is very popular, but I will to try to convince you that it's a bit easier to use it in the way I have done. One of reasons, and most important I suppose, was that I'm using a number of variables, such as release number retrieved from Subversion. Unfortunately CC.NET does not support something like custom properties or variables unlikely to MSBuild (or I just can't find them). Finally I simply want to have everything in one single file which I can easily edit without checking what is done where. First of all, I'm lazy.

Last thing from setup part is directory structure. Probably there are as many opinions as developers on that subject so I will describe what structure I'm currently using. Please note that I'm not talking about directory structure for the project itself as it is not important from our point of view.

Basically structure is simple. Root directory named build contains separated directories for every project we are going to include into CI. In presented example it is myproject directory. Each project directory has three subfolders:

myproject\drop – This is storage for drops, compiled and ready for download releases of our project with separation to debug and release builds. This directory can be shared over the network using ftp or IIS to allow users download the latest release.
myproject\working – This is the most important directory where all CI working cycle will be located and all temporary files will be stored. This folder will be cleaned before and after every build. In this directory .proj file will be placed.

myproject\working\checkout – This directory will be used for source files checked out from source control.
myproject\working\outputs – This directory will be used for all outputs generated during the build process such as logs, xml reports and so on.

myproject\testsite – This is folder where latest release of site will be published for test (or normal) users. This folder is intended to be accessible via IIS as a default website or virtual folder.

The First Build Script

Having all setup work done we can start working on things that are really important. As I mention at the beginning we are going to do:

Checkout sources from subversion
Build the project (solution)

As a project I will use very simple ASP.NET application with one Class Library project so our solution will contains two projects at the beginning. You can download this project from the attachments.

We will start from the MSBuild script by creating empty file \build\myproject\myproject.proj. We can use the Visual Studio 2005 to edit that file with all intellisense benefits. First thing to do after creating empty file is adding root tag and importing additional tasks we will be using.

$(MSBuildExtensionsPath) is the property built in MSBuild that points to default MSBuild directory. Community tasks I mention before are installed by default under that directory.

Next thing we will need is a declaration of the properties that will make our further work a bit easier. Using PropertyGroup section we can declare properties for use it later. To learn more about properties, item groups and other basic concepts of MSBuild you can refer to MSBuild documentation or wiki on Channel9.

In code below we are creating first property ProjectDir that points to project directory. Then, in the next group we are introducing next two properties that define paths to checkout and outputs folders under working directory. To define that paths we are using property declared before which allow us make change in project location with single line change.

Having all properties ready we can start with writing tasks. First work to do will be cleaning of the working directory and preparing it for the next CI cycle. Tasks are organised in groups inside targets. Each target has name that allow calling only selected target and can also depend on other targets.

In this pretty simple snippet above we are using two standard tasks RemoveDir and MakeDir. The easiest way to clean directory is to remove it and create back again. At the end we are displaying message using Message task.

When we are sure that working directory will be clean and ready we can get source files from the source control. So let us create new target as follows:

This target, named Checkout, depend on previous one, so if we call MSBuild script with parameter /targets:Checkout we are sure that cleaning will be performed at the first place. Task SvnCheckout is included in MSBuildComminutyTasks installed before. Parameters of this task are pretty obvious and do not require any special comment. At the end we are displaying message as previously.

After execution of that target we will have latest source files located in our checkout directory ready to build, so let's do it. Target to do this is also pretty simple in fact:

I named this target Build and set that it depends on "Checkout" target, which is pretty obvious. Because dependency between targets are cascade, co this guarantee us that when we will run MSBuild on out project it will do cleaning, checkout and building. Please note that we are using $(Configuration) parameter in MSBuild task. Because we don't want to hardcode type of build, that will allow us option to later separate build types, we have to pass correct parameter to MSBuild. We can define parameters in the command line which call MSBuild and this parameter will be then available in the script. Note that we don't have to declare that parameter as other parameters before.

To complete our script we have to clean up after build. To do so we will reuse "Clean" target by calling it again after build. We can't set dependency on Build for that target because it will cause circular dependency which is not allowed. There are two ways to achieve that. First is creation the next target which will be duplicated of the cleaning. We can think about that solution if we want to do something more than initial cleaning. In that case possible is creation of the new target, which will execute the initial cleaning and then do some work. Other way is creation of special target, which will execute other targets in required order. For our needs the second way is better. That target is presented on snippet below.

That target will call other targets in the specified order. Moreover, allow us to simply call one target in MSBuild command line to run all of them as we want.

We can test our build script if we want by calling

msbuild.exe myproject.proj /targets:All /p:Configuration=Debug

That command line will execute target "All" and will pass parameter "Configuration" wit value "Debug" which will execute debug build.

Server Configuration Script

To accomplish our job in this part we have to create configuration script of CC.NET. Detailed syntax and structure of that script is quite well described in CC.NET documentation. As a first step we need to create project section in the script. Project tag allows us to specify project name which will be visible on the web dashboard.

Then, we should specify url of project dashboard. This setting is not required, however is used by CCTray, small program that reside in tray and monitor build status on server by showing nice green ball or bad red when build is broken.

Next comes one of the most important things. There are different ways to set up when CC.NET should execute our build. We can set number of triggers that allow scheduling build for many conditions. However in our case we want to initiate build shortly after every source commit, so we will not need triggers at the moment. Instead of that we will use the special feature of CC.NET that is connected with source control block described later and allows initiating build after defined time after last check in.

Thereafter we have to add source control block thereafter to make above working.

If you are still focused after reading such long and boring text, you will probably shout right now: "Wait a moment. We have source control in MSBuild already!". Yes, that's true, we have two checkouts. It may not be clear now, because we are doing nothing complicated in our script, but later we will gather some information from source control during checkout and reuse them in further tasks. In theory we can checkout sources using CC.NET and then use that in MSBuild, but as far I've checked it's not possible to do the same what we finally will do in that way. This explanation seems to be a bit lousy, but everything becomes clear in the next part of the cycle. I hope that. So far you have to accept my explanation and deal with double checkout.

Right, next element is the task, which will call MSBuild and will build our project.

All parameters are pretty clear. We are passing Configuration parameter, targets to build are set to "All" and timeout is set to 1200 seconds. A bit attention needs the last tag <logger>. To be able to get MSBuild log and display it in CC.NET dashboard we have to change the way how build log is displayed using custom loggers. In this case we are using XmlLogger which generate XML file with build log.

In order to use log producer by MSBuild we have to add our final block that will publish log to form that is acceptable by CC.NET web dashboard.

In that way we are done. Below you can find all two scripts in one snippet. You can also find them in file attached to post.

At the moment our server will build our project 30 seconds after check in. Results of the build will be displayed on web dashboard.

This part becomes far longer than I was expecting, but I decide that I have to cover basic topics and post with configuration only would be in my opinion boring. In the next part, in much shorter post, we will add automatic versioning to our script and all explanations about doubled checkout shall become clear.

Below you can find a list of resources I refer in this post. Instead of adding links everywhere in the text, I've decide to group them all together.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build"> <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/> <PropertyGroup> <ProjectDir>D:\build\myproject</ProjectDir> </PropertyGroup> <PropertyGroup> <WorkingCheckout>$(ProjectDir)\working\checkout</WorkingCheckout> <WorkingOutputs>$(ProjectDir)\working\outputs</WorkingOutputs> </PropertyGroup> <Target Name="Clean"> <RemoveDir Directories="$(WorkingCheckout)"> <RemoveDir Directories="$(WorkingOutputs)"> <MakeDir Directories="$(WorkingCheckout)"> <MakeDir Directories="$(WorkingOutputs)"> <Message Text="Cleaning done"/> </Target> <Target Name="Checkout" DependsOnTargets="Clean"> <SvnCheckout RepositoryPath="mySvnUrl" LocalPath="$(WorkingCheckout)" Username="svnUser" Password="svnPassword"> </SvnCheckout> <Message Text="Checkout completed"/> </Target> <Target Name="Build" DependsOnTargets="Checkout"> <MSBuild Projects="$(WorkingCheckout)\myproject.sln" Targets="Build" Properties="Configuration=$(Configuration)"> <Output TaskParameter="TargetOutputs" ItemName="$(ProjectDir)\working"> </MSBuild> <Message Text="Build completed"/> </Target> <Target Name="All"> <CallTarget Targets="Clean"> <CallTarget Targets="Checkout"> <CallTarget Targets="Build"> <CallTarget Targets="Clean"> </Target> </Project>

<cruisecontrol> <project name="Tousprimeurs"> <webURL>http://myserver/build</webURL> <modificationDelaySeconds>30</modificationDelaySeconds> <sourcecontrol type="svn"> <trunkUrl>mySvnUrl</trunkUrl> <workingDirectory>D:\build\myproject\working\checkout</workingDirectory> <executable>D:\svn\bin\svn.exe</executable> <username>svnUser</username> <password>svnPassword</password> </sourcecontrol> <tasks> <msbuild> <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\msbuild.exe</executable> <projectFile>myproject.proj</projectFile> <buildArgs>/noconsolelogger /p:Configuration=Debug /v:n</buildArgs> <targets>All</targets> <timeout>1200</timeout> <workingDirectory>D:\build\myproject</workingDirectory> <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,c:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> </msbuild> </tasks> <publishers> <xmllogger logDir="D:\build\myproject\build\log" > </publishers> </project> </cruisecontrol>

Happy testing.

Resources:

CI Factory
- Homepage
- Hanselminutes about CI Factory
Subversion
CruiseControl.NET
MSBuild
- MSBuild Wiki on Channel9
- MSBuild Community Tasks
- MSBuild Sidekick

Continuous integration

Jimmy — Fri, 02 Mar 2007 10:27:00 GMT

Well, last time I didn't blog too much so I've decide to start a new cycle. It's the best way to force myself to post more frequently. One of the subjects on top of my head was continuous integration so there we are. The other reason is that I will have a presentation on that subject on vBug meeting in Bristol in May and this will be good exercise for me.

I believe that most of you know already what continuous integration is, so I think I can skip this and do some real work. If you need to learn about the subject, start from Google and Continuous Integration by Martin Fowler.

Let us go to plan. As an example I will use very simple web application with some extra features that will require unit testing. In the next parts of the cycle I would like to show:

Setting build server with basic build using CruiseControl.NET, Subversion and MSBuild.
Preparing very first build script.
Setting up version and build number in application assembly.
Deployment built application to the test site.
Automated testing and code coverage analysis.
Static analysis using FxCop.
Generating documentation from code.
Email notification after build.
Creating own tasks for MSBuild.
Integration with Mantis bug tracking system.

I do think it will take me 6 to 10 posts in next two months. First post of the cycle should be on line to end of the week.

Let me know if there is something you want me to add.