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.