Mainframe DevOps tooling offers a new era of productivity – with Git leading the charge. But source code migrations are far from straightforward. Fortunately, help is at hand, as expert Stuart Ashby explains.

Introduction

The mainframe development community has benefited from a bewildering array of modern technology releases over the last couple of decades that have almost completely changed how mainframe systems are built. This has coincided with the now-widespread adoption of DevOps as a procedural discipline for application delivery across the IBM mainframe and other platforms.

One example of innovative technology that has found its way into the mainframe world is the Git source repository and tooling. Outside of the mainframe, Git has proven to be a simple, sensible addition to any DevOps toolchain. But is it just as straightforward for the mainframe?

First Things First

Let me start with some assertions. First, in my opinion, the discussion around “Can Git be used for mainframe code?” is over. Vendors have demonstrated the technology integration with mainframes successfully, and some innovative organizations have run successful pilots. It is now difficult to argue that Git is not ready for the mainframe.

Using the Same Vocabulary

Traditionally, the mainframe development community has used terms like compile, assemble, linkedit, bind, newcopy, and phasein to label SCM and lifecycle phases. To outsiders, these terms can seem overly complex. A more contemporary approach describes compile, assemble, and linkedit as the build or the CI activity, and bind, newcopy, and phasein as the deploy or the CD activity. There are grey areas, of course, but these simplified concepts of build and deploy use terminology that is more familiar outside the mainframe community. Crucially, agreeing on the taxonomy for the future is a critical planning component of any SCM repository or DevOps process change.

Drilling Down into Mainframe DevOps with Git

The next question to address is “What is my branching strategy going to be?” The popular strategies to consider are GitFlow, GitHub Flow, GitLab Flow, and Trunk-based development.

Some months ago, I would have instantly replied that it had to be Trunk-based. This strategy has merits because it closely resembles the way that many mainframe developers work: once unit testing is completed, code is not rebuilt but is only deployed into test environments above unit testing.

Having been involved with a couple of organizations on the Git migration pathway, I also see the value of GitHub Flow, where a distinct branch hierarchy reminds me a lot of the traditional SCM lifecycle. In this branching strategy, for example, the developer has a feature branch to implement code changes based on specifications, and then a pull request populates the release branch. This pull request triggers a CI pipeline to rebuild, optimizing the binaries associated with the branch and removing debugging options.

So, there are choices to be made, but they are not necessarily irreversible. You must choose whether to replicate existing branching and build strategies, as these choices will influence your implementation. And remember, there will almost certainly be a cultural shift – so be prepared to embrace that, too.

Migrating Source Code

Once the branching strategy is established, the next step is to migrate the source code (and the vital audit history) from its current system into the main branch of a Git repository.

There is potentially a lot involved here, with numerous factors to consider, including the source location and system, the transferal process, and the target setup. Without sensible planning and preparation, this step can be extremely complex, time-consuming, and error-prone.

Utilities designed to extract the complete source code and history will have to be written and tested, with any defects corrected and enhancements made. Trial migrations must also be validated. Only when the Git repository migrations are complete and fully validated can the migration utilities be considered redundant.

Here to Help

At PopUp Mainframe, we have experience helping organizations modernize their mainframe delivery practices, including moving traditional SCM repositories into Git as part of a DevOps toolchain. Our tools and services streamline this otherwise arduous process, dramatically reducing the effort involved.

Our migration tools and utilities are proven against customer SCM repository migrations, preserving the full change history, including who made changes and when. We can support ChangeMan, Endevor, and Code Pipeline (formerly ISPW). These repository migrations typically take only a few weeks, depending on the repository structure and the amount of source code and history.

After the main Git repository is fully migrated, it is plain sailing to clone, edit, commit, and manage pull requests.

PopUp Mainframe can partner with your organization to create a statement of work (SOW) that outlines the efforts and timelines involved in getting from SCM to Git repository.

Other Considerations

I would suggest addressing a whole area of culture change to support this new way of working. Any change involves people, process, and technology – in that order.

All of the most successful transformations I’ve seen have started with a focus on people and the desired outcome.

The repository migration project should begin with a pioneering “pilot team” to adopt Git. First, we understand their needs, create processes to meet those needs, and get the team onto the new tooling. Feedback from this pilot team helps refine the process and builds momentum for subsequent phases.

This incremental approach ensures broad approval and acceptance within the organization.

It is also essential to measure the pilot team’s productivity with the new tooling. Results typically follow a “J-curve,” with a temporary dip as developers unlearn old processes and adopt new ones, before realizing the tangible benefits. Tracking and projecting outcomes are critical elements of this process.

If your DevOps team is exploring Git as a viable mainframe version control solution and needs guidance, reach out to us.

 

By Stuart Ashby