Continuous Integration with TeamCity and MSBuild I

‘To start this article let us cite the definition of Continuous Integration from Martin Fowler’s site:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.

I advice you to read the whole article about Continuous Integration before you go on.

For the sake of CI you need the following tools:

1 - A Build Server

TeamCity is very popular CI server from JetBrains, the  creator of ReSharper, IntelliJ, etc. I have had also used CruiseControl.NET, a free CI server from ThoughtWorks, but I liked TeamCity much more because of its friendly UI and distributed agents principle.

2 - Build Tool

MSBuild is an xml-based build platform from Microsoft that comes with the .NET framework. A build platform is some kind of DSL, that helps you to compile your code and do all other related stuff in one action. You could compile source code, execute tests, generate documentation, generate a deployable zip file, publish your web site to the server and almost everything else you may need to do with your code.

Technically, you could write a batch file as you your build script and I have no doubt it will work and do every thing you wish. It just won’t be that convenient.

NAnt is another popular build platform ported from Ant for the Java platform.

Recently I have heard a lot about using Rake, the Ruby build tool, in the .NET world. Psake  is another build automation tool written in PowerShell .

In this and few next posts I will configuring TeamCity to do a nightly build for Stutali , the task list generation tool, I introduced last in this article.The task list generation task will be also included in the nightly build to process its own code and generate the task list.

Building the Build Script

The first step in configuring the build server is to add a build script to the project.  Because TeamCity supports sln files directly, a build script is technically not necessary if you just want to compile the project. Anyway if you want to perform some further building steps like processing  source code or deployment you will need the script.

As already mentioned, MSBuild is the  technology that will be used in this article. The first and most important task is the bare compilation. For this task MSBuild needs only to know  where the sln file is.

<PropertyGroup>
  <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
  <ProjectDir>src</ProjectDir>
  <ProjectName>TasklistGenerator</ProjectName >
  <ProjectFile>$(ProjectName).sln</ProjectFile >
</PropertyGroup>

<Target Name="Build" DependsOnTargets="Clean">
    <MSBuild Projects="$(ProjectFile)" Properties="Configuration=Debug" />
</Target>
  

The Property group section is the place where you define you constants. This could include the project name, tools path and every thing you may use at different places.

TeamCity

After testing the build script and pushing the code to the repository, we can start configuring TeamCity to do the CI work. At first we have to create a new project in the admin panel. This task is as easy as clicking through the wizard steps, filling out some text boxes and ready you are. TeamCity makes really pleasant. Out of the box is Git not supported. Anyway JetBrains has developed a plug-in to enable Git repositories. You have just to download this file from JetBrains and it to the place described.

For the source code repository you should have been able to choose Git from the list after getting the Git plugin installed properly.

In the build triggering section you can specify when you want the build process to be started. Plausible options are either when the repository changes, i.e. when you push modification, or scheduled on a regular base, usually in the nightly, the so called nightly build.

Artifacts

Artifacts are any data items generated during the build process. Those could be binaries, documentation, reports, etc. Because of distributed nature of TeamCity, the actual compiling process doesn’t have to happen physically on the save machine as the TeamCity server. Thus, the artifacts you want to keep have to be specified explicitly, so that they be copied from the machine of the build agent and kept on the server.

Suppose for now the build script generates an html file containing the task list parsed from the source code and save it to CHECKOUT_FOLDER\doc\tasklist.html.  If you want TeamCity to copy this file and make available for download in the artifacts tab of the build report, you have to specify it in the artifacts section

If you want to add an alias to the copied artifacts, just use the => syntax

doc\tasklist.html => tasks.html

You can also copy a whole folder of artifacts.

Now we are ready to go. Every thing is configured and we can trigger a test build. Just click the “run” that you see on almost every project page. If every thing went well you should see a new green line in the result page of the project.

Outlook

It was just the start. What you can do in the CI process is only limited by your imagination and time. You could generate code metric reports, what we will do in the next posts, generate release binaries, push them to the download server, generate documentation,  push the new ASP.Net files to the server and precompile them, etc.

For the next posts, we will see how to integrate NDepend, NCover, FxCop and code documentation with the build process.

See you later!