HI ,
I would like to know, Promotion process of Datastage jobs developed in DEVELOPMENT envrionment , how to promote to SIT and UAT and Production Envrionments? if it manuall promotion process i know we can do it by using IMPORT AND EXPORT methods, but
is any best method of auto promotion process and code (datastage job) change control process avaliable in Datastage ?
if any one have BEST PRACTICES ON DATASTAGE JOBS PROMOTION process . pls help to share with me .
Thanks in advance.
Cheers,
Krish
Datastage Jobs Promotion Process to SIT,UAT and Production
Moderators: chulett, rschirm, roy
Hi,
Hope you are aware of Version control.
This helps you to keep track of all the versions and defects and changes in Development environment.
Before promoting the jobs to testing and produciton, VERSION project acts as centralized hub among them.
But when we initialize a project to version i could see jobs named with new version as job.name^1_1.... hence it makes the usage odd. i.e, when we try to export a catogory, the new version also add it to the dsx...
Need to find some better way of version maintaning.
regards
kumar
Hope you are aware of Version control.
This helps you to keep track of all the versions and defects and changes in Development environment.
Before promoting the jobs to testing and produciton, VERSION project acts as centralized hub among them.
But when we initialize a project to version i could see jobs named with new version as job.name^1_1.... hence it makes the usage odd. i.e, when we try to export a catogory, the new version also add it to the dsx...
Need to find some better way of version maintaning.
regards
kumar
Version Control has simply appends a version number to the job as it is "Initialized" or brought into the VC repository when it's time to promote a change. So, first the 1.1 version is created (^1_1) then the 1.2 (^1_2) and so on. Promotion involves selecting the appropriate version, typically the most recent, to promote to your other environments. During that process, the version information is removed from the job name and the job is (optionally) recompiled and marked as read only in the new project.kumar_s wrote:But when we initialize a project to version i could see jobs named with new version as job.name^1_1.... hence it makes the usage odd. i.e, when we try to export a catogory, the new version also add it to the dsx...
Not really sure what's with the rolly eyes bit, or why you would find this "odd"... or why you'd be surprised to find multiple versions of a job in an export from a Version Control repository.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Hi,chulett wrote:Version Control has simply appends a version number to the job as it is "Initialized" or brought into the VC repository when it's time to promote a change. So, first the 1.1 version is created (^1_1) then the 1.2 (^1_2) and so on. Promotion involves selecting the appropriate version, typically the most recent, to promote to your other environments. During that process, the version information is removed from the job name and the job is (optionally) recompiled and marked as read only in the new project.kumar_s wrote:But when we initialize a project to version i could see jobs named with new version as job.name^1_1.... hence it makes the usage odd. i.e, when we try to export a catogory, the new version also add it to the dsx...
Not really sure what's with the rolly eyes bit, or why you would find this "odd"... or why you'd be surprised to find multiple versions of a job in an export from a Version Control repository.
Is it possible to get latest among version (even if versions vary acorss jobs)
i.e., if a job is versioned a 1.2 and other one as 1.3 and if both were the latest.
regards
kumar