As you start to scale a software development process it becomes apparent that code and user stories have to be merged more frequently. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate and test those changes with everyone. Each team needs to be able to work on its own schedule, this means that if multiple teams want to work on different sized iterations they can. It also means they can deliver changes as needed and on a regular basis, independent of other teams.

To do this in a traditional Software Configuration Management system, you’ll face two major problems.

1. You have to merge these code changes daily for them to be of any use.
2. You also still need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, configuration teams use a single baseline or “trunk” methodology for situations like this, where all changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

In terms of traditional Software Configuration Management, your teams will have to deal with these branching and merging issues. But there are STILL other problems that can happen when you use this trunk methodology:

1. Delivering 2 weeks worth of changes only causes isolation among teams, because teams are working in such a rapidly paced environment.
2. It’s too difficult to pick out each user story from the codebase as it is completed because no tracking is in place.
3. Figuring out the dependencies of those above mentioned user stories is complex.
4. Identifying what changes came from what branch is impossible.

This “baseline pollution” is not scale-able. There are a few ways to alleviate these issues that break the baseline mold. I recommend using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews.  A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. AccuRev supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.