Teamcity triggering multiple promotions
Answered
Im trying to figure out how to chain multiple 'promotions' (by a user clicking once) whilst ensuring that ever build down the chain is not queued. My current setup is as follows, NOTE as my application is a white label the configuration described below is repeated for every site we own.
- Build & Test - Creates zipped artifact
- Deploy to Testing - Has artifact and snapshot dependency
- Deploy to Staging - Has artifact and snapshot dependency
- Deploy to Production - Has artifact and snapshot dependency
When promoting to production i want it to deploy accros all our websites (without having to manually click promote on each build). Also when doing this i need to ensure that a build is not queued down the chain so it doesn't end up deploying the latest checked in changes.
I wanted to know whats the best strategy in doing this?
Please sign in to leave a comment.
Hi Stuart,
TeamCity's approach to chains is via multiple build configurations that have snapshot dependencies on each other. A typical approach to trigger multiple "final" builds simultaneously is to have a dummy configuration that has a snapshot dependency on each of them. Triggering (or promoting manually) this dummy configuration would bring all the dependencies up to the queue.
On a manual promotion, you should be able to select which changelist you want to build (or use if there is a suitable build already) by clicking on the ellipsis right next to "Run", and selecting the right commits in the "Changes" tab. This selection should also be followed transitively along the dependencies chain, e.g. the dependencies should build only the selected changes.
If I missed something please don't hesitate to ask.
Thanks for replying Denis.
That all makes sense, promoting via changes however is a little difficult as you end up getting a lot of noise from all the checkins which makes it harder to ensure your not promoting something you shouldn't be. Is there anyway of doing this with the build number as you can easily see which version is currently on testing or staging before promoting?
The usual approach is to create a specific branch in the VCS with the changes that you want to push to each environment, and then run the build on that branch without caring for the changes that happen to the other branches. Not just for TeamCity purposes but also to keep the core VCS organized in case you did it manually without CI. <edited out for misunderstanding>
Hi Stuart,
sorry for the confusion in the message before, I've edited it out because it wasn't accurate, for some reason I kept thinking of "promoting" as a snapshot dependency bringing up its dependant builds instead of the "Promote" action inside a given build's menu.
If you go to the build you want to promote, and select promote, you will get a list of all of the transitive dependencies, where you would be able to select the final dependency, which would in turn publish the correct artifacts from the original build. This should do exactly as you want if I'm not mistaken.