Managing Branch Per Feature

######Short Questions######
If we have several features being developed at the same time in  different branches we need to manually create new VCS roots all the time  in TeamCity in order to build them.
Is there any way to avoid this with build parameters or anything else?

We have fewer environments than branches meaning we can't test them all concurently.
How do other people handle this?


######Full Question######
We have a client/server application in an svn repo that we build and deploy using TeamCity.
We used to commit everything to trunk and then cherry pick items for a release.
This made TeamCity simple as we had a build for trunk and a build for a prod pranch.
Any new features were always in trunk and so were always deployed to the dev environment nightly for people to test out.

The problems came when we would miss commits in the cherry picks meaning the feature wouldnt be deployed to prod as in dev, or when there were bugs in prod that worked in dev because not everything had been merged and the code was out of sync.

Therefore we decided to switch to trunk being production and branching per feature.
This has worked well so far in terms of merging code and deploying the prod code from TeamCity.
e.g.
We have several UAT envs that are supposed to be same as prod so we run a  custom build that has trunk as a VCS root with build parameters that  specify the environment to build to.

However, managing the builds to our different dev envs has been harder.

If we have several features being developed at the same time in different branches we need to manually create new VCS roots all the time in TeamCity in order to build them.
Is there any way to avoid this with build parameters or anything else?

We have fewer environments than branches meaning we can't test them all concurently.
How do other people handle this?

Please sign in to leave a comment.