...
Regardless of the technology you use to deploy your DataStage solutions (MettleCI or a less capable custom-crafted script-based approach) your software deployment process will contains contain these common steps:
Get the code from source control
Compile it (DataStage is a compiled visual language)
Configure the software and deploy it to DataStage Project(s) in specific target environments
...
While there can be an efficiency saving in building binaries once, the most common reason for wanting to adopt this approach is the perceived reduction in deployment risk. A build process isn't just a deterministic `code in → binaries out’ function. The binaries produced don't just depend on the code going in, but also the libraries, compiler, O/S updates, and myriad other aspects that can differ between environments, and alter over time. Compiling your DataStage jobs on the destination environments as part of each deployment means you run the risk of differences creeping in to your Production deployment due to differences in your environmental configuration at compile time. Similarly, DataStage binaries compiled on on in one environment can be incompatible with other environments due to minor O/S and or DataStage version differences.
An additional complicating factor is that of statically linked Shared Containers. It is important when deploying DataStage jobs to a target environments in which they are to be compiled to also deploy any Shared Containers referenced by that DataStage job. If not managed extremely carefully, it is possible to produce a binary of a DataStage job which cannot be produced from Git source control, as the DataStage job and its referenced shared container are misaligned. This is extremely dangerous from a configuration management and testing perspective.
...