Until recently, the terms “mainframe” and “Git” appeared to be a mismatch. However, increased adoption of DevOps practices on the mainframe, the desire to integrate the platform in enterprise-wide continuous innovation/continuous deployment (CI/CD) pipelines, and its familiarity among next-generation developers have made Git a popular solution for mainframe source code management (SCM).
Git’s feature branches, distributed development, and pull requests facilitate an agile workflow, encouraging developers to share smaller changes more frequently. As a result, changes move through the deployment pipeline faster than the monolithic releases common with centralized version control systems. Additionally, its robust collaboration features allow multiple contributors to seamlessly code, review, and merge changes into one source.
Using Git as a mainframe SCM encourages common development practices across platforms and breaks down silos, enabling the integration of the mainframe into CI/CD pipelines. While this blending of technologies across platforms could pose challenges, it doesn’t have to. Git’s success in distributed development can be duplicated on the mainframe, if planned for properly.
As you strategize your Git adoption, the key is to remember that while it’s an SCM, it does not handle complex build and deploy processes that require sourcing the correct copybooks and associated programs. To address this, consider integrating Git with your existing mainframe SCM solution, which likely already oversees these tasks, rather than replacing it. Your SCM will also act as a reliable deployment mechanism to coordinate seamlessly with any related distributed applications.
Following is more advice for those considering Git on the mainframe:
- Explain the rationale—Part of planning for Git is to provide the rationale. Why would teams want to consider moving to Git? Help developers understand the issues and the benefits to make an informed decision for their teams.
- Transition gradually—Work on your schedule. Teams can move over to Git when they are ready (and some teams may never go to Git—an important point). Resistance is understandable if all applications must move at one time, which can be disruptive. Instead, the recommended approach is a gradual one, where applications are moved to Git when team members are ready.
- Automate builds—Make sure you have an automated method to create the relationships necessary for your builds, ensuring that all of your compile parameters and impacts can be leveraged. The build should also integrate with your deploy strategy.
- Manage deploy configurations—Avoid deploy disruptions by making sure your mainframe deploys will be configured and available to work with GitHub Actions, Azure DevOps, Jenkins, Digital.ai, CloudBees Flow, and HCL Launch.
- Employ related tooling—One of the reasons to switch to Git as an SCM is to leverage the related solution ecosystem, like advanced code review tools that allow developers to build pipelines to automate their tasks.
It is good to have options as you plan your future. Moving to Git can be a challenge, but there are rewards, as long as you plan properly. Keeping pace with the latest innovations provides your developers with what they need, when they need it, giving you the ability to move forward on your mainframe transformation initiatives with confidence.