Speak with an Endevor/Git Advisor
Are you looking to adopt Git in a pragmatic, risk-managed way without disrupting productivity?
Broadcom’s Endevor/Git advisor is here to help by answering your questions and getting you on the road to adoption.
Using GitHub, GitLab, Bitbucket, or Azure Repos for version control with z/OS applications.
Term |
Definition |
| Endevor Bridge for Git | Award-winning Endevor component that enables a Git experience (aka Hybrid Git) without disrupting existing processes. |
| Developer Build | Different from a production build; developers build their changes (i.e., in-flight work) in isolation. After successfully building and unit testing, they commit the changes. |
| Enterprise Git Server | Tool that operationalizes Git; the most common ones are commercial platforms like GitHub, GitLab, Bitbucket (Atlassian) and Azure Repos (Microsoft); they typically offer complementary capabilities beyond version control (e.g., CI/CD pipeline orchestration, DevOps ecosystem integrations, pull/merge requests and online code review). |
| Hybrid Git | Git experience concurrent with existing mainframe platform (e.g., Endevor) for a specific mainframe app; developers choose their preferred interface; Bridge for Git enables the Hybrid Git scenario. |
| Git | A free and open source distributed version control system that supports distributed, non-linear workflows (parallel branches running on different systems). |
| Git Native | Use of Git alone for version control for a mainframe app rather than mainframe tools; requires the code, artifacts and automation to be moved; Team Build enables Git Native. |
| Main Repo | Typically maintained in mainframe SCM tools but can be moved to enterprise Git servers for Git Native development. |
| Team Build | A standalone build engine that enables next generation mainframe developers to work the way they want (e.g., decentralized collaboration via Git); maintains/migrates existing automation. |
The case for Git-based version control for mainframe apps is well-established. A rewarding developer experience is vital for recruiting which is a particularly acute need in the mainframe space. Career mainframers are retiring and the legacy interfaces do not have the same career appeal for next-gens as modern ones like Git. Furthermore, Git adoption facilitates other complementary DevOps capabilities that increase software velocity and quality through automation.
More detailed references:
Git adoption is part of an overall modernization trend bringing many of the best practices from the world of Agile and DevOps to the mainframe. Git Native and Hybrid Git are two of the 15 modernization use cases featured in this helpful roadmap planning toolkit:
[eBook] [Site].
For many, Git adoption is a modernization starting point, but each journey should originate with your current operating environment and incorporate organizational objectives and the long-term vision.
As a journey, ROI and timelines should be achievable - don’t set unrealistic expectations. Begin with an assessment of your staffing needs, especially in light of increased digital adoption and anticipated retirements.
Version control is the foundation of software development and today’s processes and skill sets are built around the current mainframe tools. Replacing a foundational technology can be challenging but more than the technical aspects, the biggest challenge in our experience is culture change. While some mainframe professionals will be familiar with Git through school or coding outside work, many will not and they may not see the same value in adoption as next-gens.
Why is it cultural? Like artisans, developers view their tools as being a part of professional identity. They take pride in their ability to perform at a high level with these tools, and mainframe tools have served them well. By changing their ‘tools of the trade’, career mainframers are at risk of becoming disengaged.
First and foremost, if possible, provide veterans the opportunity to choose to learn Git rather than forcing it on them. This goodwill approach via Hybrid Git has a greater likelihood of winning over key influencers who can have a positive impact on team adoption.
Also, care should be taken to highlight the advantages of Git, and DevOps more broadly, without disparaging the existing workflows or tools. Swapping one version control for another may seem unproductive, so explain the value in terms of overall IT alignment (i.e., applying the best DevOps practices to improve quality, increase automation, reduce manual toil). Often seeing the new process in action will better illustrate the benefits than words or slides so demonstrate the planned future state.
Early on, connect with internal colleagues familiar with your organization’s version control and DevOps standards. In larger companies, this could include a DevOps Center of Excellence, the CTO organization (e.g., enterprise architect) or a CIO standards team. Understanding your organization’s preferred ways of working will help you build out your narrative supporting Git and you may be able to repurpose existing assets.
First, consider the many stakeholders in the current process: developers, SCM administrators, systems programmers, architects & security leads, QA, team leaders. Socialize your roadmap with key internal influencers to get their buy-in, and use them for internal briefings, coffee talks, Q&As, etc. to illustrate enthusiasm for Git.
Because developers are the primary users of Git, AppDev leadership is the most critical influencer. They should be engaged from the outset and be visible champions of adoption.
Depending on the size of your organization, consider assigning formal training resources (e.g., curriculum development for the mainframe audience). For many, the best way to learn is to be hands-on so consider setting up a sandbox environment with sample code. Also, pairing those new to Git with others familiar with it provides a casual communication channel. Find natural teachers who like sharing their expertise with others… avoid the ones who get bothered easily. Consider setting up a dedicated collaboration channel via Slack, Microsoft Teams, etc.
While a new concept for mainframe, Developer Relations (DevRel; aka Developer Advocacy) is a new function in many organizations. If an internal DevRel function exists, evaluate the tactics and channels they’ve established for developer engagement and leverage them for mainframe modernization.
As mentioned previously, culture change takes time so introduce the Hybrid Git option early. Git champions will emerge and will help communicate the benefits to the broader team.
Git adoption is a journey, but some teams/applications might be ready for Git Native. For these applications, introduce Team Build to illustrate the advantages of Git Native to the broader team.
Because Git Native includes a degree of disruption, the primary risks should be assessed carefully:
Git Native is a valid option for applications that pass this risk screening but, in many situations, Hybrid Git provides a more pragmatic alternative.
Endevor Resources (see Modernization section)
The major Git vendors have plenty of resources including training resources. Don’t forget to connect with internal colleagues who already work with these vendors.
Our Git advisors are ready to help - don’t hesitate to reach out for a quick consultation or an in-depth discussion!
Copyright © 2005-2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
