Version Control for dsx

laiko · Post by **laiko** » Sat Oct 17, 2009 11:05 am

We are planning to use versioning tool for our project. We primarily use DataStage. The problems we are facing are:
- we are not aware of any migration tool that can handle DSX files. The files have to be manually deployed/compiled to Production environment.
- if a new release has 50 jobs, we have to one-by-one create the DSX files and check them in to our versioning tool.
Anybody who is using a versioning tool for their DataStage project, can you let me know how these things are handled and what tool you are using (for example, PVCS, CVS, Clear Case, or VSS)??
thank you.

chulett · Post by **chulett** » Sat Oct 17, 2009 1:57 pm

So, you're not aware of the tool named Version Control that ships with the product in your version?

ray.wurlod · Post by **ray.wurlod** » Sat Oct 17, 2009 3:49 pm

Version Control does not include a check-out/check-in capability.

Its replacement (IBM Information Server Manager) will do so in a near future release, according to the road map presentations at last year's IOD conference.

laiko · Post by **laiko** » Sun Oct 18, 2009 9:05 am

Hi Craig, we know about the version control. However, it does not serve the same purpose as the one which has check-in/check-out/merge/branch/lock features. I think DS version control is mainly to keep history.
Anyone using version control system, I just would like to know how they manage the creation of individual dsx files/deployment esp when it involves say 20 dsx files, etc.. thanks.

chulett · Post by **chulett** » Sun Oct 18, 2009 10:20 am

I don't see the point of any sort of external check-in/check-out capability nor the merge/branch functionality as IMHO they are bascially worthless in this GUI environment.

For the individual dsx files question, most people who do anything like that seem to have scripted the process - Kim Duke, for example, has mentioned creating that functionality so it is as automated as possible. There's also the concept of a 'dsx cutter' that's been posted here in perl, from what I recall, that will take a single export with multiple objects and 'cut' it into individual dsx files per object. So there's several options, it seems, again I just don't see the point unless you are mandated to use one just to keep the Powers That Be happy. For me, anything I've needed from a version tracking / promotion processing tool has been satisfied by VC.

dsxuserrio · Post by **dsxuserrio** » Sun Oct 18, 2009 10:34 am

Laiko

Until IBM comes up with a feature to integrate check in/check out with IDE,you may have to live with exporting DSX files and version them.

You can export several datastage jobs ( all jobs in an iteration) into a single dsx. That way release and deployment may be easier.

We use subversion.

Thanks

laiko · Post by **laiko** » Mon Oct 19, 2009 12:25 am

Hi dsxuserrio, we are also planning to use subversion. It feels great to know we're in the same boat. I would appreciate if you can let me know how you are doing things in subversion.
- Do you have individual dsx files for each job, sequence, routine?
- What are the objects you version (job, sequence, routine, anything else)?
- How do you deploy them? Manually? As in one authorized account has access to production who pulls the file from subversion repository and compile them in production?
- How did you initially checked-in all the files into the subversion? Did you have to create all (hundreds or thousands) of dsx files?

Excuse me for asking a lot.. but will greatly appreciate your guidance.

kduke · Post by **kduke** » Mon Oct 19, 2009 11:00 am

The batch file Craig is referring to works off a list. You give it a list of jobs and it will export a job, import to a different project on a different server and compile the job on the new server.

It does a couple more things like strip the dependent objects like shared containers. It also logs everything in a SQL Server database so you can report on it.

kduke · Post by **kduke** » Mon Oct 19, 2009 11:09 am

I forgot it also changes job to not READONLY so the compile works before it compiles it. Afterwards it makes it READONLY again.