SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Example VSS Framework - Source Code Management - Part 2

By Chris Kempster,

This article continues on from Part 1, expanding on other source control scenarios and how our defined project structure and VSS branching functionality accommodates it.    

I want to move files to next weeks change control

In the previous example, we only processed the single ASP file, for some reason, the developers wanted to delay the DLL for the next round of change controls.  Therefore we need to get the COM file in /development/cc001 into the new project /development/cc002 for it to be included in that change window.

The CCM will:

  1. create /cc002 in /development folder
  2. The developer will branch the DLL code from /production/cc001 into /development/cc002

  1. Select the file(s) to be merged in /development/cc002.

  1. Resolve the differences (we know what they are and are fine with all of them)

After the merge, double check your code before moving on with development.

What does VSS look like after 2 iterations of change?

After two complete iterations of changes, we end up with this structure in VSS:

We have a snapshot of production for all iterations:

  • Initial snapshot
  • change control 1
  • change control 2

We can also rebuild the test server from a production build and roll forward through change controls.  In the development project, we have a well managed source environment for each change and its progression through the environments.

I forgot to take a file into production for a schedule change

The CCM needs to:

  • Check files are in the equivalent /test project folder
  • If not, the developer should update this project folder by branching the missing files from the equivalent development folder.
  • As the /production/ccxxx folder already exists (had to for other code to go into prod), the CCM simply merges this missing file into the project and takes the files from here to the production server environment.

I have a special project that will span many weeks, now what?

The scenario is this:

  • We do weekly change controls
  • A new special project will take 2 standard chance control iterations to move into production
  • The standard change controls will be altering files the special project will be using
  • We need to ensure that the standard change controls are not affected and visa versa for the special project until the special project is ready to do live.

To manage this we need to ensure these rules apply:

  • Strict branching from a single point in time from the /production project folder
  • The special project files will merge with some future change control and go live with this change control window to ensure VSS consistency.

At CC003, we start a new special MYAPP project that affects the single ASP file we have.   The CCM will:

  • Create /development/CC003 project
  • Create /development/MYAPP Mini Project

  • The developer branches in the files to be altered into both /development/cc003 and /myapp mini project 

  • Now both project folders in dev are branched from the single tree root (for one of a better word).  Developers continue to work in DEV and branch to test as need be to facilitate standard app testing.

Merging MYAPP Mini Project back into the standard change control.

Here we assume CC003 and CC004 changes over the last 2 weeks are in production, we need to get MYAPP Mini Project live, this will be done in CC005.  The VSS structure is:

  • CCM creates /development/CC005
  • CCM branches code used in MYAPP Mini Project from /production/cc004 (current production source)
  • CCM then, working with the developers, merges into /development/MYAPP Mini Project with the /development/CC005 project files.

  • Merging is a right pain in VSS, take care and where possible, attempt offline from the product.

  • On completion of the merge, remove MYAPP Mini Project or renamed to 'CC005 - MYAPP Mini Project'
  • Go through standard development, test, production VSS practices as outlined through this document.
Total article views: 4758 | Views in the last 30 days: 1
Related Articles

Version Control - Part 2 - Tracking Changes

Part 2 of Steve Jones' series on version control. This article examines how you can track the change...


Migration to Production

SQL Server is an easy to use product in many ways, much better than the other major RDBMSs out there...


Version Control - Part 3 - Migrating Objects to Production

Part 3 of Steve Jones' series on version control. This article examines how migrate your changes to ...


Stairway to Database Source Control Level 3: Working With Others (Centralized Repository)

One of the main purposes of placing a database under source control, alongside the application code,...


Development and Production Database

Insert Into Development and Production Database at the same time