HowTo - Manage many builds or many deployement targets on same source file (and report it in buildReport / metadata store / Web Application)

[FALLAI-Denis]

Hi,

In our context of use, for the same source file, we must supply several execution targets (different z/OS partitions or different execution environments). Execution targets are declared in a properties file associated with the source file.

Today we trigger as many builds as targets, (potentially the build characteristics may be dependent on the execution target, although at this time this is not the case). As a result, we feed as many PDS as execution targets. This allows us to have PDS of components by execution targets, which allows us to produce a package of the application with all the components by execution targets, and to indicate it in a manifest file which is used for the deployment, (the deployment is done by execution target). In the BuildReport.json file, each construction step is recorded individually in an EXECUTE type record, with its associated outputs, (each build feed a PDS associated with a target). In the Web Application rendering, all the steps are attached to the same source element: OK, but we don't know which target is attached to which step. I don't know how these informations are saved in the metadata store.

We could also build only once for all the targets concerned (which would prohibit having constructions dependent on the target), but we must then find a way to indicate the targets concerned in the BuildReport to then exploit it in the packaging and the production of a manifest file describing the targets associated with each component built.

--> how could execution targets appear for each component built in the Web Application?

A priori it does not seem possible to add attributes in the EXECUTE records of the BuildReport, and in any case they would not be recognized by the Web Application, and perhaps the metadata strore.

Should user records be created in the BuildReport to indicate execution targets for each component? How would it be rendered in the Web Application?

[FALLAI-Denis]

PS : use case of 2 programs built twice (1 source / 2 targets : SIRIS and HUB)

[dennis-behm]

@FALLAI-Denis ,

I struggle to find a good sample, of what I understand by your above description. But let me give it a try:

Let's say you are developing a banking system, which is split into domestic banking and international banking branches. Some of your modules need to deployed into the runtime environments for domestic only, international only or in both domestic and international.

The question is where and how to I maintain/manage the mapping of a file to one of those above categories (targets):

• The developer is interested to understand the different targets
• Because it is the same module, the build admin might say: We only built the outputs once.

Generally, I believe the build framework should not contain environment specific data (like x number of test environments or even their names) - That is the topic for the packaging and deployment activities. There is an exception, when this mapping is more a logical grouping of source and outputs to different application runtimes, where a module might be reused in multiple contexts (like the above sample with the banking system).

What strategies exist:

• Invoke the build for each "target" and store the outputs in their dedicated dataset libraries. This leads to longer build times and you are binding information into the build framework implementation.
• Another approach is to document the mapping as a metadata member and define that as an output of the build to pass the information as input to the packaging step. Similar to that is to store the information in a AnyTypeRecord or PropertiesRecord which is then documented in the BuildReport.json, rather than the output member.
• Use the deployType attribute to indicate the mapping.
• Completely manage it in the packaging step and maintain a table outside of the application repo. Less transparency to the developer. Not preferable.

I would be on favour of the second approach, which I know other customers have implemented as well.

Please note - in DBB 1.1.x, the DBB HTMLTransformer allowed you to customise the BuildReport.html . However due to security concerns, this API was removed in DBB 2.0 - see Upgrade to DBB 2.0.

I don't know how close I am with my comment on your problem; there is also the very technical topic where a program is executed in multiple runtime environments (in BATCH and CICS) which require slightly different link options and a multi-link approach. I just have added an new recipe to the wiki .

[FALLAI-Denis]

Hi @dennis-behm

Once again thank you for your advice.

We are in the case of a management of Application components which are distributed over several logical sets, most often over a single logical set, and exceptionally over several logical sets. These logical sets are then instantiated on physical servers, one or more.

The association between source and logical set is the responsibility of the development team (taking into account technical operating constraints). It seems normal to us that this information is associated with the "source", and with the "components" produced by the construction of this "source".

I will study the solution of the management of the mapping on the basis of AnyTypeRecords which will then be associated with the "source" to know which logical sets are concerned by the "components" associated with a "source". I think reserved the deployType to the nature of the "component" produced by the construction, and not to make it bear the notion of logical set.

The notion of logical set does not concern construction, but deployment. In this case, only one construct per "source" will be needed, producing and packaging a single instance of "components" for that source.

The problem of multiple runtimes (Batch and CICS) also exists for us, but this is not the subject of this issue. In the case of the mixed COBOL source (Batch and CICS) we do a COBOL compilation, and two linkedit to produce a loadmodule for each loadlib (Batch and CICS) because the Db2 runtimes are not the same in batch and in CICS, and the Db2 runtime must be statically linkededited for CICS. And in this case we do use different deployTypes for each loadmodule.