Software Configuration Management Principals

Software Configuration Management Principals

SCM: Software Configuration Management serves as a mechanism for communication, change management and reproducibility.

Team Project: A TFS Team Project is a collection of artifacts used by a team to track a related set of work. You must create at least one Team Project before you can begin working in TFS.



In order to make decisions about how to best organize your projects in Team Foundation Server (TFS), it is important to understand that TFS best practices were developed around the concept of a "Team Project".

Scalability of Team Projects: Scalability is limited by the complexity work item types. MSF for Agile Development have been shown to support 500 team projects per server while MSF for CMMI Process Improvement have been shown to support 250 team projects per server.

Common strategies used to structure team projects

Team Project Per-Application (Most Common – Supports both large and small applications as well as multiple release and parallel development).

• Create one team project for each application being developed.

• Releases are manifested in TFS as source branches or as different nodes in the iteration class hierarchy.

Team Project Per-Release (Works well for large teams working on long-term projects).

• Every major application release starts a new team project.

Team Project Per-Team (Provides central control and monitoring of the activities of software development teams).

• Projects aligned with team boundaries in the organization.

• Cluster together applications developed by the same team.

Isolation Mechanisms in VSTF

Branch: An isolation level mechanism that allows one or more people to work on a set of files in isolation. A branch of a file is a revision of the file that uses the trunk versions as a starting point and evolves independently. Branches are labeled with a minor version number that corresponds to the major version number in the trunk. Typically, most of the work happens in the trunk or main branch, which is branched at every release. Small amount of work might still happen in the release branches, which is typically merged back into the main branch.

Note: Branching is the only isolation mechanism that provides collaboration and version changes among a group of developers.

Workspace: Allow individual developers to work in isolation from others. This is where the developer keeps all the artifacts needed to accomplish a task. Workspaces are normally associated with versions of the artifacts. Workspaces include any item that appears in the Source Control Explorer. Typically the following are stored in the source control:

• Source Code

• Test Code

• Library Files (.cs)

• Library Files for 3rd party or shared libraries (.dll)

• Scripts

Workspaces are associated with one or more code-lines.

Shelve set: When a file is changed in the work space, the source control marks it as being edited by the person who edited the file. However, this change is not reflected into the source control unless the file is checked in. There are scenarios where the user wants to save all the changes made to the workspace, but not check them into the source control. For example, the developer might want to send the changes to their peer/manager for a code review. For this purpose, the changes made can be saved as a shelveset, stored in the source control. The shelvesets are not incorporated into the source tree, but can be retrieved on demand and its contents can be viewed.

Typical Branching Strategies in VSTF

Branch Strategies begin by thinking about where isolation is needed that provides version control and the ability for multiple people to collaborate. Compose the isolation scenarios below to form your overall branching strategy.

1. Release Isolation – If you need to work on multiple releases in parallel you may want to isolate them in their own branch.

a. Note: the term “release” does not refer to a new version of the product; it may refer to releasing to a test team from a dedicated branch so issues can be fixed independently from development continuing on the development branch.

2. Feature Isolation – Isolating functionality that is experimental or risky enough to merit its own branch. Developers can collaborate on a feature without exposing the application to instability.

3. Team Isolation - Sub-teams work in isolation from each other, providing the ability to collaborate without breaking changes that other teams are working on.

4. Integration Isolation – Staging area for merges. Merges are often destabilizing, and maintain a branch where active development does not occur is often beneficial.

Branching Consideration

Over-branching is an easy mistake. Weigh the benefits of isolation against the costs so you can make appropriate decisions about the amount of process overhead you’re willing to incur in your environment.

1. Merging – Moving changes between branches. Changes can easily get merged incorrectly resulting in a destabilized environment. This is one reason for creating a staging area for merges. (above)

2. Latency – It takes time to move changes between branches. A Typical merge operation involves stabilizing the source branch, executing merge, conflict resolution then stabilization of the target branch. On large projects, scenarios taking days, weeks or even months are not uncommon.

Structuring your Branching Hierarchy

Structuring your branching hierarchy is important because merging along the hierarchy is easier than merging across the hierarchy.


1. Merging along the branch hierarchy - TFS tracks information about the relationship between branches in order to allow 3-way merges.

2. Merging across the branch hierarchy - If the information is not present, TFS doesn’t know about modifications made in the different branches. Without this information TFS assumes changes have been made in both branches, resulting in manual merges that are otherwise unnecessary. The first time you merge across hierarchy, the relationship is established and future merges are much simpler.

Note: Cross hierarchy merging is not supported through the GUI even after the relationship is established. Cross hierarchy merges can only be done via command line (tf.exe).

Choose a hierarchy that provides the appropriate isolation strategy while still supporting your merge hierarchy.

Branching concerns: A company’s branching model should match the business model. A company that wants frequent product releases may have complex branching structures and need time-intensive merges. Another company may have many customers using independent releases and few branches.

Labels in TFS: Labels in TFS are powerful in that they can contain versions of files from different points in time.



The canonical example is:


1. You label a build
2. You find bugs
3. You change only a few files.
The label represents a collection of points in time and not a single point in time.

Individual versions of files can be assigned labels, and all files with the same label forms a release group. Unlike VSS, TFS source control repository does not support linking to an item from multiple places in the source folder structure, nor does it allow an item to be "pinned" (allow different references to the same file from different directories to point to different versions in a way that cannot be further edited). - Wikipedia

Geographically located TFS structures: TFS Proxy server provides an experience for remote a user that is comparable to that of on-site users. Factoring geography into your decision is not necessary.


Common SCM Definitions

You can find a list of SCM Common Definitions here

References

Branching and Merging Primer

Team Foundation Branching Guidance

Whitepaper

Microsoft (2007)

V1 TSP VSTF Process Guidance

Book

Berczuk, S. & Appleton, B. (2002)

Software Configuration Management Patterns: Effective Teamwork, Practical Integration.

Boston: Addions-Wesley

External Links


Branching Structures at Microsoft

The Terminology of Branching

A Branching and Merging Primer

Branch Structure in Developer Division at Microsoft