Approaching Parallel Development with Branch - Merge Strategies

[article]
Summary:
Many times when managers first consider parallel development, it appears to be a very effective way to manage changes to concurrent streams of development. This is somewhat true if the project uses an SCM technology that allows for stable branching and establishes discreet project and maintenance branches. However, what is often forgotten is that while branching is a great way to separate code changes, at some point merging will have to occur. This article provides guidance for approaching and performing parallel development.

Many times when managers first consider parallel development, it appears to be a very effective way to manage changes to concurrent streams of development. This is somewhat true if the project uses an SCM technology that allows for stable branching and establishes discreet project and maintenance branches in which developers can modify their code.

However, what is often forgotten is that while branching is a great way to separate code changes, at some point merging will have to occur. In other words, parallel development is meaningless without a branching and merging model to support the development. This brief article hopes to provide guidance for approaching and performing parallel development.

Why Parallel Development
Some claim that parallel development will increase productivity by allowing two or more streams of development to occur at the same time. This is a tempting scenario for Product and Project managers who are always looking for ways to improve their time-to-market goals. Moreover, parallel development may occur within a project or across projects (and often times both).

In many cases, parallel development occurs within a project release context where two or more developers are working on the same piece of code at the same time in different workspaces. In other cases, parallel development occurs across streams of development including the: current project release (2.0), future release (2.1), maintenance or bugfix of past releases (1.0.1), and customer specials or variants (2.0a, 2.0b, etc).

Given the above possibilities for parallel development, most groups end up performing parallel development at one of these levels (within a project or across projects). And finally it is important to understand that parallel development may occur anyway so it is important to learn the concepts of parallel development and what can be done to approach it in a constructive and productive way.

Pages

About the author

Mario  Moreira's picture Mario Moreira

Mario Moreira is a columnist for the CM Journal, a writer for the Agile Journal, an author, an agile and CM expert for CA. He has worked in the CM field since 1986 and in the agile field since 1998. Mario has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the agile arena having implemented Scrum and XP practices. Mario is the author of Adapting Configuration Management for Agile Teams  and Software Configuration Management Implementation Roadmap. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at http://cmforagile.blogspot.com/.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09