Sunday, April 21, 2013

How to Automate Builds with TeamCity (Part 1)

Please notice that this is a multi-part, step-by-step guide, on how to automate builds in TeamCity CI Server. You can find the parent article here, which has links to all the related posts.

Part 1:  Creating the Project’s Build Script 

To get started, we first need to setup our source control repository and create an application we can use to configure and test our TeamCity CI Build.

TC_build_web_02_thumb[2]

  1. Create a Repo on your Source Control Server that can be seen from your TeamCity CI Server. In my case, I’m using Subversion
  2. Create an application that you can commit to the repo for testing purposes. Let’s start with a default ASP.NET MVC 4 application, which will be created with default controllers and views.
  3. Once created, run the application from Visual Studio (F5 or DEBUG/Start Debugging) to make sure everything is working correctly. You should see the default page running.
  4. Let’s do a couple of modifications so you can give a few personal details to the home page. In the HomeController.cs file, change the ViewBag.Message property for something more meaningful in the three controller actions. That should be good enough for now.

Now, the trick to enable TeamCity to automate the Build process of your applications is to establish a build mechanism. Each tech stack will have its own mechanisms to compile and build projects. 

In Visual Studio, you build your solution every time you compile and/or run your application. Visual Studio is able to do this by using Microsoft’s Build Engine, known as MSBuild.

TeamCity needs to have a mechanism in place to know how to build the application files that will be retrieved from the source control repository. Currently, TeamCity supports a wide variety of build mechanisms that work across a large range of platforms.

Among the supported platforms, you will fine MSBuild, Ant, .NET Process Runner, Command Line, FxCop, Maven, rake and PowerShell. You will also find mechanisms to build and run unit tests suites like Nant, NUnit and MSTest.

In our case, the common choice is to use MSBuild and MSTest for .NET projects. This means that we need to create a MSBuild script in our .NET project, which will be used by TeamCity to build our solution.

TC_build_web_43_thumb[2]

In your solution, create a new folder and called “Build”. You will place your MSBuild scripts here. Open the explorer of that location and create a new file for your MSBuild script. It can have any name, but needs to have “.build” extension. In my case I named it “project.build”. Now make sure to add it to the project inside the Build folder in Visual Studio.

The following is the code for the build script:

  1: <?xml version="1.0" encoding="utf-8"?>
  2: <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  3:   
  4:   <PropertyGroup>
  5:     <Configuration Condition=" '$(Configuration)' == '' ">Dev</Configuration>
  6:     <ClassLibraryOutputDirectory>bin\$(Configuration)</ClassLibraryOutputDirectory>
  7:     <ProjectDirectory>$(SolutionDir)\$(ProjectName)</ProjectDirectory>
  8:     <ProjectFile>$(ProjectDirectory)\$(ProjectName).csproj</ProjectFile>
  9:     <ApplicationOutputDirectory>$(ProjectDirectory)\$(ClassLibraryOutputDirectory)</ApplicationOutputDirectory>
 10:   </PropertyGroup>
 11:   
 12:   <!-- Build projects by calling the Project files generated by VS -->
 13:   <Target Name="Build">
 14:     <MSBuild Projects="$(SolutionDir)\$(SolutionFile)" Properties="Configuration=$(Configuration);"  />
 15:   </Target>
 16:   
 17: </Project>
 18: 

Notice that the script has two main sections so far. One where we declare properties that can be used across the script, and then the one where we define the MSBuild target. In this case, we are defining a simple target for our “Build” process, which will build our solution based on the configuration that we pass (in this case set as “Dev” by default).

Take a look at the MSDN documentation(here and here) for the specific documentation. In this case, we are putting together a generic Build project that work across web apps.


Now we are ready to create the TeamCity Build configuration. We can create the configuration at any point, but if we do it now, we can test it as soon as we commit our first changes to the repo. Alternatively, you can commit your changes right away. We can then run the Build manually from TeamCity, or do any modification and commit it to trigger it (once the Build is properly configured in TeamCity of course).


Next Article:


Part 2: Creating the Build Project in TeamCity

No comments:

Post a Comment