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:
- VCS Triggers: Triggers a build when files are checked into source control.
- Schedule: Triggers a build on a predetermined schedule.
- Dependencies: Triggers a build when another build completes successfully.
- 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.
Lets 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.)
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!
2 thoughts on “Implementing TeamCity for .NET Projects, Part 2: Triggering Builds”
Comments are closed.