0
votes

Consider the following build configurations:

[Build & Package] -> [Deploy to TEST] -> [Deploy to LIVE]

I have set these up so that:

  • [Deploy to TEST] has both snapshot & artifact dependency on [Build & Package].
  • [Deploy to LIVE] has snapshot dependency on [Deploy to TEST] and snapshot and artifact dependency on [Build & Package]

This links all the builds together nicely in a build chain which allows us to build and package regularly, then when we're ready, extend the chain into the TEST environment. It can sit in here for a week being tested, then we run the [Deploy to LIVE] configuration knowing that we're deploying the same binaries that we've been testing for the last week. Great!

We use two repositories, "Source" for the code itself, and "Config" for deployment parameters. This allows deployment/environment settings to be modified and tracked by the Ops team without forcing the Source VCS repository to increment revisions, therefore we avoid muddling environmental/configuration issues with source issues. Also great.

The Config VCS root is attached to both the [Deploy to TEST] and [Deploy to LIVE] configurations.

The problem we just encountered is that since our successful deploy to TEST (Source:1002, Config:6) a week ago, we changed the settings for the deploy to LIVE, which resulted in a new revision of the Config VCS root (Config:7). Now we want to deploy the known-good Source:1002 to LIVE with Config:7, but the build chain insists on using Config:6 to maintain the snapshot.

How can we force TeamCity to allow us to use a newer revision of config in LIVE, but keep the build chain intact?

We've committed subsequent changes into Source which we don't want to put in LIVE yet, so I can't just simply re-run everything from the beginning.

1

1 Answers

0
votes

I just thought I'd update this question as I appear to have come across the answer myself while setting up a pipeline for a new project.

The key was basically to add a new TeamCity build configuration for the exclusive purpose of getting config XML files from the VCS and storing them as artifacts, e.g. [Get Config].

I removed the Config VCS root from our [Build & Package] configuration thereby disconnecting it from the build chain, and attached it to the [Get Config] configuration. Now when [Get Config] runs it basically just gets the latest config xml files from the Config VCS and stores them as nice versioned artifacts.

Then, I added a new artifact dependency from [Deploy to TEST] to [Get Config], configured to get artifacts from the "Last successful build". So, [Deploy to TEST] will always run using the latest config, even if we need to make last minute changes to it, without affecting the build chain or distorting the package versions.

Another benefit is that if we unknowingly mess up the config, using the Run Custom Build dialog, we revert back and use older [Get Config] builds to run a deploy with a known good configuration.