Until recently, the terms “mainframe” and “Git” didn’t seem to match. However, increased adoption of mainframe DevOps practices, the desire to integrate the platform into 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 often. As a result, changes move through the deployment pipeline faster than the monolithic releases common to centralized version control systems. Additionally, its robust collaboration features allow multiple contributors to seamlessly code, review, and merge changes into a single source.
Using Git as the SCM host encourages common development practices across platforms and breaks down silos, enabling integration of the host into CI/CD pipelines. While this mixing of technologies across platforms might present challenges, it doesn’t have to. Git’s success in distributed development can be replicated on the mainframe, if properly planned.
As you plan your Git adoption strategy, it’s critical to remember that while it’s an SCM, it doesn’t manage the complex build and deployment processes that require getting the right copies and associated programs. To address this, consider integrating Git with your existing mainframe SCM solution, which probably already oversees these tasks, rather than replacing it. Your SCM will also act as a trusted deployment mechanism for seamless coordination with all connected distributed applications.
Here are some more tips for those considering Git on a mainframe:
- Explain the reasoning— Part of planning for Git is to provide a rationale. Why should teams consider switching to Git? Help developers understand the issues and benefits to make an informed decision for their teams.
- Transition gradually— Work according to your schedule. Teams can move to Git when they’re ready (and some teams may never move to Git — an important point). The resistance is understandable if all the applications have to be moved at once, which can be disruptive. Instead, the recommended approach is an incremental 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 needed for your builds, ensuring that all of your compile parameters and influences can be used. Crafting should also integrate with your deployment strategy.
- Manage deployment configurations— Avoid deployment disruptions by verifying that your mainframe deployment will be configured and available to work with GitHub Actions, Azure DevOps, Jenkins, Digital.ai, CloudBees Flow and HCL Launch.
- Use related tools— One of the reasons to move to Git as an SCM is to take advantage of a connected ecosystem of solutions, such as advanced code review tools that allow developers to build pipelines to automate their tasks.
It’s good to have options as you plan for your future. Moving to Git can be a challenge, but there are rewards, as long as you plan well. Keeping up with the latest innovations gives your developers what they need, when they need it, giving you the ability to move forward with confidence in your mainframe transformation initiatives.