Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 

Since the a gmStudio upgrade solution is a flexible, documented and repeatable process it is designed to manage change.  The procedures for a source change are as follows:

  1. We first like to verify that the source change is know to be 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 a implement a process.
  4. We run 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 adapt to resolve any undesirable changes.  
  8. If necessary update 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.   Typicalluy 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 teh latest checked in VB6 through gmStudio to a full .NET build and then to their testing environment.    I think Amerisource Bergen did something similar.


  • No labels