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.
Then, I’ll attach the project’s VCS root to the Deploy Stage as well. This is necessary to allow for snapshot dependencies:
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:
And configure the artifact dependency to use the artifacts from the same build chain:
This creates a build chain between the Commit Stage and Deploy Stage, which is visually more user friendly:
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:
I’ll also change the build type into a deployment project:
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:
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:
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:
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:
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:
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.