3

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?

Dave Rael
  • 1,759
  • 2
  • 16
  • 21
  • Named branches aren't the right choice for short-lived efforts like bugs and features. They're better reserved for eternal concepts like 'stable' and 'experimental', with tags use for releases. Read http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ – Ry4an Brase Mar 02 '11 at 06:20

2 Answers2

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.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • This works, but just note that two simultaneous pushes from two developers will make TeamCity leapfrog over the first one if the timeframe is short enough. – Lasse V. Karlsen Mar 02 '11 at 08:38
  • I've seen that with Jenkins too. Separate jobs avoids that, but always-the-tip is susceptible to it. – Ry4an Brase Mar 02 '11 at 15:02
  • thanks for the information guys. i'll experiment a little with throwing tip in the branch in the build configuration. never occurred to me something that simple could work. i see the point about named branches. will consider this and talk it over with my team. will be back here to report results and accept answer. – Dave Rael Mar 02 '11 at 16:16
  • just plugging in tip didn't work. still gonna try a little more to see if i can figure out a way to trick it. – Dave Rael Mar 04 '11 at 23:22
0

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.

Dave Rael
  • 1,759
  • 2
  • 16
  • 21