Almost two years ago we started a new project (related to SOA/BPM infrastructure) on a large telco organization. Project is going very well and run on production since last summer. We develop more and more modules and things going well. Now it’s time to transfer the knowledge to client’s developers. The main things that we have to taught them are naming conventions, source code, architecture and administration tasks. As we will be in the same team for a few more months, first of all we have to explain them our version control branching strategy.

So, on this post I will explain our approach on version control branching strategies. An approach that we defined after spending a lot hours on conversations and reading books.

Facts:

• We have many individual/autonomous applications that are related to each other.
• Each application is dependant to at least another application (based on WSDLs).
• We do not have quality assurance manager, neither release manager, so we do all the work, which is related to design, development, release management and administration tasks.
• We have defined 3 types of testing (related to release):
  • Unit testing: Testing that can be done by us (developers) without communicate with external systems (like CRM, Billing, etc.).
  • Integration testing: Testing that includes communication with external systems (Billing, CRM, etc.) and is done by developer(s).
  • User Acceptance Test: End-to-End testing that is performed by client without us.

Rules:

1. We follow the unstable branching strategy. This means that trunk contains the latest code, regardless of how must stable it is.
2. Branching is used only for release candidates, releases, bugfixes and experimental code.
3. Use consistent tag-naming schemes for the tags:
1. Branch tags will always start with ‘BT_’
2. Release candidate prefix is ‘RC_’
3. Release prefix is ‘R_’
4. Bugfix prefix is ‘BF_’
5. Experimental code prefix is ‘EC_’
6. Developer tags start with ‘DEV_’
7. Branch names will always start with ‘BR_’
4. A tag is always created on trunk:
   1. Before create a branch: <branchName>_BASE (e.g RC_2_0_ApplicationName_BASE)
   2. Before merge a branch to trunk: <branchTabName>_PMB (PMB: Pre Merge Branch)
   3. After merge branch to trunk: <branchTagName>_AMB (AMB: After Merge Branch) (e.g. RC_2_0_ApplicationName_AMB)
5. Always do tags in branches after do work, with suffix ‘–counter’ and always increase counter (e.g. BT_RC_2_0–1_ApplicationName).
6. Merge back frequently; the fewer changes there are to the trunk, the easier they are to merge.
7. Create a Wiki page for each application and write details for each individual tag and branch.
8. Record tags in related issues/bugs on your bug tracking system.

The above rules/steps are for only one application, but they are the same for all applications.

I will continue this topic to another post (released at last) giving an extended example with names and full steps for a release candidate scenario.

Hope it helps,
Adrianos Dadis
—
Democracy Requires Free Software.