Award-winning Endevor component that enables a Git experience (aka Hybrid Git) without disrupting existing processes.
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).
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.
A free and open source distributed version control system that supports distributed, non-linear workflows (parallel branches running on different systems).
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.
Typically maintained in mainframe SCM tools but can be moved to enterprise Git servers for Git Native development.
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.
Frequently Asked Questions
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.
Are Enterprise Git Servers secure enough for our mainframe source code?
Each organization and team should assess this concern in the context of its specific security and compliance requirements. The mainframe community is still in the early stages of Git adoption, but the evidence suggests many organizations are confident their Git platforms satisfy these critical needs.
How do I assess the value of Git adoption for my team?
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.
What is the biggest challenge with Git adoption?
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.
How can we overcome this challenge?
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.
How can we gain buy-in for Git adoption?
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.
What is the best way to educate those unfamiliar with Git?
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.
When ready, can we move our portfolio to Git in one big cutover?
While the ‘lift-and-shift’ approach is feasible, we typically advise against it due to the cultural complexities of Git adoption described previously. However, for teams with smaller portfolios that are prepared with the necessary skills and risk assessment, portfolio-wide cutover to native use of Git using Team Build is possible.
How can I fast-track adoption?
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.
Do we need Endevor to use Team Build?
No, Team Build is a standalone build engine so you can use it with any mainframe version control tool including Broadcom offerings like Endevor, Panvalet and Librarian, homegrown systems, and other commercial tools. Existing automation can be used in many cases through the tool’s JCL converter or the Endevor to Team Build initialization utility.
Do we need Endevor to use Bridge for Git?
Yes, Bridge for Git is an extension of Endevor. With Bridge for Git, teams introduce a Git experience without disrupting existing workflows built on Endevor.
Will Team Build and/or Bridge for Git into my budget?
Team Build, Bridge for Git, and Endevor are included in the DevOps Suite, so customers of this offering have the freedom to adopt Git whenever and however needed without purchasing any new tools.
Which of my applications are ready to move to Git Native?
Because Git Native includes a degree of disruption, the primary risks should be assessed carefully:
Staffing - can the development team support the app with Git-trained resources only?
Frequency of changes - if the app rarely changes, is migrating to Git worthwhile?
Application architecture - if the app is monolithic, are all of the components ready to be migrated?
Application risk - if the app presents a risk to the business, is the value of Git worth the change?
Git Native is a valid option for applications that pass this risk screening but, in many situations, Hybrid Git provides a more pragmatic alternative.