CI/CD with COBOL and CICS

December 4th, 2017

Introduction

Reading about Continuous Integration, Continuous Deployment, CI/CD,  and unit testing etc all seem a million miles away from daily life on the Mainframe.

In fact there is a basic question to be answered for all projects, “Why do we need to do continuous integration?”. Agile Guru, Martin Fowler puts it best (he usually does) when he says

Continuous Integration is a software development practice where members of a team integrate their work frequently; usually, each person integrates at least daily… Each integration is verified by an automated build… to detect integration errors as quickly as possible.

Large software projects are plagued with integration issues, developer 1 changes code and breaks developer 2’s code. If you are not following a continuous integration approach this will only be discovered near release, resulting in many late nights for the developers and even more grey hairs for the project owners. It is at this point that coding standards fall precipitously and “hacking” a change in to “make it work” can ensure that the next project delivery starts with, often, severe technical debts. Unless you are the US government this debt will have to be paid resulting in longer release cycles and missing features.

At Heirloom we develop our products and our code every single day following industry best practices and are extremely proud to call ourselves agile.

That’s great for Heirloom as a commercial software development company producing a completely automated mainframe workload migration platform but what about our customers?

Well our tooling enables our customer’s mainframe code to fit into industry best practice CI/CD environments and processes just like the one below. Because mainframe code compiled with Heirloom PaaS runs on the Java VM we are in the great position that we can utilize all the Java infrastructure that has been built in the last few years to support enterprise application development.

continuous-integration-101-9-638

How do we implement this?

Lets start with the Developer Workstation. Heirloom PaaS is delivered as both a development environment and a set of run time Jar files.

The development environment is an Eclipse Perspective. We add COBOL and PL/1 as fully supported languages to the industry standard Eclipse development environment.

eclipse cobol

We can follow a full development cycle here, EditCompileDebugTestCommit.

The code being worked on in the image above is a standard CICS application presenting a BMS screen to the user. With Heirloom PaaS, BMS screen definitions are automatically transformed into HTML5 templates with the initial template design mimicking the green screen that mainframe users are familiar with. See an earlier post for a typical green screen sample program Mainframe Migration? Why?

The version control server that we use at Heirloom is BitBucket (our clients have used hosted services like GitHubGitLabs or their own internal repositories).

The Continuous Build Server that we use runs the  Jenkins open source automation server.

All our notifications back to the developers are done using using slack channels.

So what is the process flow?

  1. Developer makes and tests code changes in eclipse and commits them to the VCS
  2. A notification is sent to a slack channel, visible to all developersslack bitbucket
  3. The jenkins server is also notified of the change, checks the code out of the repository and starts the build, test and deploy process. Our build pipeline looks like this jenkins pipeline
  4. When all the tests are run Jenkins pushes the newly created artifacts to our overnight build area and creates versioned artifacts in a maven repository. Jenkins then notifies the developers that the build was good (or not) on a different slack channel.slack buildinfo

Summary

Heirloom PaaS migrates not just your mainframe code to a new platform, the Java VM. It also enables you to transform your developer and integration processes. When you use Heirloom Paas your mainframe projects and developers are now full citizens, and can adopt, industry best practices for continuous integration and deployment.

A pre-requisite that many people may have noticed for all this to work is that there is a set of tests that can be run automatically as part of the build and integration process and that is the topic for the next article