Page 1 of 1

Automation of Development Datastage Code to production

Posted: Mon Dec 13, 2010 11:08 am
by greenjo
To All Datastage Experts,
I have been tagged with the all mightly task of automating the deployment of Datstage Code from development to production. Currently i development my own code on a development server, export the code when ready, then import code to production server and compile jobs. I know 8.5 will have some type of code control, but i have to come up with a code control method using version 8.

Here is what i have so far:
1. Continue to export Dsx from develolment when ready for production release, but code is moved to a freeware called subversion. From this area an operations team can access the code, but that is as far as i have gotten.
2. without allowing access to the gui what is the best command to issue in import code into production?
3. is there a command that can be entered to compile a list of jobs or is it better to just export and import jobs "with executables", or do the jobs still need to be compiled with this option?


Any advise will be appreciated...

Posted: Mon Dec 13, 2010 1:28 pm
by FranklinE
Our approach here is to import executibles only using a script (we are in Unix) that runs:

Code: Select all

dsjob -import -OVERWRITE
I've left out many environmental things because they are specific to our shop. We use Control-M and a "utility" id that owns the job and the command when it runs. Only the production operators can submit the job. All is quiet in Security Land. :wink:

Posted: Mon Dec 13, 2010 2:37 pm
by ray.wurlod
You can create deployment packages using Information Server Manager which has the istool command line interface. When you get version 8.5 you will be able to check in and check out these packages through an Eclipse plug-in for Subversion or via your own code using the provided API.

Posted: Mon Dec 13, 2010 3:08 pm
by kduke
I took DataStageBackup.bat and modified it to:

Assume migration from DEV to TEST
1. Read a list of jobs.
2. Export each job from DEV to JobName.dsx.
3. Import each dsx to TEST.
4. Compile each job in TEST.
5. Update audit table using SQL. (user,job name, to project, from project,time and date)

I have rewritten the same logic using VBscript. Each script requires command line arguments to tell it to and from server connection information.

Posted: Mon Dec 13, 2010 3:11 pm
by kduke
You need a set of admin scripts to do these routine tasks. I give away a lot of these scripts on my tips page. I have not added these new versions yet.

Posted: Fri Dec 17, 2010 4:53 pm
by PaulVL
I think it's important to ask if you are currently running 8.0.1 or 8.1.

With 8.1 you can import DSX files on the server side via command line.
With 8.0.1 you are still stuck with Client side dsx file importing.