Mercurial workflow with selective feature deployme

for a team of 12 developers, can you help me determine a process and workflow for building and deploying a product using mercurial for source control and team city for build server?

we have a system that tracks issues and enhancement requests. most of these are pretty small bugs and enhancement worked on by one developer in a timeframe of a day or two up to a week. what i want to accomplish is to have business persons and IT management negotiate priorities for tickets on which developers work. when completed, these changes are committed and pushed to the central repository and marked as dev complete in the ticketing system. the qa and business teams should then be able to select from the tickets that are marked as dev complete and have those included in our product for the next release based on priorities, the amount of qa necessary, and qa resource avaialbility.

i was originally thinking i could get this implemented by having developers commit changes on a new named branch for each ticket. with this, the branch for each selected ticket can be merged onto default and the build and deploy to qa (and ultimately production) can be executed.

the problem with this is continuous integration. it appears to me i can only configure teamcity statically to build off a particular branch in our central repository. maybe this is a limitation of the version of teamcity we are on. currently using 5.0.3, but upgrading is an option (and something we'll probably do anyway). maybe there's some tricky way to make it build off the tip and therefore the head of the branch on which the commit triggering the build occurred? if developers are committing and pushing on different branches for everything and these branches don't get merged into default until some time later - enough later that qa is now waiting for these changes to build and if there is a broken build, the cost is higher - there isn't a specific branch on which for us to do a continuous integration build.

perhaps i am making this overly complicated and/or overlooking something simple. help is appreciated. is there a way i can accomplish this selective integration for releases and still have continuous integration at the time developers are doing pushes?

回答1:

Using Jenkins (formerly Hudson) it's easy for developers to duplicate an existing job (ex: a job that builds the newest head in 'default' branch) and make a small change (ex: a job that builds the newest head in the 'jim' branch). (Though read my comment above about why named branches probably aren't the right choice for what you're doing). Presumably teamcity has something similar.

Another route is to do just as you said and just have the builder always build the 'tip' regardless of branch. You can probably acheive that by just putting in 'tip' as the branch name. It's not a branch specifier, but teamcity likely just does 'hg update -C -r BRANCHNAME' and 'tip' will work just fine there.

回答2:

i have concluded that the direction i was trying to take is just not going to work. will have to do this a different way.