Introduction

About the book

This is a sample chapter of the book Continuous Integration in .NET. It has been published with the exclusive permission of Manning.

Written by: Marcin Kawalerowicz and Craig Berntson
Pages: 375
Publisher: Manning
ISBN: 9781935182559

TeamCity is a CI server that has been gaining popularity in the .NET community for the last few years. It is packed with handy futures which we will discuss in a minute and has a free version suitable for smaller teams.

The free version of TeamCity lets a group of 20 people work with 20 various projects. There are a few other minor restrictions like the lack of more sophisticated login scenarios using Active Directory. If you need support for more developers or projects you have to buy the license for about $1500. Both versions allow you to set a distributed build grid using build agents. They let you divide your builds over several machines. Basically you install the agent software on various machines and TeamCity automatically starts the build on one of the build machines.

It has a very neat future that lets you forget the manual build technique. It verifies code compiles and passes unit tests before committing your source code into the repository. Look at the Figure 1 to better understand the difference.

Figure 1: The pre-Test commit feature of TeamServer lets you check your build for correctness before you commit it to the source control repository.

You basically send your changes first to TeamCity and not to your source control system. TeamCity performs the build, tests if everything is fine, and then commits the changes to source control system only if everything worked fine. We hope we got your attention and you are eager to try it yourself. So let's get started with TeamCity!

Running TeamCity

You can download the TeamCity setup from the JetBrains website1. It is quite a large setup file that contains everything you need to build a CI process. It asks you to install the core features and build agent (Figure 2).

Figure 2: To run the builds with TeamCity you need to install at least one Build Agent. You can install more Build Agents on multiple computers to create a build grid.

Both the Build Agent and Core Server will be installed as separate Windows services and automatically hooked up together. TeamCity comes bundled with its own Web Server. All the TeamCity configuration and management happens on a web page that is hosted on this server. As showed on figure 3 you have to choose a port where TeamCity will be available.

Figure 3: TeamCity comes with a bundled Web server. If you have IIS or any other application running on a standard http port you will have to change the port for TeamCity.

You will have to decide under which account you want to run TeamCity (Figure 4). It depends on what are you expecting to do with the server. Will your build need more rights than a normal System account? It may be possible if you plan to use network shares or have other restrictions on the files on the server. If you are not sure, run it under the System account. It's safer, as your user account is probably an administrator on the machine.

Figure 4: If you plan to make TeamCity available outside your Intranet environment, don't make hasty decisions here. Run it with the user that has the fewest rights needed for normal usage.

Start both the Build Agent and Server services. When the installer is done you will be presented with a license agreement and be asked to create the first user account with administrator privileges. TeamCity is then available for normal work. After initial login you will be asked to create the first project (Figure 5.).

Figure 5: Once TeamCity is ready to work, the first step is to create a new project.

To make the project run under TeamCity you have to connect TeamCity to the source control configuration, define a runner and make sure your agent is properly connected. Let's do all it.

Project configuration

Once you have installed TeamCity, you need to configure the first project. In fact, you'll go through these steps for each project, but some settings may change from one project to another. Let's walk through setting up the Framework shard library from our Financial Calculator.

TeamCity needs to know how you will refer to the project (Figure 6). This does not have to be the same name as the Visual Studio project. In fact, you probably want to make it something more understandable as it will be used in the feedback mechanism we discuss in Chapter 5. Enter the name and description for the project then click Create.

Figure 6: No angle bracket tax in TeamCity. The whole configuration process runs in a comfortable UI. We are starting with a new project.

Now that you have created the TeamCity project, you need configure it (Figure 7). This is probably the most difficult part of setting up a new project as you need to decide things like the build number format and what to do if a build fails. Notice the Configuration Steps on the right side of the screen to help you know everything you need to do.

Figure 7: General project settings. Pay close attention to build number formatter and the fail conditions. Builds will be formatted with the revision number. We decide to fail even if the build exceeds the 10 minute rule.

Once you have configured the build options for the project, you must configure the connection to the Version Control System (VCS) or in other words, your source code repository (Figure 8). The source root configuration varies depending on the source control system we are using. As we are using SVN we will have to provide at least the SVN URL, username, and password. The newly created source control root will be added to the project configuration.

Figure 8: Creating a new source control root. You will be able to reuse this configuration in other projects.

You can also decide what checkout mode you want to use (Figure 9). It can be done on the TeamCity server, on the build agent or not at all if your build script will pull the changes for itself. SVN lets you checkout the files on the agent, so do it. It will reduce the load on the main TeamCity server. You can decide where to check out the files or leave it blank for TeamCity to decide. The build folder could be automatically purged before every build. You can automatically label every build you make. To do that you will have to dive into additional SVN configuration. We will pull the build lever on it without labeling.

Figure 9: Additional source control configuration. Checkout on the build agent, default working directory with cleanup and no labeling.

The next step is the build runner configuration. The build runner is a tool that will perform your build. TeamCity comes with a bunch of runners. In our .NET scenario MSBuild, NAnt and Visual Studio Solution runners are handy. Yes, TeamCity is able to run the solution projects directly and not only through a MSBuild script as CCNet. We will use this feature for our Shared project as shown in Figure 10.

Figure 10: Visual Studio Solution runner configuration. It starts the Rebuild target in Release configuration.

To make TeamCity automatically trigger the build every time something new is detected in the source control repository you will have to check Enable triggering when files are checked into VCS flag as showed in Figure 11. You can enable quiet period detection there. You can configure the build dependencies for your project. We don't have any so we will accept the defaults. Similarly, we will use the defaults for the properties and environment variables and agent requirements.

Figure 11: Configuring triggers in TeamCity. You can have triggers that fire periodically, or based on a dependency.

Summary

There you go! If you configured everything correctly you have your first continuous build with TeamCity ready and it should be visible on the projects overview page.

About Manning Publications

Manning Publication publishes computer books for professionals--programmers, system administrators, designers, architects, managers and others. Our focus is on computing titles at professional levels. We care about the quality of our books. We work with our authors to coax out of them the best writi... This author has published 33 articles on DotNetSlackers. View other articles or the complete profile here.