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.