• Configuring TeamCity 7 to build your VS2010 .NET project using Git repository

    Published by on April 27th, 2012 7:18 pm under Continuous Integration, TeamCity7

    1 Comment

    Hi everyone,

    Recently I’ve been working with TeamCity 7 and getting involved in the continuous integration practice, so I would like to show my experience in this post.

    For my project, “build” means the following things: compiling, checking Source Analysis, checking Code Analysis, running Unit Tests and measuring Code Coverage. Taking this into account, I will show you how to configure TeamCity 7 to perform all these tasks automatically in a VS2010 .NET solution, with .NET Framework 4 and a Git repository.

    First of all I had to create a new project. I did this in the Administration > Projects section, clicking Create new project and providing a name for it. After that, I had to create a new configuration for my project. This configuration has various “steps” to configure.

    Configuring General Settings

    image

    In this section I only provided a name for the new configuration. I left all the other values by default.

    Configuring Version Control Settings

    image

    In this section I had to specify the URL of the Git repository that I’ve been using to commit the source files of my application. To do this, I clicked Create and attach new VCS root and then, when the New VCS Root windows is displayed, I specified the URL of my repository and set the authentication method to Private Key, indicating the Private Key Path too.

    image

    TeamCity will be monitoring my repository according to the triggers that I specify in the build execution. On each build, TeamCity will search for changes in my repository and will execute the defined Build Steps. I will show all of this configuration in in the next sections.

    Configuring Build Steps

    This is one of the most important parts of the configuration process, because Build Steps are the actions that will be executed when a new build runs. In my configuration, I had to create 3 Build Steps as shown in the following picture:

    image

    Step 1 – Source Analysis, Compilation and Code Analysis

    This step will use a MSBuild runner with a ciserver.proj build file that resides inside the repository of the project. This build file has all the routines to check Source Analysis, Code Analysis and perform the compilation.

    image

    Ciserver.proj file

    image

    IMPORTANT: In order to successfully run this build file, you need to have Stylecop and MSBuild Extension Pack installed in the Server machine.

    I defined all the paths to the working directory, FxCop and the Extension Pack at the beginning (they should be environment variables provided by TeamCity), so they can be passed to the tasks that are executed after that. In the ItemGroup tag I specified all the source code files in the repository, the assemblies to take into account, the rules to include, the soulution files and the ones that I want StyleCop to include in the checking.

    • RunSourceAnalysis task: It depends on the StyleCop.dll assembly of the MSBuild extension pack. This task will take the files defined in the ItemGroup section and the Settings.Stylecop specified and will perform the check generating a log file with all the information of the execution.
    • Compile task: It will perform the compilation of the solution. Notice that it depends on the RunCodeAnalysis task.
    • RunCodeAnalysis task: It will check Code Analysis in the assemblies defined in the ItemGroup section, and generate the results in a txt file. It also depends on the Compile task.

    All the result files generated by StyleCop and FxCop will then be used to show the Code Metrics reports in the TeamCity UI. I will show how to do this at the end of the post.

    Step 2 – Run tests

    This step will use MSTest runner with the Local.testsettings and test-metadata (.vsmdi) files generated by Visual Studio. In the test-metadata file I included the list of tests that I want the Build Process to execute.

    image

    All the other fields are left by default.

    Step 3 – Measure Code Coverage

    For this step, I decided to execute a Build file called teamCityCodeCoverage.proj with a MSBuild runner and measure the coverage manually instead of using one of the tools that TeamCity provides (NCover, PartCover, dotCover, etc).

    image

    The only things that I had to provide in TeamCity were the path to the Build file, the .NET Framework used and the platform (x86 in this case). I left all the other fields by default.

    teamCityCodeCoverage.proj

    image

    When the Tests were run in the previous Build Step, a sort of TestResults folder is created in a temp folder inside TeamCity path. It is the ArtifactDirectory path that is displayed in the previous image. Inside of it we have 2 important assets: The Out folder with all the assemblies of the test results, and the data.coverage file with the coverage information inside a In folder. All these stuff will be passed to the CoverageConvert.exe tool (this is an internal tool developed by the engineering excellence team), which will process them and produce a CodeCoverage.xml file with all the results of the measurement. But this is a lot of information to show in a report, so I used some assemblies to transform this xml into a html file with the summary of the Coverage.

    Folder with build files and Coverage tools

    image

    NOTE: The disadvantage of measuring Code Coverage like this is that these assemblies have no maintenance and are a blackbox, although they were developed here in Southworks.

    Configuring Build Failure Conditions

    In this section you can specify when the Build should fail. Notice that you can add custom Build Conditions apart from the ones provided by TeamCity. In my case, I added two build failure conditions when there are Source Analysis or Code Analysis violations. Basically in the ciserver.proj file I show a status message when the check of Code Analysis and Source Analysis finishes. This will be printed in the Build log of TeamCity, so I added my custom failure conditions to fail the build if the status messages of Source Analysis and Code Analysis in the Build log of TeamCity are failure.

    image

    Configuring Build Triggers

    In this section you can specify the triggering of the Build Process. In this case, I decided that the build process should start after a new commit is detected in the Git repository, so I chose a VCS trigger.

    image

    How to Show the Code Metrics Reports in the TeamCity UI

    TeamCity 7 provides custom report tags. These ones are useful to show reports generated by other tools, like in this case, Source Analysis, Code Analysis and Code Coverage. To make this happen, we have to store these 3 reports as artifacts from the build.

    To do this, we specify the path to these files in the General Settings section of the Project Configuration Wizard.

    image

    After that, we will create a new report tag for each report, and retrieve the report from the artifacts generated by the last successful build. To do this, click Administration at the top right corner, click your project’s name and the click the Report tabs tab. There you can create all the tabs that you want, specifying the build which the artifacts will be taken from, and the file names. These artifacts will be taken from the data-directory path of TeamCity, in this case, under Users\User\.BuildServer7\system\artifacts\{projectname}\….\{file-name}.

    image

    Then, you can see the new tabs in the Project’s Home page, displaying the required reports.

    imageimage

    image

    I know that the Code Analysis report is not very consumable, but I will show another alternatives for reporting it in another post.

    I hope that you find all this information useful!

    Thanks!