My blog has moved!

Visit or and update your bookmarks.

Sunday, April 19, 2009

Implementing TeamCity for .NET Projects, Part 3: Running Tests, Nightly Builds, and Creating Artifacts

For more information on this series, please see the introductory post.  This post also assumes that you have completed parts 1 and 2.

With our basic solution build, we want to start running our unit tests on every check-in, create a nightly build (that runs both unit and integration tests), and generate some artifacts.

Running Tests

First things first, lets get the tests running.  Open the current build configuration and select the build runner navigation link (it should say Runner: sln2008).  On the build runner page, select NUnit 2.4.8 from the NUnit runner combo box.  Add the path to the unit test assembly in the assembly text box.  For our solution, the path is: **/bin/debug/AdventureMVC.Tests.dll .  As you can see, this is using an MSBuild wildcard format to find the correct assembly.  It is unnecessary to point to the full path.


Save your changes.

Now, when your builds run, you should get a new status indicator showing how many tests passed. 


If you click on the status, you will also see a new tab on the build results page showing the test information.

image image

Nightly Builds (with integration tests)

Now that we have our imageunit tests running on every check-in, let’s create a nightly build.  Open the current build configuration.  Make a copy of the build by clicking on the Copy button on the right-hand side of the page. 

Rename the new configuration as you see fit.  I will use Nightly Build.


Select the build runner link.  Add the integration test assembly to the test assembly text box.


Save your changes.

Select the Build triggering link.  Deselect the check box.  On the imageSchedule tab, click on Add time trigger and configure your nightly build time. Save your changes.  (You can test the build at this point by clicking on the Run button.)

Creating Artifacts

We want to make the compiled website readily available, so we are going to create some artifacts.  Getting at the precompiled website through the file system is inconvenient.

If the example solution contained a website, compiling the solution would create a precompiled website.  Since the example solution contains a web application project (specifically an ASP.NET MVC application project), I had to add a post-build event to create the precompiled site.  Check the AdventureMVC project properties to see the syntax.

On the Nightly Build configuration page, select the General Settings link.  In the Artifacts text box, type: PrecompiledWeb\Web=>PrecompiledWeb.  Save your changes.


Now when you run your build, you should see an Artifacts dropdown link in the status line of the build. 


When you click on the build status, the status page now has an artifacts tab.  


Not only do you have the ability to download the individual files, you can now use these artifacts in other build configurations…but that is for another post.

