Source code changes are a reality for any long-running upgrade effort. In practice, there are three types of changes during a migration:
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:
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.
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.
nSnapShot. gmStudio allows the user to select whatever file\directory comparison tool they want. I use
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
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.