Compile jobs on dev; Deploy to prod machines.

[MMarietta]

In the documentation that i've read, it appears possible to compile jobs on one machine w/ a C++ compiler and deploy to other machines with the C++ runtime and no compiler.

Also, some folks I work with were lucky enough to go to the training class. though it did not cover a development/deployment section. They posed the question to the instructor who maintained this was the truth.

The problem I'm having is that no one seems to know where to begin when setting up this process to build/deploy.

Any help or direction on where to get started would be much appreciated.

Thanks

[trokosz]

First, if you compile in DEV then you would export the Job Design and its associated Executable and import into TEST or PROD. You need both and you do not need to compile in TEST or PROD.

Second, if ther eis an issue in TEST and PROD then you need to go back to DEV, change, compile and redeploy.

Third, you need a change management process to facilite which could be manual export/import with spreadsheets to DS Change Control (but not offered in IS 8 as of yet), or use a enterprise solution (e.g., ClearCase, CVS, PVCS and so on).

[MMarietta]

1) This is the part I need the most help on.
Would I need to go through each job in Designer to compile/export?
Is there a Unix command to compile/export these jobs?
Where are the job designs/executables stored so I can pick them up?
If parameters change from DEV to TEST/PROD, how are you getting around this?

Thanks for your help.

[trokosz]

Just to repeat what I said "Job Design and its associated Executable and import into TEST or PROD. You need both and you do not need to compile in TEST or PROD. ". This means bringing the executable over means no recompile is required. In DataStage Export GUI you will see Job Designs, Executables and so on (its obvious). You select there.

Objects and code are within the Universe repository for pre-IS 8 and in a DB2 or Oracle repository for IS 8 and greater. There is no need to go into these repositories. Just follow the above.

[MMarietta]

In DataStage Export GUI you will see Job Designs, Executables and so on (its obvious). You select there.

Ok, I'm clicking through the GUI and can export an individual job or a set of jobs under a folder. My question from my previous post is really coming from the perspective that I would like an automated UNIX process to export these files. So, I can export them, package them, and deploy them without a GUI. And, without using my windows machine as a stepping stone for deployment.

And, I'm also still wondering about how parameters are handled. For example, my Oracle stages have a SID for a development instance defined in a parameter. Are you changing all your parameters for test/prod, compiling, exporting, deploying? Then, going back and changing them back for development?

[kcbland]

You should have devised an ETL framework that supports transportable code across environments. The two most obvious methods are environmental variables utilized by the jobs at runtime or intelligent job control that derives parameter values for jobs at runtime from tables, environment, and or configuration files. Both methods have their pros and cons, but the idea is that we never right any code with explicit paths and credentials as that is contrary to transportability, either across environments or with multiple versions of the code within the same environment.

[MMarietta]

You should have devised an ETL framework that supports transportable code across environments. The two most obvious methods are environmental variables utilized by the jobs at runtime or intelligent job control that derives parameter values for jobs at runtime from tables, environment, and or configuration files. Both methods have their pros and cons, but the idea is that we never right any code with explicit paths and credentials as that is contrary to transportability, either across environments or with multiple versions of the code within the same environment.

Fair enough. I didn't play a role in the design and development of the application. But, have been asked to support and design a build/deploy solution for it.

If that means modifying the jobs to use environmental variables or intelligent job control.... That can all be part of my suggested implementation.

Thanks for the good info.

[ray.wurlod]

It probably also needs to be mentioned that the runtimes must be 100% compatible with the compilation environment.

[MMarietta]

It probably also needs to be mentioned that the runtimes must be 100% compatible with the compilation environment. ...

Just to clarify, you're saying the C++ runtime environment in production must match the C++ compiler/runtime environment in development?