There is no need for mainframe teams to shy away from Git as a single integrated source repo. Today’s mainframe development space provides many options to choose from and embraces the same open-source tools that you already use in your enterprise like Git, Ansible etc. and this path is not new. Many large enterprises that have migrated to Git, and IBM has case studies on how this has helped organisations in their digital transformation journey. And as you probably guessed, this SCM can be any implementation of Git (GitLab, GitHub, BitBuket, etc.).
As we talk about Git as SCM, I also wanted to touch upon the Git-bridge solutions I hear about. It is usually about retaining the current library manager as is, putting a Git front-end, and syncing between these two. When you hear about it for the first time, it sounds simple; but deep down it has many nuances that are not immediately visible.
Let us take a diversion for a bit. In India (where I live), pedestrian bridges have become cheaper, quicker solutions to the traffic problem of pedestrian crossings disrupting vehicular flow. These pedestrian bridges create islands. People start identifying addresses as “west side of the bridge” and “east side of the bridge”. Over a period of time, the west and the east even become culturally different neighborhoods. Ideally, cities have to be built with pedestrians in mind. Similarly, SCMs need to be built with developers in mind, and developers should not have to worry about maps and bridges.
Mainframe SCM bridges that link legacy SCMs with modern SCMs create more problems than solutions. The real need for a SCM is to have “one source of truth”. How does one guarantee “one source of truth” when it is hosted in two different tools? SCM’s bridges give a false illusion of the “best of both worlds” where developers get access to a modern SCM to develop and operations still use the old library managers for controlled environments. But what do we really end up with?
- Islands of development teams have their own version of common modules that are not integrated.
- Increased pain for developers who spend their development time making sure that they follow the processes religiously for code duplication, code reconciliation, integration testing, etc. This obstructs the flow, just like pedestrian bridges.
- The bottleneck of sequencing projects just moves from development to integration region and the velocity of delivery to business remains almost the same.
- Developers spend hours in training for the new SCM, usually Git as front-end and a bridged legacy SCM as back-end, without any clearly defined benefit.
- Two different cultures of programming start evolving between people who use the bridge and who don’t.
- Young mainframers still need to understand the old development process and adhere to it.
Just as using Jira and Scrum does not make a team agile, similarly using SCM bridges will not make the legacy library manager problems magically go away.
So, what is the solution? The solution is a single modern SCM that stores all source code in your organization. The solution should provide truly modern DevOps tools to developers and operators and not just the facade of pseudo-modern tools. Talk to your IBM representative today about getting started on this journey. We can also help you through our DevOps Acceleration Program. Together, let us achieve the goal of transforming your mainframe development process to be truly agile.