Centrally Managing Scripts with Endevor Team Build
Team Build Isn’t Just for Developers
For customers considering orchestrating and governing their mainframe development natively with their Enterprise DevOps tools stack, Broadcom’s Team Build is a key enabler. It allows mainframe builds to be done regardless of where the source code is housed by decoupling the build engine from the traditional all-in-one Endevor ecosystem. Very often in off-host development, build scripts are maintained by the team and versioned with the code in their Git repository. The continuous integration process simply fetches the script along with the code and uses it with the build engine to produce the binaries. With Team Build, things are no different and it certainly supports this way of working. For some though, this presents a challenge: mainframe expertise for builds has long been centralized; many developers are not fully versed in what can be very complex build logic and have relied on tools like Endevor to provide this for them. The good news is that with Team Build, build scripts can still be centralized if so desired.
Dedicated Script Repositories
With traditional Endevor, processors are managed by Endevor itself. When you invoke a Generate on an element, the assigned processor group determines the build script that gets used and the actual file / processor that provides the logic is pulled from a controlled location in Endevor. Typically, only certain users have access to update the logic but it is usable by all developers. In a native Git implementation, you can opt to manage things the exact same way: by creating a dedicated repository for the build scripts.
The logic stored in Endevor, once initialized as Team Build scripts can be checked into a central build scripts repository instead of the application source repository. Maintaining scripts in a version control system instead of an external location like a database or controlled PDS makes a ton of sense and is why processors are managed by Endevor itself. For one, you can apply the same discipline for updating the scripts that you would any other application source. You can control access to update, you can branch and have different versions available and you can use things like pull requests to review and approve changes. If your Endevor Admin (who typically managed build logic for their teams) prefers working in Endevor, you can even maintain the Team Build scripts in traditional Endevor and publish them to a central repo with Bridge for Git.
Working with Central Script Repositories
When scripts are centralized, developers are going to need to ensure they can access them whenever builds are needed. This can be done by one of two methods. The first way is to simply fetch the central repository separately and refer to it from your scripts. In this scenario, your project directory might look something like this:
The two repositories are cloned under a top level folder and by referencing the scripts folder in your build scripts it’s just a matter of ensuring you have both on your machine.
There’s an easier way to do this though by using something called a Git submodule. Using submodules, you can embed a reference to the other repository in your application repository so that whenever someone makes a clone of it, the repository containing the scripts is also cloned.
Notice in the above screenshot that the scripts is located under the application repository and there is a file in the folder .gitmodules that specifies the link to the scripts repository. VS Code also highlights the folder in blue to show it is a submodule providing the files.
Creating a submodule reference is simple with the following command:
git submodule add <remote_url> <destination_folder>Once you’ve created the link, you commit and push the change like any other. When cloning the project though, make sure you include the --recurse-submodules flag to get the files from the submodule repository:
git clone --recurse-submodules <remote_url>Submodule Versioning
Submodules link to a specific version of a repository. This may be a good or a bad thing depending on your use case. You may wish to control which version of a set of scripts is being used to keep things stable, especially while changes are still being worked on. However, if you prefer to always use the latest version of a repository, create a wrapper build script that issues the git submodule update — remote command before calling Team Build’s bldz command to refresh to the latest version of the scripts in the centralized script repository. Alternatively, you can embed the command into the Team Build script itself so it happens with every run of bldz. Note though that if you want to update the reference in the application repository to the latest version of the scripts repository for future runs, the git submodule update command will not be enough. After you run the update, you need to commit and push the updated reference in the application repository just like you would any other source code artifact.
Summary
Submodules provide a convenient way to include other parts of your application that might be managed by other teams into your own application’s repository. Today we talked about build scripts but it could just as easily be a repository of centrally managed copybooks. The copybooks could even come from a team that maintains them from a traditional 3270 Endevor interface via a Bridge for Git managed copy. Either way, applying source code management techniques to manage your application build scripts, whether the scripts are managed in Endevor or in Git, should be considered a best practice.
If you’ve found this blog useful and would like to learn more about modernizing your mainframe development practices, you can do so at our Modern Mainframe blog site where we talk about integrating mainframe into Enterprise tool chains with practical examples and use cases.
