Support Statement: Dealing with Source Code Changes

Owned by Mark Juras
Last updated: Mar 25, 2018 by George Juras
2 min read

Source code changes are a reality for any long-running upgrade effort.  In practice, there are three types of changes during a migration:

  • source changes,
  • rule changes, and
  • requirements changes 

 As a flexible, documented and repeatable process, the gmStudio Upgrade Solution is designed to manage change.  The procedures for managing source code change are as follows:

  1. We first like to verify that the source change is correct, "official code".  It is not a requirement, but it helps to set expectations.
  2. We compare the original source (oSource) to the new Source (nSource) just to see what types of changes are there so we have an idea what types of impacts to expect. Then we put the new source in place where it will be processed by gmStudio.
  3. We take a snapshot of the upgrade configuration (translation script, translation log, and translation result); call this oSnapShot.  Capturing a SnapShot file is a critical and reliable gmStudio feature.  The snapshot may also hold the build log and test log, if you write and implement a process.
  4. We run the upgrade process to produce new logs and results and we take a snapshot of that; call this nSnapShot.
  5. Use a file comparison tool to compare oSnapShot and nSnapShot.  gmStudio allows the user to select whatever file\directory comparison tool they want.  I use BeyondCompare by Scooter.
  6. Review the actual differences with the expected differences.   
  7. If necessary, correct or adjust the upgrade rules to resolve any undesirable changes.  
  8. If necessary, update the metrics databases and reports.  

 The actual impact of a source change depends on the nature of the changes and the nature of the rules in the solution.  Some rules are more general and others are very sensitive to code changes.  We aim for general rules to allow for a resilient process.

In my experience, adapting to code changes is a very minor effort; with nothing needed in Step 7.  So it is not a completely transparent task, but it is also not a big deal.   Typically, it takes an hour or two to do the steps carefully and make sure the nSource is running through just as well as the oSource.

One of our customers (Greycon) implemented the gmStudio upgrade as part of their nightly Continuous Integration (CI) process --  mainly because they had CI for .NET so they hooked gmStudio (it has a batch interface) into the nightly build for the full .NET system.  They did the upgrade to feed the latest checked in VB6 through gmStudio to a full .NET build and then to their testing environment.

Â