Releases with multiple long lived branches using maven

Question

So here's the Subversion, Jenkins, Beanstalk setup:

• trunk/ -> development main line
  • CI builds on checkin
  • Successful CI build spawns CD build that pushes to "Testing" Beanstalk environment
• branches/qa/ -> current release candidate
  • CI builds on checkin
  • Successful CI build spawns CD build that pushes to "QA" Beanstalk environment
• branches/prod/ -> current release
  • CI builds on checkin
  • Successful CI build spawns CD build that pushes to "Prod" Beanstalk environment

Basically what I want to do is this:

• Development cycle starts in trunk (trunk: 0.1-SNAPSHOT)
• When development cycle is complete branch to qa and being qa cycle. Also begin next development cycle in trunk (trunk 0.2-SNAPSHOT, qa: 0.1-SNAPSHOT)
• When qa cycle is complete branch to prod and perform maven release. Also begin next qa cycle (trunk 0.2-SNAPSHOT, qa: 0.2-SNAPSHOT, prod: 0.1)

The idea is to have short sprints where at the end of each a development cylce ends and a qa cycle begins. When the qa cycle is complete it is pushed to a production environment.

I'd like to preserve the branches and do merging to\from the branches instead of deleted and re-created. The idea being that any fixes made in qa would be merged back intro trunk, and any changes made in prod would be merged back into qa (and back into trunk).

prod is therefore a "hot" branch and represents the current state of the production environment.

this is for a small team of developers working on week long sprints.

Questions:

1. How does this setup sound?
2. Can i get maven to act correctly, or will i need to script this?
3. Who is your daddy? And what does he do?

Answer 1

I wouldn't recommend a qa and prod branch. Read up on subversion best practices. I'd recommend The SVN Book, in particular chapter 4 regarding branching/merging.

You should version every release even if it is to QA (through tags). Trunk is used for current development work, tags are for released versions(defined as "feature complete", not what environment it is in), and branches are for defect fixes (amongst other things).

Sample Scenario:

Version 1.0 is in production, your team has just released 2.0 to QA for testing, and are now working on a 3.0 release. At this point you would have:

• /trunk (developers working on 3.0)
• /tags/2.0 (used for QA)
• /tags/1.0 (historical for what is in production)

If your QA team finds a problem in 2.0, you'll create a branch off of the 2.0 tag. Make your fix, merge to trunk then release the branch as 2.0.1 (another tag). You would then be left with:

• /trunk (developers working on 3.0, + the 2.0 defect fix)
• /branches/2.0.* (use the * character to indicate this is where all 2.0.* fixes will be committed. You can reuse this same branch if yet another defect is found in the 2.0 code)
• /tags/2.0 (original tag QA was testing with the defect)
• /tags/2.0.1 (2.0 code base, with ONLY the defect fix)
• /tags/1.0 (historical for what is in production)

Answer 2

I've done some similar work around branching and releasing before, and in my experience, the setup you have described has ended up becoming very unwieldy and bureaucratic before too long.

Domenic D.'s answer is pretty close to the sort of set up I would prefer, particularly with a small number of developers.The more branches you have, the more complex the management of the code base becomes and the more likely you are to introduce error through bad merging practices.

One thing you don't mention that is important, in my opinion, to get right at the start is your check-in policy. The SCM is not a backup for incomplete work, you should strive to make sure the main lines are at the very least always building. Be strict about this, it will make everybody's life easier in the end.

The main thing is though, no matter what release procedures you come up, make sure you get buy in from your team and that they don't have to be "forced" into place. That is a sign that there may be something wrong with what you've come up with is not right and will probably be quickly ignored or subverted.