How to setup UAT builds for specific revisions?


I have team city doing DEV/trunk builds - code is fetched and compiled whenever code is checked in. Works great - thanks.

I now want to setup a UAT build - a possible release candidate. Any tips on how best to do this with TeamCity.

Its a .Net/nant project.

I can see that I could possibly extend the nant script to have a UAT target which uses an environment variable to tag the current dev trunk with a given label and then gets and builds it. I guess I may even need to split this into 2 dependant builds, one for the tagging and one to build the specified tag.

Or I could outside of TeamCity, create a tag and then update the VCS route for my UAT build to point to that tag.

I was thinking that there might be a way for TeamCity to tag a build - although from other posts, it seems it cannot build a given tag/revision.

So - any tips/comments - what have other people done? What does Jetbrains do?

Thanks in advance,



I went for this option for now:

"Or I could outside of TeamCity, create a tag and then update the VCS route for my UAT build to point to that tag."

This means a separate project for the UAT build and you need manually hit the run button.

Probably not too bad a solution for now.




I have just upgraded to TC3 and see the shared VCS roots stuff, but its still not clear to me if this helps or how I should setup TC. This is for a subversion based project.

I currently have a real world project that we have a DEV, UAT and LIVE build for. This is done as mentioned above, ie we have 3 TeamCity projects, each pointing at the relevant svn root, eg


I am now wondering if TC3 gives me some options for better configuring this.

I guess I can now create my DEV, UAT and LIVE builds under one project, using a shared (or separate) svn root.

What do other people do to achieve DEV, UAT and LIVE builds/staging etc?



TeamCity gives some new options for doing things - I want to see if it makes thing better/simpler...



I suppose that the possibility to have different VCS configurations for build configurations within single project should help you to have better configurations.
You may have single VCS root

and specify checkout rules mapping like
trunk/foobit => .

or tags/uat-1.0.57/foobit => .

Thus, you'll have a single VCS root and different configurations which checkout different parts of this VCS root.

Hope this helps,



Just a quick update - if anyone is interested.

I have switched to getting TC to doing the tagging - makes it easier to control UAT from TC without having to use a separate SVN client to tag the project. It also means that as TC is monitoring the trunk it can track the changes between each UAT build.



Please sign in to leave a comment.