Building from a different VCS root

We have our source code in Subversion. We primarily build and deploy from the trunk, but there are times when we want to build/deploy from a feature branch. For example, there may be code that we want to deploy into the QA environment and test before merging into the trunk and deploying into production.

Our repository looks someting like this:

Where NewFeature1 is a branch from trunk to implement a new feature that will be merged back into trunk when it is finished and ready to deploy.

We have a build configuration in TeamCity for each project that compiles the project and produces an installer (MSI). We then have another build configuration, that depends on the compile, that deploys the MSI to the servers it needs to deploy to. The compile and deploy currently work off of the trunk, but we would like to run the build off of a branch to deploy incomplete features into the test environment.

What is the best way to accomplish this? We are a fairly small group, so I am open to changing how we setup our builds or version control.

Comment actions Permalink


  As I understand, currently you have a VCS root which points to trunk, and a couple of build configurations which use this VCS root to compile and deploy your app.

  I think that for your case the most simple solution would be to create a branch-vcs-root, which points to a branch, and to create copies of your compile/deploy build configurations,
  which use this new VCS root.  Copies can be created via TeamCity UI, and all you'll have to do is to replace used VCS root on VCS settings screen.

  This VCS root can be updated depending on which branch you're going to build next time.

  The drawback of the approach is that if you'll want to change build configuration settings, you'll have to make it twice - for trunk configuration and for branch configuration.

  You may also want to vote for the issues:
  TW-5428 Support variables in VCS roots, dynamic VCS roots
  TW-3350 Build Configurations inheritance

  Kind regards,

Comment actions Permalink

That is exactly the solution that we came up with and decided to pursue. Our build configurations very rarely change, so that isn't much of a problem. We now have the trunk, which builds and deploys for production, and a specific named branch that builds/deploys for the QA environment. The QA branch can be replaced with whatever we want to deploy, including the trunk if we want to deploy production code into QA. Obviously, this requires some coordination, but it's not too onerous.


Please sign in to leave a comment.