I posted Simple Versioning and Release Notes a few weeks ago talking about how to simplify release notes and versioning. This post is a bit of a cheat sheet for how I set up my builds.
I normally have two but sometimes three builds for each project. The structure is something like this:
- TeamCity Project
- Acceptance/UI Tests (optional)
1. CI builds the solution with correctly versioned assemblies (update assembly info files with version before build), runs all unit tests then creates any packages which are required. This includes NuGet packages, Chocolatey packages, zipped binaries, clickonce installers etc.
This build monitors pull requests and is triggered automatically when there are new commits/branches.
2. Acceptance/UI Tests is an extra I use when I have long running or UI tests, for example TestStack.White on TeamCity (sign in as guest) has this build setup and it runs Whites UI tests.
The reason I separate it is for speed reasons, I want my CI build to fail fast and only if it is successful do I run this slow build.
This build triggers whenever
1. CI succeeds
3. Release (or 2. Release if there is no acceptance/ui test build) is run manually and it releases the artifacts build by
1. CI, if that is a NuGet package it is pushed to NuGet.org, chocolatey packages get pushed to chocolatey.org, zip files get pushed as a GitHub release etc.
Once this build succeeds it should tag the VCS root and push that tag.
First step is to create our VCS root.
VCS Root Name: Project Name (all branches + pull requests)
Default branch: master
If you are using stash it would be
You should also put a username/password in to authenticate with the VCS root so we can tag in the release build
This has two build steps, for this to work you should install GitVersion on your build server via chocolatey.
Runner Type: Command Line
Step Name: GitVersion
Run: Executable with parameters
Command executable: GitVersion
Command parameters: . /updateAssemblyInfo /output buildserver
This should be setup however you used to do it, build your solution, run your build scripts etc.
VCS Trigger with the default settings which has a branch spec of
I have the report status to GitHub plugin installed, this plugin tells github the build status of pull requests so it can display warnings if a pull request will break the build
2. Acceptance test
This build varies greatly, if you need this build it has the same triggers and dependencies setup as 3. Release. I won’t repeat those settings here.
The same VCS root which is referenced by 1. CI should also be referenced by this build
Normally for me this just a NuGet push step. But whatever you normally do, use the artifact dependencies to get at the artifacts from your CI build to publish
Labeling pattern: %system.build.number%
Label builds in branches:
+:* (we want to label any release)
Check Label successful builds only
This is the important part, we want to setup a proper TeamCity build chain.
1. Add snapshot dependency for CI build and previous build in chain, so if you have 2. Acceptance tests then add a snapshot dependency for both CI and Acceptance test builds
Tick Do not run new build if there is a suitable one and Only use successful builds from suitable ones
The snapshot dependency is really important, it means that you release the artifacts associated with a specific git commit. If you don’t you can deploy artifacts which came from another branch =/ 2. Add Artifact Dependency to CI Build with these settings:
Get artifacts from: Build from the same chain
Artifacts rules: MyPackage.*.nupkg (or whatever artifacts you need to publish
I put this last because you need the dependencies setup before configuring this page. Build Number Format: %dep.MyProject_Ci.build.number% (MyProject_Ci is the project ID of the CI build)
Hopefully this helps you get your TeamCity builds setup, I have found this setup works quite well and is easy to setup and keep running.