Upcoming posts:

  • Build scripts: We need some additional functionality that the basic solution runner doesn’t provide, such as zipping up artifacts.

  • Setting up notifications: We will look at the different options for notifications, such as email and the tray notifier.

  • Deployment: Using TeamCity and build scripts to update different deployment environments.

    JetBrains TeamCity
    Sample Project on GoogleCode

    Wednesday, April 15, 2009

    Implementing TeamCity for .NET Projects, Part 2: Triggering Builds

    For more information on this series, please see the introductory post.

    Why Continuous Integration?

    The benefit of continuous integration, according to Martin Fowler, is reduced risk.  Reduced risk is accomplished through a quick feedback cycle.  The longer you defer integration, the more difficult integration becomes.  If you integrate automated testing into your integration cycle, you can further reduce your risk.

    Continuous Integration with TeamCity (VCS Triggers)

    TeamCity has four build trigger options:

    1. VCS Triggers: Triggers a build when files are checked into source control.
    2. Schedule: Triggers a build on a predetermined schedule.
    3. Dependencies: Triggers a build when another build completes successfully.
    4. Other Triggers: Triggers a build if previous build fails.

    VCS triggers are analogous to continuous integration.  Check in files to source control and a build is started.  Enabling continuous integration in TeamCity takes only a few clicks to configure.

    imageLets get started. Click the arrow next to the build configuration we completed in the last post. Select Edit Settings.




    On the right side of the build configuration screen, you will see a list of Build Configuration Steps.  Select the Build Triggering step. 

    Select the checkbox labeled Enable triggering when files are checked into VCS


    At this point, you can save your changes and you will have enabled continuous integration.  The quiet period and trigger rules (explained below)  fine-tune the behavior of the build trigger.

    Once checked, an option to set a quiet period is enabled.  A quiet period is the length of time after a check-in which TeamCity will wait before starting the build.  If check-ins tend to come in waves, this can help keep the build queue short.  (If you tend to forget to check in all your files or need to check in files from your IDE and file system, you may want to give yourself a short quiet period before triggering a build to allow for multiple check-ins.)image

    However, if you configure too long of a quiet period with a project with a large team, the build may take too long to start, negating the benefits of continuous integration.  I prefer to select Do not use or Use default value (60 seconds) for my projects.

    Finally, you can exclude some check-ins from triggering the build by defining trigger patterns.  Exclusions can be based on file paths, users, or a combination.  For example, if your project team includes a technical writer who produces documentation, those check-ins probably do not affect build quality.  Or, when you update your build scripts, those changes may not need to trigger a build either (see example below).  For the purposes of the example solution, you may define the –:*.build pattern, even though we haven’t started using build scripts yet.


    Defining a trigger pattern is fairly straightforward. The pattern is:
    +|-:[user][VCS root][path]
    Defining a +: rule removes the include all rule, allowing a very fine-grade include path. Defining a –: rule excludes the defined path from triggering a build.  For more information, see the documentation.

    Finish by saving your changes and returning to the main page.  Update and check in a project file and you can watch TeamCity start a new build process.

     Congratulations! You have just enabled continuous integration with TeamCity!

    Upcoming posts: Creating artifacts and nightly builds

    JetBrains TeamCity
    Sample Project on GoogleCode

    Sunday, April 5, 2009

    Implementing TeamCity for .NET projects, Part 1: Just Build It! (A Simple Build Configuration)

    For more information on this series, please see the introductory post.

    When working on an development team, one of the more challenging tasks can be building your integrated source code for deployment.    Building a production version of the application may be a long and difficult process, especially if production builds are infrequent.  Even a well-documented build procedure may take hours or days to complete and is probably prone to error.  One person may have all the requisite knowledge to perform the build, causing delays or rifts for other team members when builds are needed.

    Therefore, creating a repeatable build process that any team member can instantiate can provide great benefit for the team, reducing the risks in the build process.  That is our purpose for this exercise – to Just Build It! 

    For a production build system, your build server should be a mirror of your production environment.  This helps reveal possible issues and risks before deploying to your production environment.  For the purposes of this series, this is not necessary; however, you must have the following installed:

    • Microsoft Visual Studio 2008
    • A version control system(VCS), such as Subversion or Team Foundation Server. 
      • If you do not have a current VCS instance, consider VisualSVN Server
      • Ensure that the system on which you will install TeamCity has the ability to check out files from your VCS natively.  For Team Foundation Server, you must have Team Explorer installed.  For Subversion, you must have SVN or TortoiseSVN installed.
      • For a full list of supported systems, consult the TeamCity documentation
    • The sample AdventureMVC solution
      • Added to your installed VCS
      • Available from
        • A zip file is available to download for utilization in your VCS
        • You may also browse the source on the site
    • The AdventureWorks database installed on SQL Server 2005 or SQL Express 2005
      • Available from Microsoft downloads
      • Update the web.config file to your specific database connection information prior to running the solution or any builds
    • TeamCity 4.02 or later
      • If you are using VisualSVN Server 1.7, you must download TeamCity 4.1 EAP or later
      • For installation instructions, consult the TeamCity documentation.
      • Note your installation directory and build server directories.  These will be useful in the future.
      • I usually locate my buildServer directory in the TeamCity installation directory rather than in the user profile folders.
      • When choosing the port for the TeamCity website, be aware of other sites configured on the machine.  Unless the server is dedicated to TeamCity operations, I suggest using port 8111.

    Note: I am assuming that you will be installing all of these packages on one system for exploratory purposes.  If you are not, you will need to adjust the instructions accordingly, especially in later posts.  For example, you will need an instance of AdventureWorks on your development system and your build system.  In a future post, I plan to explore the challenges of integrating databases into a continuous integration solution, such as TeamCity.

    Your First Project

    With TeamCity, the time between finishing installation and running the first build can literally be minutes.  Lets get started.The minimum requirements for build configurations are:

    1. A project to house the configuration (TeamCity houses all build configurations within user-defined projects).
    2. A connection to a version control system
    3. A build runner

    Start up the TeamCity site.   Click on the imageCreate Project link, name your project, provide a description of the project (optional), and click the Create Project link.  

    Your First Build Configuration

    image Click on Create Build Configuration (you have 20 total in the professional version). 

    On the General Settings, provide a name for your build configuration and an optional description.  Leave the rest of the options on the General Settings page at their default.

    Click on VCS Settings.

    Name your VCS root and choose your VCS type.  Fill out your VCS-specific settings.  Ensure that the root of the source control directory is the trunk folder. 

    Here is my Subversion configuration for the example project:


    And my working directory:


    Here is a possible TFS configuration:


    Test your connection and save.  Once again, leave the rest of the options at their defaults. 

    Click on Choose Build Runner.

    Select sln2008 from the Build Runner: option list.  In the Solution file path: text box, enter src\AdventureMVC.sln.  Change the text in the Confguration: text box to Debug.

    Click Save.

    Running Your Build

    Click on the Projects tab in the top navigation. In your newly defined build configuration, click on the Run button (do not click the ellipse) and watch your build run.image


    If everything compiles, you should see a success message for your build.  If not, check the error messages in the build log.  You may have errors in your VCS configuration.


     Congratulations! You have just completed and run your first build configuration!

    You can find your compiled website in the TeamCity installation directory under \buildAgent\work\guid\src\PrecompiledWeb\Web.

    Next: Continuous Integration (or Triggering Builds) and Creating Artifacts

    Even with a source code version control system (VCS), ensuring each developer has a working, buildable version of source code can be a slippery slope.  A developer may forget to check in a new file or dependent library.  With a VCS based on optimistic locks, a careless developer may break another developer’s code during a merge operation. So, how do we make sure that the latest code is compiling code? By using Continuous Integration.

    And, isn’t there an easier way to get at my compiled application? Yes, there is.  Its called Artifacts.

    Stay tuned.