Dependency and Impact Resolution with zAppBuild

[dennis-behm]

From a recent query via email:

Dennis, Dan,

If I have a Git repo that has multiple application folders each which has a COBOL folder and a COPYBOOK folder, can you address the questions below for an impact build?

Git Repo contains application folders A, B, C, D, etc.

1. If a change is made to a COPYBOOK in application A, will the DBB dependency scanning identify COBOL modules in applications B, C, D, etc. to be rebuilt or are COBOL programs that are only in application A that ones that will be in the BuildList?

2. If a COBOL program in application A is changed, the copybook search path can be configured to look at the application A COPYBOOK folder (done by default) as well as the COPYBOOK folders of applications B, C, D, etc., correct?

[dennis-behm]

Hi -

TL;DR - Yes, that can be configured in zAppBuild.

Let me start by answering the second question first. zAppBuild leverages the DBB search path syntax to configure both the dependency resolution as well as the impact resolution.

Today, the sample contains the reference to the ${application} that is part of the search path:

dbb-zappbuild/samples/application-conf/application.properties

Lines 119 to 141 in a719842

	#
	# copybookSearch
	# searchPath to locate Cobol copybooks
	# used in dependency resolution and impact analysis
	#
	# Please be as specific as possible when configuring the searchPath.
	# Alternate configurations:
	#
	# dependency resolution from multiple repositories / multiple root folders:
	# copybookSearch = search:${workspace}/?path=**/copybook/*.cpy
	#
	# dependency resolution across all directories in build workspace, but filtering on the file extension cpy:
	# copybookSearch = search:${workspace}/?path=**/*.cpy
	# dependency resolution across all directories in build workspace, but filtering on the file extension cpy and cobcpy:
	# copybookSearch = search:${workspace}/?path=**/*.cpy;**/*.cobcpy
	#
	# dependency resolution in the application directory and a shared common copybook location:
	# copybookSearch = search:${workspace}/?path=${application}/copybook/*.cpy;/u/build/common/copybooks/*.cpy
	#
	# More samples can be found along with the syntax for the search path configurations at:
	# https://www.ibm.com/docs/en/dbb/2.0.0?topic=apis-dependency-impact-resolution#6-resolving-logical-build-dependencies-to-local-physical-files
	#
	copybookSearch = search:${workspace}/?path=${application}/copybook/*.cpy

To address the outlined scenario, you can define a more generic search path rule, that will include all subdirectories within the build workspace:

copybookSearch = search:${workspace}/?path=**/copybook/*.cpy

or list all the application directories to specifically call out where to look into, something like:

copybookSearch = search:${workspace}/?path=${application}/copybook/*.cpy;ApplicationB/copybook/*.cpy;ApplicationC/copybook/*.cpy; 

This will enable zAppbuild and DBB to resolve copybooks in other subfolders.

To answer your first question, today zAppBuild is using the searchPath configuration copybookSearch also as the configuration to perform impact analysis. So, a changed copybook will rebuild all the consuming programs in all applications.

However, you can override the impactSearch configuration using a file property and specify a rule for each application.

For the latter case, my main question, which I am concerned about it, is about managing the build result history for impact builds, and thinking if you are implying to consider pipeline configurations for each application directory. Imho, this is shifting the grouping of application scopes into the build configuration rather than cleanly organise the code in multiple repositories (which then allows their dedicated workflows as well).

This sounds like an interesting use case for the dbb-git-migration-modeler that was published a few weeks ago.