Development on our system takes pace at a rapid pace, it’s not uncommon for me to release new/fixed code many times a day. Generally these are small enhancements, incremental development or even “preview” code that I want only specific users to run. So it is not uncommon to have three different versions of the code “out there” at any one point.
I’ve divided up our releases into Production, Beta, Alpha and Testing. The first three types correspond to the blessing levels I use and the final is an area I use mostly for myself to test and debug runtime issues. My deployment procedure is pretty simple, create the .pcl files, copy them to the appropriate directories (corresponding to the release types) and have the user restart.
The end user actually executes a .cmd file. This file copies all of the application down to the local hard drive (in a directory corresponding to the release type). This includes visual.exe, all .pcls from Visualworks that are used, all of my .pcls and any configuration files. It then uses the start command to launch visual in a new process so that the .cmd file can exit and the command window disappears.
The .cmd file starts by changing to the local hard drive and verifying that the target directory exists using the following command
IF not Exist C:\Production731\prn md C:\Production731
So it will create the folder on the fly if the local drive does not already have a folder named it.
The copy command (I use XCopy) uses the /D and the /Y options, /D ensures that only newer files are copied down (making the startup process much faster) and the /Y eliminates any “overwrite this file” messages that the command processor might throw.
Here is an example of the start command which will start my application in another process, thus allowing the command window to close.
START Visual.EXE Runtime.im -cnf myApp.cnf -notifier MyNotifier -doit 'MyApp open'
By copying everything locally and then running the application, I do not have issues with copying the .pcl files out onto our network during a busy time. The actual files on the network are not “in use” by anyone directly.
You can see that my release directories also include the version of VW that we are running. This lets me then migrate users to the next version in a much more controlled fashion. The shortcut that the user has to start the application actually points to a general .cmd file for Production/Beta/Alpha on our network. In that .cmd file, I call another .cmd file for the specific version of VW that I am running. That way, when I am ready to move Beta users over to VW7.4.1, all I do it edit the Beta.cmd file on our network to point to the Beta741.cmd file. The end users shortcut on the desktop is not changed, so there are no changes on the workstation that we need to make. This also adds in the ability to revert back to 7.3.1 should I find anything that is unacceptable. Since I use release directories with the VW version number as part of the name, there are no issues with running a mix of the wrong code.
Down the road, if I want to clean up the local users hard drive, I can always insert a command in the .cmd file to delete a previous release directory should it exist.
In practice I’ve found that these techniques make deployment much easier to manage. I can easily place Alpha users on a different version of VW, or have Beta users running different code than production. I may release code in the middle of the day and ask a specific user who requested a change to restart. This gives them the new code but does not disrupt any of the other users.
Here is a listing of one of my .cmd files
@Echo off Echo Starting Target Trading II - 2005 Beta Version ...
Echo Updating Source Code Echo Please wait....
REM Code to update the local workstation with new code
IF not Exist C:\TradingBeta731\prn md C:\TradingBeta731 C: CD \TradingBeta731
REM DEL . /Q
XCOPY I:\Forest\Apps\VisualWorks7.3.1\*.* C:\TradingBeta731 /D /Y
XCOPY I:\Forest\Apps\TargetTrading\Beta7.3.1\*.* C:\TradingBeta731/D /Y
XCOPY I:\Forest\Apps\TargetTrading\bmp\TargetIIBeta.bmp C:\TradingBeta731\Herald.bmp /D /Y
Echo Code update complete.
START Visual.EXE Runtime.im -cnf trading.cnf -notifier TargSysNotifier -doit 'TargetFrameApp open'