In a previous post, I had configured a deployment build configuration in TeamCity. I had mentioned back then that it’s possible to set it up in a different way, which makes it is easier to visualize the deployment pipeline across all environments. In this post, I’ll modify that deployment pipeline to use snapshot dependencies and project templates.

First, I’ll modify the artifacts so that they’re all stored in a subfolder named artifacts. This allows to clear only that subfolder when clearing artifact paths. The inline script for deployment needs to be adjusted accordingly.

Using a subfolder for artifacts

Then, I’ll attach the project’s VCS root to the Deploy Stage as well. This is necessary to allow for snapshot dependencies:

Attaching VCS root to deploy stage

Note that we’re still not using anything from the source code during deployment. We’re only using the immutable artifacts generated during the commit stage. We just need to add the VCS root because TeamCity allows us then to use snapshot dependencies. Adding the snapshot dependency is the next step:

Adding snapshot dependency

And configure the artifact dependency to use the artifacts from the same build chain:

Using artifacts from the same build chain

This creates a build chain between the Commit Stage and Deploy Stage, which is visually more user friendly:

Visualizing build chain

Now that this is done, I’d like to use one build configuration per DTAP environment. First, I’ll change the environment configuration parameter so it’s not a prompt anymore:

Changing the env parameter to normal instead of prompt

I’ll also change the build type into a deployment project:

Changing Deploy Stage into a Deployment build configuration

Now I’ll extract a project template out of this build configuration, so that I’ll be able to reuse it for all environments of the DTAP:

Extract template out of Deploy Stage

From there, I can rename the old “Deploy Stage” into “Deploy to Test” and set its env configuration parameter to test. I can further clone this build configuration for Acceptance and Production and set the env configuration parameter accordingly. In the end, I can see this screen on the Commit Stage of the build:

Deployments of Commit Stage

One more trick I like to do is to see the same build number across all build configurations. The Commit Stage is already configured to use SemVer, so we’ll re-use that number in the deploy configurations:

Using the same build number across all deployments

We can also configure Acceptance to depend on Test and Production to depend on Acceptance. This is done by adding additional snapshot dependencies, e.g. for production:

Making Production depend on Acceptance

This means we can’t deploy to Production unless we have first deployed to Acceptance and we can’t deploy to Acceptance unless we have first deployed to Testing. This has pros and cons, so you might want to think about before implementing it. In any case, it gives a nice build chain:

DTAP build chain

So this is it, a different way to model the deployment pipeline using build chains. From here, we can add more build configurations between the deployments that perform automatic tests (e.g. integration tests) but we can also add build configurations that correspond to manual acceptance steps (e.g. manual QA acceptance or PO acceptance). I’ll try to do that in a next post.