Better Concurrent Development

through Branching and Surround SCM

by Peter Vasiliauskas

To compete in today’s business environment,
development teams can no longer afford to build
applications sequentially. Instead, they need to
embrace a concurrent development methodology.
However, many companies are ill-equipped to do so
because they have not implemented effective change
management techniques and policies. Many that have
do not make optimal use of the tools at their disposal.
One way to manage concurrent development is through branching.
Branching provides a way of logically organizing and managing
code changes throughout the development lifecycle. Without it,
change management simply becomes a means of archiving files
and tracking changes. When development only occurs in a single
branch, or without any branches and only labels, it becomes
difficult to maintain a stable version of the product because the
code base is continually evolving.

Sequential development simply means that each step in the
development lifecycle happens in sequential order—new feature
development, followed by defect fixes, followed by a release
(Figure 1). The obvious drawback is that new feature development
must be stopped in order to fix defects.
In principle, branching is similar to labeling. For instance, labels
and branches can both be used to capture the state of code at
one point in time. But branching has the distinct advantage of
separating feature development from defect fixes. This separation
allows developers to work in parallel on the same product without

Feature Fix Release Feature Fix Release

Development Defects Product Development Defects Product

Time

Figure 1: Sequential Development

the fear of releasing an incorrect version or having previously fixed

Feature Feature
Development Development defects mysteriously reappear.
Release Release
Fix Product Fix Product
Defects Defects “Branching is integral to version management, software build
correctness, and release management. It enables parallel
Time
development of a new system and provides concurrent support
Figure 2: Concurrent Development of multiple releases by labeling each instance of a branched
configuration item and establishing a mapping between the label
Concurrent development shortens the overall development and the module revisions...”1
timeline by developing new features and fixing defects in
In addition, branching allows developers to make controlled
parallel while working from a common code base (Figure 2).
changes to isolated code, meaning they will be less confused
But concurrent development without a strategy to manage code
about where to make changes and can also implement new
changes makes it difficult to know what features and defect fixes
features without affecting a release that is close to completion.
are included in a release.
Consequently, there will be less anxiety about code freezes or other
development milestones.

Figure 3: Branch Tree in Surround SCM
Branching in Surround SCM
A baseline branch is where all the product code and other
associated tools or libraries for a particular project are located. It is
the basis for future development and acts as the parent branch for
the project. In Surround SCM, the baseline of code can be either
in a mainline branch or a child baseline branch. A mainline branch
serves as the root of all child branches. It can be used as the project
baseline branch (Figure 3).
Other branch types supported by Surround SCM are snapshot
branches and workspace branches. Snapshot branches mark the
completion of a particular release when you want to capture what
was actually released, such as a QA build or a final release build.
Workspace branches are private branches that a user creates
when they are the only person that will be making changes in that
branch. It might be for a feature that has only one developer and
needs to be separated from the rest of the code, or it may be a
place for users to test features they want to keep isolated from
the rest of the code.
How and When to Branch
Create a child baseline branch whenever it is necessary to make
separate changes to the baseline code. Child baseline branches
are most commonly created at the feature freeze and code freeze
development milestones. Child baseline branches can also be
created for other reasons such as a beta release or to separate
developers working on a large feature. To keep branches in
sync, child branch changes can be
promoted into parent branches;
LEGEND
likewise, parent branch changes can
on new features for the next release can continue working in the
baseline branch. After defects are fixed in the feature freeze branch,
promote the changes to the baseline branch so the next product
release includes the defect fixes. In addition, make the feature
freeze branch read-only or make a snapshot branch after all defects
are fixed to ensure developers do not inadvertently make more
changes to the code.
The code freeze milestone, which is when the product is ready for
release, is the next time that a branch should be created. Creating
a code freeze branch as a child of the feature freeze branch at this
milestone captures the code to be released. Developers should not
be allowed to make any unnecessary changes in the code freeze
branch. If a critical bug is found, it can be fixed in the code freeze
branch and promoted into both the feature freeze and baseline
branches. Make the code freeze branch read-only after the product
is released to ensure the actual released code is captured. This can
be useful when rebuilding a previous release.
Branches can also be created for a specific feature that affects a
considerable amount of code. Creating a feature branch allows
developers to work on the feature in a separate environment,
without worrying about how their changes affect other developers
and vice versa. When feature development is complete, rebase the
baseline branch code into the feature branch so the new feature
can be tested along with any new or changed baseline branch code.
After testing is complete, promote the feature branch changes to
the baseline branch for inclusion in the next release.
Branching example
In this example, Surround SCM is used to demonstrate how
branching can be used in a typical software development
environment. Development begins on a new software product
named MyProduct. A baseline branch named MyBaseline is created
nc –

