Migration from development to production - best way?

[gmorey]

I'm a DataStage newbie, and I've recently started at a company where there has been a 95% turnover within the last 6 months. The guys that were working with DataStage have left. I am now "the DataStage guy".

We're using DataStage 7.1. Many of the jobs and job sequences are UniData extractions which are loaded into SQL Server.

We have a development project and a production project. Sarbanes/Oxley (SOX) is looming.

What I'd like to know is -

What is the best way to do the migration from development to production?

Also, if I'm developing DataStage jobs and sequences, and SOX requires that someone else implement these
in production, what's involved, and how skilled in DataStage must one be to do that?

I'd welcome any thoughts on this..

Thanks!

[chulett]

The official answer is Version Control- a separate installable tool that comes on the DataStage Client cdrom and installs on your pc. Check to see if you have it installed and if not, do so.

Read the docs that come with it, particularly the Methodology chapter, which is Chapter 2 from memory. Come back and ask questions.

As for SOX and Production and all that rot, we have dedicated Production Support types that now have had to learn and love DataStage to a small extent. They have to do final promotion step via VC and (amongst other things) they also get to do any manual job reruns required... normal production support type stuff, but now they need a copy of the DataStage client and minimal training in how to use the Director and Version Control.

[chulett]

Greg, they aren't literally named like that are they? Project1, Project2, etc?

Typically, in my experience, you would name projects based on the subject area they serve and they would come in threes as mentioned in the VC docs. Four when you throw in Version Control:

SubjectAreaADev
SubjectAreaATest
SubjectAreaAProd (or perhaps just SubjectAreaA)
VERSIONA

We typically use a dash to separate the suffix from the main name. Some people use more than three main projects, differentiating between Test and QA, for instance.

Note implied above the fact that Version Control does support having multiple VC repository projects, so best practice in my book is to have a dedicated VC project for each subject area.

Hope that helps!

(King Crimson fan it would seem)

[gmorey]

Greg, they aren't literally named like that are they? Project1, Project2, etc?

Typically, in my experience, you would name projects based on the subject area they serve and they would come in threes as mentioned in the VC docs. Four when you throw in Version Control:

SubjectAreaADev
SubjectAreaATest
SubjectAreaAProd (or perhaps just SubjectAreaA)
VERSIONA

We typically use a dash to separate the suffix from the main name. Some people use more than three main projects, differentiating between Test and QA, for instance.

Note implied above the fact that Version Control does support having multiple VC repository projects, so best practice in my book is to have a dedicated VC project for each subject area.

Hope that helps!

(King Crimson fan it would seem)

Craig,

No, those are not our real project names.. it's more like

WidgetTrackingDev
WidgetTrackingProd
etc.

Didn't realize we could have a VERSION project for each project group! I'm curious if anyone else out there has an opposing view on this..
-------------------------------------------------------------------------------
Regarding King Crimson, I think Robert Fripp is a rather unusual individual, no? Their album Discipline is my fav.