Continuous Delivery with psake and TeamCity - Preparing for a pipeline

In my previous three posts I have shown how you could set up a Continuous Integration build with psake and TeamCity 6.5. This time I will show you how to prepare for continuous delivery where the artifacts from the CI build flows through several steps and environments that together form a pipeline of builds which culminates in deployment to production. It seems like this is developing into a series, so here are my previous installments:

1. Creating a Local Build With psake, Part 1: Compiling
2. Creating a Local Build with psake, Part 2: Testing
3. Continuous Delivery with psake and TeamCity - Reusing the Local Build to Create a CI Build

One of the core principles of continuous delivery is that the deployment process should be repeatable and reliable. To achieve this we have to make sure that every bit of the deployment process is automated and that we deploy in the same manner to every environment. I urge you to read Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. It’s a fantastic book!

The output produced from build is usually referred to as the build artifacts. This includes all the compiled binaries and other packages, for example installers and migration scripts for a database. It is very important that you compile you binaries only once and use the same binaries to deploy to each environment in the pipeline. To enable this the artifacts needs to be stored somewhere so that the deployment process can get it. TeamCity comes bundled with an artifact repository which can be configured in the Build Configuration. This feature allows us to associate the artifacts from a build to the build id and reuse them by setting up an artifact dependency between the different builds in the pipeline. By doing this we can say that the deployment build to for example test has a dependency on the CI build. Whenever the deployment-to-test build runs, TeamCity will automatically download the artifacts from the specific CI build you configure it to get it from, for example the last successful build of CI. In this manner we can chain or builds to create a full continuous delivery pipeline.

Let’s get on with it and configure our CI Build Configuration to publish artifacts. Open the Build Configuration and look for “Artifact paths”:

Here you can specify files and folders that you want to publish to the artifact repository. For a detailed explanation of the format see TeamCity’s documentation. Let’s make TeamCity zip our WpfApplication so that we can deploy and distribute it in successive builds. Add the following to the “Edit artifact paths”:

build_artifacts\Debug\ContinuousDelivery.WpfApplication => app.zip!ContinuousDelivery.WpfApplication

This statement takes all the files in the ContinuousDelivery.WpfApplication folder and zips it to a ContinuousDelivery.WpfApplication folder inside app.zip. If we now run the CI build we should see that an artifacts tab has appeared and that our zip-file is displayed.

That concludes this post. Next time we will reuse the artifacts and setup a dependent build to deploy to a test environment.