How to Automate Builds with TeamCity (Part 6)

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 6:  Running the TeamCity Build

If you click on the “Build Configuration Home” located at the top of the configuration steps section on the right, you will be redirected to the Build Home page, were you can see a series of stats about the build.

Here you will see an overview of the Build configuration. You can check the status of the build, any pending changes, and recent history. You can switch to the top navigation tabs to see a complete report of the build’s history, change log, issue log, statistics, compatible agents, pending changes and settings.

This page will be very helpful when trying to figure out issues or broken builds. It is the place where you can see changes made, and find the responsible for the build triggers and breaking changes.

If you now go to the home page of the TeamCity CI Server or click on the “Projects” tab on the top navigation, you will now see your project listed, and under it, the actual build configuration we just added.

Notice that the build hasn’t run yet. You can run it manually, but we already configure it to run when changes are committed to the repo. So let’s go ahead and test the real thing.

Let’s commit the pending changes we have, which are basically the MVC app creation, along with the build file. Keep an eye on the TeamCity project’s build status.

In SVN, you should first add the new files. Make sure to tell SVN to ignore the bin and obj folders generated by Visual Studio. We don’t want those going up to our source control server.

Once you are ready, commit the changes to the server.

When the commit completes, almost immediately (depending on your server’s speed) the TeamCity project’s build process should start.

The first time it will take more time because it needs to create the first checkout. In general subsequent commits and changes should be a lot quicker.

During the build process you can click on it and see the overall status. You can see the overview, the changes committed, the build log and the current build parameters.

Troubleshooting Build Errors

If you have followed all of the steps so far, you should actually get a failed build, which although you might feel disappointed, is actually desirable. I want to show you how to quickly troubleshoot build errors.

So, what do you do when you get errors? We just did the commit and the Build actually failed.  

If you click on the build project, and go to the Build Log section, you can see what happened. Notice that you have a few options to see the log messages. Click on the “All Messages” to see everything that happened.

We can quickly see that the problem is related to the “Dev” configuration not being found on our solution. The reason is because TeamCity could not find a configuration matching the “Dev” setting we passed to the build step.

If you take a look at the Web.config file in your solution, and expand it, you will notice that there are to Web.Config transforms: Web.Debug.config and Web.Release.config. However, there is not a “web.Dev.config”

To fix this, let’s just change the Build parameters to “Release” instead of “Dev” (adding Web.Config transforms will be part of a different post.)

Now run the build (you can run the build manually from TeamCity without the need to do a commit). Your build should finish without any issues, displaying the success notification.

Done!

There you go, you have been able to automate for Build process by establishing a CI mechanism using Source Control (SVN in this case) and TeamCity. Now you can be sure that every commit will certify the changes by building the solution and displaying the success or failed status accordingly.

Notice that my build is taking 22 seconds, which is quite good.

Compatibility Issues

If you are still getting errors when your Build runs, it might be because of compatibility issues between your server and development environments. Whatever you use locally to build your solution, needs to be available on your server environment. It might be, that the server can’t build your solution because it was created with a different version of Visual Studio or is targeting a .NET framework not available or supported in the server. Check my post around similar issues just in case, it might save you some time and a few headaches!