Welcome!

Java Authors: Pat Romanski, Liz McMillan, Elizabeth White, Dana Gardner, Jim Kaskade

Related Topics: Java, .NET

Java: Blog Feed Post

Avoiding Merge Hell with Development Hierarchies

Many traditional SCM tools do not easily support or surface a development hierarchy

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.

More Stories By AccuRev Communications

AccuRev Inc. is a US-based software vendor focused on optimizing and automating the software development process for organizations challenged with today’s highly evolving agile, geographically distributed, and parallel software development environments.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.