DSXchange

Hi all

I have seen a lot of cases where we are asked to export DataStage jobs along with their executables from development to test/UAT/production. Apparently this is a best practice. I don't believe this should be the case (and NO our environments do not lack C/C++ compilers) because personally I prefer compiling my jobs in the target environment each time. Apart from a complete validation of all the assets that I have imported, my import (and thus export dsx) also tends to be a faster process due to only job designs without executables being included.

Lately because of this habit I came across a host of jobs in our production environment that do not compile due to missing mandatory parameter values in sequence jobs. Of course, because the executable has been migrated the sequences do not fail.

My question is, is this really a best practice? I do not think it should be and sincerely hope it is not.

Thanks in advance for your insights

Tony

Best is like saying Chocolate is way better than Vanilla. It's a matter of taste. But... Standard Practice... Yes. I would say migrating objects with executables is Standard Practice.

This allows for a full Unix side automated migration without any manual intervention or super fancy call to a windows client compile command. This would facilitate a CICD deployment. Do not underestimate that buzzword, managers and higher ups find that it is all the rage.

When you migrate an object that has the executable in it, you most likely pulled it from an external source control repo (github). If you are not doing that, then it's a silly process that should be rewritten because disasters happen and you need to be able to rebuild or back out code to a prior version level.

The Object coming from the repo will most likely be placed into a higher tier environment (sit/stage/uat/prod) where regular folks do not have developer authority due to security compliance reasons. Typically only an admin or a batch ID / code migration ID has authority to load code and/or compile. OPS folks should never have compile authority in anything other than DEV.

If you are working in a large shop, you are bound to get an audit done. They will ask who has access to compile, edit, migrate code into prod and what security measures are in place to control that. If any John Doe can edit and compile, you've pretty much allowed them keys to the kingdom and any type of code migration rules are thrown out the window.

From an admin point of view, I only allow Admins and Batch IDs, where the application teams do not have the password, to be able to load code into sit/stage/uat/prod. If I ever allowed an application team full access, they would "just make a quick fix" in prod and never reapply that back to baseline dev. Then the next time the edit in dev, they do not have that fix, and it breaks prod again.

There will be a war room situation where an admin has to do an emergency fix and compile with application team guidance, but that fix would then be loaded back to dev because it would be tracked.

Nope... I've been an admin in some of the biggest shops around... never going to allow users compile access in prod. I'd rather abdicate ownership of that datastage setup rather than do that.

What Paul said.