This section describes the rational for gmStudio's approach to deployment .
One of the unique features of gmStudio is that is allows you to separate code generation from code deployment. This best practice resulted from our work in helping teams perform migrations of very large systems. It works like this: rather than publishing the translated code as separate files and folders immediately as they are produced, gmStudio creates a consolidated text archive that contain all the files. This text archive, or bundle file as we call it, must be explicitly processed, or "deployed", to create the separate files and folders. By default, this feature works behind the scenes and it is extremely fast so you barely notice it. This approach provides additional control and visibility to the migration effort, and having all the generated code in a single file facilitates several useful operations:
Furthermore, migrating a large system produces a new codebase, and this can mean thousands of new source files and millions of new lines of code. It is critical that the migration team plan for this tsunami of new code and has tools to help them manage it efficiently. gmStudio's bundle file deployment feature is useful in this regard.
A contemporary codebase consists of a very large number of files, some of which are text files and some of which have binary formats. It is the mandate of this system that it be able to process an existing codebase and to then transform it into a new codebase with different files, different structure, and even with different internal file format. The term "Deployment" is used to refer to the various operations required to gather large numbers of files into an archive and then to redistribute the contents of the archive in a new location.
Though there are many binary compaction formats that could be used to gather files into a single archive, this system uses a simple text-based format that is compatible with all contemporary operating systems. The details of this format will be discussed later. The advantages of using a text-based format are two-fold:
Bundle files are the self-extracting text archives produced by the translation process.
Here is a sample bundle file
cat >\gmProj\DemoScanTool\deploy\ScanToolUI_iop_csh\ScanToolUI.csproj <<
'' ... Text OF \gmProj\DemoScanTool\deploy\ScanToolUI_iop_csh\ScanToolUI.csproj ...
cat >\gmProj\DemoScanTool\deploy\ScanToolUI_iop_csh\AssemblyInfo.cs <<
'' ... Text OF \gmProj\DemoScanTool\deploy\ScanToolUI_iop_csh\AssemblyInfo.cs ...
''... REMAINING FILES AND DEPLOYMENT COMMANDS ...
Notice that the bundle file contains commands and content. The commands are directory management commands such as rmdir and mkdir. The content is in the venerable unix "here-file" format
'PATH OF FILE TO CREATE <<'!)(!'
'' ... Text OF FILE TO CREATE ...
The translator always writes your translation to a bundle file that you specify in the Translation Script and a separate step, running the deployment tool -- is used to run the bundle file. By default, gmStudio handles all of this behind the scenes.
You can view the deployment logs for a given migration unit by selecting the [Deploy Log] option on the [Task Details] tab. Checking the [Grid] option here will display the internal contents of the bundle file.
You can generate a report of the internal contents of the bundle files for selected migration units in your project by clicking [Reports/Code Bundles].
Deployment is a specific step in the migration process that can be turned on of off from the [Batch Control] Form. By default deployment is always on and runs after the Translation step and before the Build step.
Behind the scenes by gmStudio performs deployments by running an external deployment tool, deploy.exe. The command string for deployment is defined in the application config file by the following settings:
ShellToolExe = "%SystemFolder%\deploy.exe" ' the 'deploy' sub-command passed to the Shelltool will run shell commands such as rmdir/mkdir/execute otherwise only the cat commands run. DeployCmd = "cmd.exe /C pushd '%LogFolder%' && '%ShellToolExe%' '%BndPath%' verbose replace > '%LogPath%' 2>&1 %UserCmd% && popd" %LogFolder% is the workspace\log folder where gmStudio does almost all of its batch operations %ShellToolExe% is the path to deploy.exe %BndPath% is the path to the code bundle to be processed verbose is a command line flag that tells deploy.exe to report progress replace is a command line flag that tells deploy.exe to replace files with the ones in the bundle. %Logpath% is a file that will capture the deployment log %UserCmd% is a place-holder for a user batch command script
Deploy == Replace
By default, the deployment step will replace files in the deploy folder. If you have made hand changes to the code in that folder and have not captured those changes in the tool configuration or saved a backup in another folder, they will be overwritten by the next deployment.
The deploy tool is actually a command processor that can remove and create folders, and execute external programs. For example, the deploy.exe utility is used to deploy and build to binary (by running MSBuild) all the prototype assemblies generated in a prototype translation.
Deployment is a standard operation in the batch upgrade process, however if you want to deploy your migration files on demand, perform the following steps:
Translating a VB6 migration unit produces a set of files that correspond to the ones referenced by the source VBP:
By default, all files generated for a given migration unit are placed in a single folder called the unit deployment folder. The unit deployment folders for VB6 translations use the following naming conventions:
[WorkspaceRoot]\[MigName]\deploy\[TaskName]_[TaskTag]_[Lang] where: [WorkspaceRoot] is the workspace root folder [MigName] is the migration project name [TaskName] is the original VBP file [TaskTag] is the task tag assigned to the task when it was added [Lang] is 'csh' or 'vbn' if the target language is C# or VB.Net respectively.
The ScanTool sample has the following settings
In the project file header: ProjFolder = "C:\GMS\samples\workspace\DemoScanTool" DeployFolder = "%ProjFolder%\deploy" On the task records: TaskTag = "mgd" Lang = "csh" SrcName = "ScanToolUI" or "ScanToolLib"
Thus, the full path to the csproj files produced for each migration unit is:
gmStudio communicates the deployment folder to the translation process using a select DeployLocation command in the Translation Script.
The contents of the file look like this:
deploy V9.77 (BETA.007) System Build(6/18/09 8:40:51) Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\ScanToolLib.csproj Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\AssemblyInfo.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\modScanToolLib.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPRefReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsDirList.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPBinReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsCOMReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPModReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPCntReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsVBPSrcReporter.cs Unbundling: C:\GMS\samples\workspace\DemoScanTool\deploy\ScanToolLib_iop2_csh\clsScanControl.cs
Translating a web site has a different deployment model because folder structures tend to be much more elaborate and important to the conceptual design, security, and operation of the site. In addition #include paths may be virtual or physical and the concept of a virtual root directory comes into play.
The discussion here refers to a web site migration script that contains commands to compile all the pages in the site, but it would also apply to a script for a single page.
Translating a web site produces a set of files that correspond to the ones referenced by page slices named that script as follows:
By default, all files generated for the site are placed in a folder hierarchy that corresponds to the source folder hierarchy, but under the deployment folder. The deployment folder for a web translation is similar to the one used for a VB6 translation. The default folder for a migrated web site uses the following naming conventions:
[WorkspaceRoot]\[MigName]\deploy\ where: [WorkspaceRoot] is the workspace root folder [MigName] is the migration project name
Not getting anything except empty project files from your web site translation? gmStudio probably failed the deployment step because of missing sub-directories in the \[workspace]\deploy folder. Look at the deploy log and you will probably see error messages to that effect. This is a common mistake with ASP migrations because by default setting up the ASPX site directory is a manual preparation step. What we normally do is create a full empty folder tree in the deployment root using a tool like robocopy. Of course web sites depend on many types of "pulp" files (images, css, etc.) that will also be needed to run and test the new site so you may want to copy those as well. Again robocopy is good for setting up the "test site" directory from your current site directory.
For ASP upgrades, you will typically associate a user batch script with the migration tasks and modify that script with the following commands:
These pre-deployment commands create empty folders to receive the generated site and also delete all files from prior translations.
The DemoFMSWeb_csh.gmproj sample has the following settings:
In the project file header: <ProjFolder> C:\GMS\samples\workspace\FMStocks_csh</ProjFolder> <DeployFolder>%ProjFolder%\deploy\web</DeployFolder>
Note that the subdirectory "web" was added to the default deployment path. This was done do put the FMStocks site in its own folder next to the "lib" folder that is used for all the FMStocks class assemblies.
The full path to the web application project file produced for the site is
gmStudio communicates the deployment folder to the translation process using a select DeployLocationcommand in the Translation Script. For example, the tran.DemoFMSweb_csh.xml script template contains the following statements:
<Select DeployLocation="%NetProjFolder%" />
gmStudio uses information in the Configuration Files to set the parameter %NetProjFolder% when you run the translation.
<Select DeployLocation ="C:\GMS\samples\workspace\deploy\web" />
This folder ultimately ends up in the bundle file and directs the physical deployment of files to disk.
The VBP deployment conventions are controlled by several settings in the gmStudio.cfg file:
WorkSpaceRootFolder = "user-defined directory" DefaultDeployFolder = "%ProjFolder%\deploy" VbpDeployPat = "%DeployFolder%\%SrcName%_%TaskTag%_%Dialect%"
You can modify the settings in the gmStudio.cfg file to change the application defaults.
The migration project file provides two variables that can override deployment folder defaults if desired
ProjFolder = User-defined directory; default = [WorkspaceRoot]\[MigName] DeployFolder = User-defined pattern; default = %ProjFolder%\deploy
You can modify these settings in the gmproj files to change the project defaults.
For example, set
DeployFolder = %SrcFolder%\..
To put the migration unit folder next to the original source project folder.
The Translation Script has the final say on where deployments will be placed. The default command means use the value computed by gmStudio from the config.
<Select DeployLocation="%NetProjFolder%" />
You can modify this setting to change the deploy location for the units that use the script. For example
<Select DeployLocation="C:\project1_net" />