In a previous life I was responsible for promoting new and modified SAS DIS jobs from Development through to our production environment.
The usual process would consist of manually exporting the appropriate objects, selecting the dependant object option then importing the objects into Test trying to remember what objects needed to be imported where, the import was then repeated into PROD. Needless to say mistakes were made, documentation of the releases were minimal – not ideal.
And at the bottom of the release logs there is always a note the goes something like
INFO – You can submit the following command to the batch export tool if you want to export this package again.
ExportPackage -profile “TEST” -package “C:UsersbobDocumentsAnotherReleaseSigh.spk” -objects “/Users/bob/My Folder/AWSomes(Job)” -subprop
I would always say to myself why would you need to do this? (Well not really but works with my story)
Then along came a very big project that was going to require multiple releases. You can imagine I was not looking forward to the countless hours of point and clicking. There had to be a better and easier way, of course otherwise why would I be blogging about it J.
As with all good projects it had a good level of documentation, one of interest here was the release document, a simple but comprehensive excel spread sheet that out lined the process involved to get from A to B. This spread sheet contained a list of all the objects to be deployed, their type and a few other things. If only I could automate this…
A quick search and I had found SAS’ documentation for ‘ExportPackage’ and ‘ImportPackage’ :
http://support.sas.com/documentation/cdl/en/bisag/64088/HTML/default/viewer.htm#a003261084.htm,
At this point I turned to my SAS coding skills to create a couple of batch files that contained the exportPackage and importPackage commands with the appropriate syntax.
Basically the process consisted of importing the excel sheet, manipulating the data into a form that made it easy to construct the commands, creating the batch files (with noexecute first) using good old data step and put statements, and then running the files. A couple of macros later and I had a piece of code that I could point to a release file, click run, wait a few seconds and have some batch files that I could run to do the release.
Here a few parameters I found useful, plus a couple of tips. But as always have a good read of the documentation and play, play, play.

– ProfileSpecify a SAS Connection Profile on the client, save you from having to define the server, port and userid etc.– subpropSpecify a file that allows you to change the values of properties associated to an object, such as paths of a library.– noexecuteAllows you to validate before executing the Export/Import– objectsAllows you to list all the objects you want to export.-preservePathsSpecifies that objects and folders are to be placed in the same path where they were located in the source environmentTipsI found it best to create the Import and Export Files at the same time, that way if the release file changed the files were always in sync.Plus I created multiple import files, one for each environment, that meant there was no modifications of the files at the time of importing.Record the object type in the release document rather than trying to work it out in code, the developer knows the type. The objects parameter requires it if you specify specific objects.

So another good tool from SAS to help the release process – Have a look at these even if you only do a few releases – It ensures the process is documented with all the objects to promote listed, Export/import logs recorded, is repeatable and consistent, and frees up time for you to do something else.

Barry, Preventer of Chaos.