Overview
In this blog post, we will look at how an organization can transform the way they develop, build, and deploy code to the mainframe. The offering provided by IBM allows our clients to move from waterfall methods and legacy tooling to more agile ways of developing their code for the mainframe.
We will look at a solution called GitLab Ultimate from IBM and how it can drive an excellent CI/CD pipeline to help a mainframe team meet their development goals. Why is this solution valuable alongside our zDevOps capabilities? Here are three points that can be addressed using the solution:
- Mainframe developers are isolated from the rest of the application team. The z/OS development team is often completely separate from the distributed team using different tools and methods. DevOps should really bring everyone together.
- Mainframe developers use separate, non-agile tools. In some cases, the tools are decades old and changes to z code are seen as risky. They can be a hindrance to keeping the team from moving at the speed the business demands.
- Mainframe development skills are becoming rare. Before the pandemic, the average age of a z Developer was over 55. In more recent months, the average age is under 50 years old now and by the end of 2022, the average age is expected to be 45. Onboarding to a modern tool like GitLab with the IBM zDevOps tooling can help as developers standardize on a common framework, use common source code repositories, and move away from legacy library managers.
Our zDevOps Tooling working alongside modern pipelines like GitLab Ultimate for IBM can help address these pain points for our clients.
View of a GitLab Pipeline for z/OS
The following graphic provides a high-level view of the solution using GitLab Ultimate for IBM and the IBM zDevOps tooling:
We are leveraging GitLab to drive our development including using git from a source code management perspective and the CI/CD pipeline capability that comes with GitLab Ultimate from IBM. Our CI/CD pipeline which is defined in a .gitlab-ci.yml file will leverage the IBM zAppBuild Framework to integrate with different tools including:
- IBM Dependency Based Build (DBB)
- IDz Z Unit
- Code Coverage
- IDz Code Review
- Wazi Analyze
- IBM UrbanCode Deploy to package, integrate with asset repositories like Artifactory, and deploy to your target environments
The following screen shot shows gives you an idea of the pipeline:
The zAppBuild groovy framework is what will drive each step of the process in the .gitlab-ci.yml. Here is an example of the call to initiate the DBB build process:
$DBB_HOME/bin/groovyz -Djava.library.path=$DBB_HOME/lib:/usr/lib/java_runtime64 $ZAPPBUILD/build.groovy --workspace $CI_PROJECT_DIR --hlq ${HLQ}.${LLQ} --workDir $CI_PROJECT_DIR/BUILD-OUTPUT --application ${APPLICATION_NAME} --logEncoding UTF-8 -cc --verbose ${BUILD_TYPE}
For this blog, we will do a quick overview of each phase of the pipeline with description of the functions performed.
Review of each Phase and Step
At a high-level, the pipeline that is executed in this example, includes the following phases with a description of what is happening behind-the-scenes:
Phase: Import – This step will update your mainframe build target with the latest version of the zAppBuild repository and places it on the USS filesystem. This step is flexible so you could already have the zAppBuild groovy framework on your USS filesystem and this step would not be needed. Many of our clients take the zAppBuild groovy framework provided by IBM and extend and customize it to meet their needs. Often this is placed in a git repository as well.
Phase: Build and Test – In this phase, IBM Dependency Based Build (DBB) is called to perform an “impact build”. It will calculate the list of files impacted by your changes. In our case, the build completes in an amazing 29 seconds as shown below:
This is a huge win for us over the legacy solution leveraged in the past. If we had 100 COBOL programs in our project, it would build all of them and it would take a lot longer period of time to complete.
Further, as the build executes, IDz zUnit Tests will be run depending on what files you modified. The results of the zUnit tests are transformed into a standard junit format so they can be displayed in the GitLab pipeline view. Finally, a code coverage daemon will collect the information from your zUnit tests and generate a report. One of the groovy scripts, AnalyzeCodeCoverageReport, will extract the overall code coverage percentage and present this in the output log.
Phase: Analysis – In our analysis phase, we will help ensure that good quality code is progressing through your pipeline. First, we will run the Code Review step which is a feature available in IDz. The pipeline will run Code Review in batch mode and will tell you if there are some problems with the quality of your code. You can setup “rules” that check the quality of your COBOL or PL/1 programs to make sure they meet your requirements. Example rules include:
- Cyclomatic complexity
- Avoid language elements that are obsolete in Enterprise COBOL 5.1
- Avoid a “select *” in an EXEC SQL statement
Based on the severity of the rule violation, the pipeline can fail at this point and a quick feedback loop is made available to the developer.
Further, in this phase, we will run Wazi Analyze which allows you to see the structure of your mainframe programs in a graphical way. Here is an example:
In this example, a developer could see that a call is missing from EBUD01 to the EBUD03 sub-program. After fixing the issue, the developer would see the graphical representation of the application to properly reflect the call to EBUD03 as shown below:
Phase: Packaging – In this phase, the pipeline leverages IBM UrbanCode Deploy (UCD) to create a deployable artifact. This step leverages the BuildReport.json that is generated by DBB at build time to figure out which files or load modules should be deployed based on the changes made by the developer. In the output log of this step in the pipeline, you will see a “Deployable files detected” as shown below:
Using this output, a shiplist.xml file is generated and leveraged to call buztool to create the new component version for deployment. The version label can use the pipeline ID in GitLab for traceability as well. This new component version can be pushed to Artifactory as an example to provide long-term storage of deployable artifacts.
One of the nice features that our clients love is how you can link the new component version back to the source code, the pipeline executed, and the DBB build result for excellent traceability. Here is an example of the new component version that was created using buztool with the links included:
Phase: Deployment – In our final phase, the pipeline calls a “ucd-deploy.groovy” script to initiate the deployment of the new component version to our Integration target environment. This script is making a REST API call to IBM UrbanCode Deploy to request the application deployment.
You can follow the process request by clicking the URL link as shown above to see the results in the IBM UrbanCode Deploy web console.
As you can see, our deployment was successful and completed in 25 seconds! The ability to perform an incremental deployment without having to deploy all of our COBOL programs as was done in the past really accelerates the time it takes to get our changes deployed to each target environment!
Conclusion
Modernizing the way you build and deploy your z/OS code can address significant pain-points for your organization and drastically reduce a velocity gap in the delivery of your mainframe programs.
As you saw in this post, mainframe developers can use GitLab Ultimate from IBM which includes the use of git from a source code repository perspective. The GitLab pipeline can easily call IBM Dependency Based Build (DBB) to perform “impact” or intelligent builds which include quality testing with zUnit tests and Code Review features that come with IDz. Finally, you can do quick and reliable deployments of your mainframe code using IBM UrbanCode Deploy (UCD) which also provides an excellent audit trail and security model.
This is an exciting step for our mainframe teams. What could take weeks in the past is now completed in a matter of minutes which is a tremendous value to our clients.