Snapshot Dependency - Don't promote pending changes unless done manually

Basically, this is the same question that was asked on StackOverflow, but I am not satisfied with the answer there.

I have 2 build configurations to build deployment packages for Test and Production. I want to trigger both of them manually, but I want both of them to always use the same VCS commit (in Git) when they run. I DO NOT want to use the same binaries (because Microsoft designed ASP.NET website projects to work this way and it would take a lot of extra scripting to do so). Another reason is because I might want to eventually deploy my project directly to the production server, but this is not possible on my test environment because of a firewall I have no contol over, so I would like these to be separate configurations if possible.

I figured out how to make them use the same version number.

The problem is, if commits are added to the VCS after the Test configuration is run, then triggering the Production configuration causes the the Test configuration to run again. I need to ensure that these commits go through a manual testing process before being approved.

My question is - is there a way to get TeamCity to always use the VCS sources from a snapshot dependency without ever causing the dependency to be rebuilt from the latest commit? Is there a way to get it to build based on a specific commit? If not, is there another TeamCity feature I can use to get the same effect?

The only reasonable solution I have been able to come up with (without spending too much time) is to merge both of my build configurations into one in order to always run them at the same time. This isn't ideal because it would take twice as long to run and will use up disk space for Production artifacts that are never actually deployed. Not to mention, I wouldn't be able to easily tell which builds never made it to production.

I am using TeamCity 7.1, but will consider upgrading if there is a new feature that can do this.

2 comments
Comment actions Permalink

It seems you are looking for "Actions / Promote...", but maybe I have misunderstood your problem.

You may also consider created a dedicated (temporary) branch for every release candidate in the VCS. It makes things in TeamCity more explicit, and also in the VCS itself.

0
Comment actions Permalink

Thanks, it looks like Actions / Promote will do what I want.

It would be nice to make Actions / Promote for the latest build in the Test environment the default option when clicking "Run" on the Production environment (or possibly hide the Run button in the Production configuration), though so it isn't possible to inadvertantly push untested changes through. Releases for web sites shouldn't require a technical manual, just a button click.

I guess branching in the VCS would also work, but would add more steps to the release process. The whole point of migrating the release to TeamCity is to eliminate steps in the release process so it doesn't take so long.

0

Please sign in to leave a comment.