Example VSS Framework - Source Code Management - Part 1

,

This article provides a working framework for source code

management in Microsoft Visual Source Safe.  The framework

presented is not only designed purely for a system currently under

support and maintenance, but will support other development

initiatives (mini projects) that may be adding new

functionality.   

For those working on multi-client software in which production

source code is at different patch levels (and may include custom

code), then you will need to rework VSS to adopt the strategy.

The article is scenario driven, starting with a very basic

scenarios as we then move to more complex changes.

Appreciations/Terminology

CCM

Change Control Manager.

Project

Is similar to a folder in explorer, contain configuration items

(files), VSS will automatically version projects and files with an

internal value.

Branch

Is synonymous to a copy in explorer, but VSS maintain

links between versions of branches to facilitate

merging at some later stage. VSS via its internal

version numbering will maintain the logical branch history in

order to facilitate merging with any other branch. 

Share

A shared file is a link to its master, or in other terms, a

shortcut.  The shared file will be automatically pinned; to

alter it you must unpin it.  If the shared file is altered its

master will also be changed, along with any other shortcut

(share).

Merge

Process of merging the changes from two branched files.  The VSS GUI will show the hierarchies of branches and associated

links/paths, broken branches can not be merged too, or branches

from incompatible parents (can merge the branches from two

different trees!).

Build Phase - Moving to the new change control structure

The new structure of VSS is:

This structure maps to your equivalent development, test and

server environments.  Source code for development and test

environments is built from VSS production code project and the

subsequent development/test project code applied over top (roll

forward) to form the environment.  The developers need to

manage themselves when there are multiple 'versions' of a DLL or

other file source moving into test over time.  Either way, the

VSS environment allows the full 'build' of development or test

servers from a known image of production source code (which is

critical):

The /production project folder includes the names of other

applications currently under the change control process.  To

start the process of change management using this structure, we

will be introducing a new application called 'MYAPP'.  The CCM will:

  • Create a new project in

    /production call 'myapp; create sub-projects to

    hold myapp's source code

  • Label the MYAPP project as 'MYAPP Initial Release'
  • Arrange a time with the

    developer(s) and check-in source code into the projects created

Giving this structure:

The production folder is 'read only' for all but the CCM.

First Change Control

All application project changes in the /production project folder, follow a change control window path, as such, in the

development project folder the CCM will:

  • Create a new project in the

    development folder representing the change control window (if none

    exist)

  • Notify developers of VSS

    development project status

Giving us this structure:

The MYAPP developer needs to alter his single ASP and COM files for

this change control window, the developer will:

  • Create a MYAPP project under

    the CC001 project in development

  • Expand the production source

    code project, navigate to MYAPP and the COM Libraries project, then

    with a right click and drag the project to

    /development/cc001/myapp and from the menu displayed, select

    share and branch

  • Check the recursive check box if any sub-project folders

    are also required.

  • Do the same for Web

    Sites.  Important - If there are multiple websites and

    you only want selected projects, then manually create the same

    structure in dev then share off the projects from there. 

  • REVISE WHAT YOU HAVE DONE - ONLY SHARE/BRANCH THE FILES REQUIRED FOR THE CHANGE CONTROL. IF YOU

    FORGET FILES OR REQUIRE OTHERS, THEN REPEAT THIS PROCESS FROM THE

    SAME PRODUCTION SOURCE PROJECT.  ALWAYS KEEP THE SAME

    PROJECT FOLDER STRUCTURE AS IN THE PRODUCTION PROJECT

  • If you make a mistake, delete

    your project and start again.

We now have this:

To review where the original source came from in the production

folder:

  • Select a file
  • Right click

    properties

  • Select the paths tab
  • Click links if the GUI

    is hard to read

Check in/out code as need be in the development project. The DEV server environment is then built (refreshed) from this

source in VSS.

Moving Code to TEST

The CCM will:

  • Create a CC001 project in the

    /test project “folder”

The developer(s) will:

  • Remove any reference to Myapp

    in the /test/cc001 project (if applicable)

  • Expand the cc001/myapp project,

    select myapp then right click and drag to the /test/cc001 project,

    selecting the share and branch option

  • Select recursive check box

    (as all code for MYAPP is going up as a single unit of

    testing).

This will give us:

This scenario will assume all code will transition from DEV and

TEST and into PROD. The TEST server environment is then built (refreshed) from this

source in VSS.

Overwriting existing code in TEST from DEV

During testing we found a range of problems with our ASP

page.  We fixed the problem in /development and now want to

overwrite/replace the VSS /test copy for the CC001 change

control.

The developer will:

  • Check-in code in the

    development folder for the change control

  • Navigate to the

    /test/cc001/myapp/Web Sites/ project

  • Delete from this point

IMPORTANT - You can do individual files if you need to,

rather than a whole project !

  • Goto the

    /development/cc001/myapp project folder, right click and drag the

    websites project

Test now has the fixes made in dev.  Use the files to

build/update the test server environment.

Taking a Change Control into Production

The developers will:

  • Ensure all code in the

    /test/cc001 folder is OK to go live

  • Remove any files that are not

    ready

The CCM will:

  • Create a new project in the

    production project folder to represent the change control going live

  • Share and branch the myapp

    application (entire structure) into the new project folder in

    production:

  • Navigate to the

    /test/cc001/myapp project, get a list of files to go live

  • Navigate back to

    /production/cc001/myapp project and locate these files, for each

    file:

    • Select the file,

      SourceSafe,  Merge Branches

    • Pick the appropriate branch to

      merge to

  • Press the merge

    button.

  • Check conflicts if need be.

The /production project structure is:

Once all files are merged into the new production project folder,

the production server environment can be built from these altered

files.

The branching in VSS provides an effective solution to managing

versions and the inter-relationships between components (files) and

physical projects.  The above scenario for example gave us

this tree like structure to work from (versions in diagram are VSS

internal versioning numbers - use labels to assist with

source identification if you are having trouble with it):

Rate

Share

Share

Rate