nc –

nc –
ra 0”

ra 1”

ra 2”

Branch
be rebased into child branches.
h

h
e b .0.

e b .0.

e b .0.
ez t 1

ez t 1

ez t 1

Developer Changes
fre uc

fre uc

fre uc
de rod

de rod

de rod
co yP

co yP

co yP

The feature freeze milestone, which Branch Creation/Merges

“M

“M

“M

is when new feature development

ra ” –
h
e b .x
nc
ez 1.0

for the next release is complete, is

fre ct
re du

create branch create branch create branch

tu ro

an ideal time to create a child branch

fea MyP

promote changes promote changes

“

from the baseline. Branching at this

point lets the development team
ra ” –
h
e b ine
nc

promote changes promote changes

focus on different responsibilities.
lin el
se as

create branch promote changes

ba MyB

Developers working on defect

“

fixes for the current release can

make changes in the feature freeze time
branch, while developers working Figure 4: MyProduct branching diagram
for the source code and associated
files. All feature development takes
place in this branch (Figure 4).

After development for the first release

is complete, a feature freeze branch
named MyProduct 1.0.x is created.

Feature development for the next

major release continues in the
MyBaseline branch while some
Figure 5:
developers fix defects in the MyProduct Promote Branch and
1.0.x branch. Snapshot branches mark Promote Preview dialogs

the completion of a particular release

when you want to capture what was
actually released, such as a QA build
or a final release build.

A code freeze branch named MyProduct 1.0.0 is created after

deciding that MyProduct is releasable. Critical defect fixes for the
release are made in the MyProduct 1.0.0 branch and promoted to
both the MyProduct 1.0.x and MyBaseline branches (Figure 5).

After the product is released, the MyProduct 1.0.0 branch is made

read-only and a snapshot branch called Final Release 1.0.0 is made
to ensure the released code is captured (Figure 3).
A feature branch named FormatChange can also be created
from MyBaseline. Developers working on a large feature, such
as a database format change, work in this branch. Once feature
development in the FormatChange branch is complete and tested,
changes made in MyBaseline are rebased into the FormatChange
branch. This branch is then re-tested to ensure the new feature
works with the existing code. After the branch is re-tested, the
changes in the FormatChange branch are promoted to the
MyBaseline branch.
This process of branching and promoting changes continues
for all minor and major releases. For example, a branch named
MyProduct 2.0.x is created from MyBaseline when development
on the next major release is complete.
Conclusion
Branching will shorten your product lifecycle by enabling parallel
development for defect fixes and new feature enhancements.
Emergency releases can be easily created from child branches,
with minimal effect on current development efforts. Feature
branches can be created to separate developers working on a
feature that affects a large amount of code. Your use of branching
depends on your company’s needs and business processes.
Regardless of the development methodology you follow, Surround
SCM provides a flexible branching solution that can be easily
adapted to your development environment. Seapine Software can
help you formulate a branching strategy for your next development
initiative. Contact Seapine Software today at 1-888-683-6456, or
visit us online at www.seapine.com.
References
1 Chuck Walrad and Darrel Strom, “The Importance of Branching Models in SCM,” IEEE
Computer Society, September 2002, 31.

About the Author

Mr. Vasiliauskas is a software engineer at Seapine Software, Inc. With more than nine years experience in the software development industry, Mr. Vasiliauskas performs
software design, development, and testing on Seapine’s award-winning software change management product line. His technical specialties include developing cross-platform
applications with C++ and Qt.

www.seapine.com

5412 Courseview Dr., Suite 200 TEL 513-754-1655 ©2006 Seapine Software, Inc. TestTrack Pro, TestTrack, Surround SCM, QA Wizard, SoloBug, SoloSubmit, Seapine CM, Seapine
SQA, and the Seapine logo are trademarks of Seapine Software, Inc. All other company products and company names are either
Mason, OH 45040 FAX 513-754-1660 trademarks or registered trademarks of their respective companies. All rights reserved worldwide. Information presented here is
accurate as of the time of printing, but is subject to change or revision without notice. 6149.1 Better Branching.indd 07/06