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)