Using Team Build with Endevor
When and why we should use Team Build with Endevor
In the previous two blogs (#1 and #2) of this series, I introduced working on your Mainframe software projects with a modern IDE like Visual Studio Code and invoking builds/tests with a single keystroke. If your projects live in Endevor and you’d like to try the new way of software development, this blog can help with the one last piece to get started — a way to initialize a working directory with the Endevor source.
You may be wondering why you should bother using Team Build with Endevor. Endevor build automation is easy to invoke so why should you change? A primary driver is the adoption of Git. This blog outlines a number of reasons why adopting Git may be the right answer for your organization.
In this blog, I will introduce two ways of working with Endevor projects and Git, supported by Team Build to perform your application builds.
First of all, both approaches take advantage of Endevor Web Services which is a component shipped with Endevor (version 18.0.12 or later is required). You need to consult your Endevor support team about its availability.
Now suppose we have a COBOL application in Endevor:
How can we start working with these source files and Git? Well…the answer depends on whether you are going to move to the native use of Git as the version control system or you want to continue to use Endevor as the gold copy.
Mirroring Mainframe software project by Bridge for Git
If you want to keep your code base in Endevor as a gold copy, you can use Endevor Bridge for Git and set up an environment as the following diagram shows:
The Endevor Bridge for Git server synchronizes the elements in Endevor with the corresponding files in an Enterprise Git repository. When a dev branch is merged to the synchronization branch, the code change will be automatically synchronized to Endevor. Moreover, the changes made to Endevor will also be synchronized back to the Git repository.
In this architecture, the build can be done by Endevor with the help of Zowe CLI. In this scenario, the changes in the developer’s working directory are sent to an Endevor environment to be built and tested.
If you want to know more about how Bridge for Git works, I recommend reading the easy-to-follow whitepaper.
Alternatively, you can use Team Build as the “Developer’s build” and initialize your working directory using Team Build’s initialization utility described below.
Initializing a Team Build project from Endevor
Team Build includes a utility called Exportz that lets you initialize a project from existing Endevor build automation. You can either include the source code if you plan to use Git natively without Bridge for Git or simply extract the build automation.
Exportz is a standalone program for Windows, Mac, and Linux that initializes the project from Endevor on your local file system. Both the associated Endevor processors and source code dependency relationships will be properly handled. In the end, you will have a runnable build script and optionally the related source code in a working directory of your choice. You can check the resulting files into any source repository or if you are creating a Bridge for Git developer’s build, into the mapped Enterprise Git repository. You can also use Team Build’s Syncz and Bldz to transfer the files to the LPAR and build/run the programs.
Let’s initialize a Team Build project for the COBOL application mentioned above using Exportz:
As the initialization utility runs you can see a number of messages describing the progress or any problems it may have encountered:
Errors and warnings will be printed with “[ERROR]” and “[WARNING]” prefixes. If your terminal supports color, those prefixes will be in yellow and red color respectively. If it failed to work, you can first check for potential typos in the local path, the Endevor system/subsystem names, your user name/password, and the URL of the Endevor web service (version 18.0.12 or later is required). You can also contact your Endevor support team.
If everything went smoothly, we will have all the files exported. We can work on them in Visual Studio Code or any other IDE/editor of choice:
We can use Syncz to transfer the working directory to the LPAR and use Bldz to run the generated build script: (Syncz and Bldz are sibling tools of Exportz in Endevor Team Build)
By default, the build script will use the specified HLQ to create some data sets for the generated artifacts and intermediate output files. In our example, the load modules are found in the “.LOADLIB” data set:
Those data sets will be automatically created or updated by the build script. It is always safe to delete them when they are no longer needed.
To add your customized post-build actions, such as publishing to binary repositories or deploying to CICS regions, we need to add more code (JavaScript) to the generated build script. We will talk about Publishz, the publishing tool of Team Build in a future blog of this series. This utility helps with publishing artifacts to raw-format binary repositories. JFrog Artifactory and Nexus Repository Manager are currently supported. The binary repository is a perfect solution for sharing modules and libraries with other development teams.
In this blog, I briefly introduced two ways of using your Endevor project with Team Build and Git. Endevor Bridge for Git keeps bidirectional synchronization between Endevor and Git, and Exportz directly initializes Team Build projects in local working directories from existing Envedor projects. If you want to learn more info, you can find it here.
A wide range of Endevor/Git blogs is available here.
And don’t miss the many resources on the Endevor webpage.
