Moving IBM Z source code into Git should simplify development. But when Git still feeds a legacy library manager, teams often end up maintaining two systems, two workflows, and two versions of the truth.
For many IBM Z clients, the journey to modern development practices starts with one key decision: adopting Git as the system of record for source code. Too often, however, teams try to modernize by connecting Git to their existing legacy library managers.
“The long-term goal is one source of truth, one automated path to production, and one development experience across the enterprise.”
Traditional library managers combine source storage, change control, promotion, and deployment in workflows built around partitioned datasets and centralized development. Connecting Git to these tools may feel like a safer transitional step. In practice, it can:
- introduce unnecessary complexity
- limit developer productivity
- preserve the very silos modernization efforts are meant to eliminate
To fully unlock the benefits of modern development on IBM Z, organizations must pair Git with modern pipeline automation, dependency management, and build orchestration—not simply wire it into tooling from decades past. This combination enables teams to retire traditional library managers and replace them with integrated, enterprise-wide DevOps practices that span languages and platforms.
Git and Modern Build Pipelines: The Right Foundation
Git is not simply a new place to store the same code. It provides a fundamentally different model for managing source, versions, branching, and collaboration.
When combined with modern build, deploy, and test automation, Git enables:
- Parallel development using branches rather than serialized changes
- Lightweight, code-centric workflows with no reliance on long-held datasets
- Consistency with the distributed development experience, making skills portable across teams
- Automation-driven builds and deployments that improve speed and quality
- A single source of truth across the enterprise, regardless of language or platform
Organizations gain the full value of Git when it drives the pipeline directly rather than synchronizing through a legacy library manager.
Git should serve as the authoritative repository for source code, pipeline definitions, and related configuration. Artifact repositories can then manage compiled outputs and deployable packages. Together, these components create a traceable, automated path from source code to production.
“Git should serve as the authoritative repository for source code, pipeline definitions, and related configuration.”
Why Connecting Git to Legacy Library Managers Limits Progress
Some organizations consider a transitional approach: connecting Git to legacy library managers so developers can check code into Git but still depend on traditional tooling under the covers.
While this may feel like a safer hybrid path, it can undermine the advantages Git was introduced to deliver:
1. It Prevents Developers from Using Git’s Full Capabilities
Git excels at:
- Branching
- Merging
- Pull requests
- Code reviews
- Fast local operations
- Rich collaboration workflows
Legacy library managers were not designed for this model. When Git must synchronize with them, organizations often restrict branching, require serialized merges, or impose workflow steps that work against Git’s design.
Developers may technically use Git without gaining the speed, flexibility, or collaboration that make it valuable. The organization changes the repository but preserves the old development model.
2. It Creates Two Systems to Manage
Adding a legacy library manager beneath Git means:
- Two systems must remain synchronized
- Two audit trails must be reconciled
- Failures must be diagnosed across two platforms
- Changes may be duplicated between two states
Instead of simplifying the development lifecycle, the hybrid model can increase operational overhead.
Consider the difference between the two approaches:
| Hybrid Git Workflow | Git-first Workflow |
|---|---|
| A developer commits code to Git | A developer commits code to Git |
| Code synchronizes with a library manage | The pipeline starts directly |
| A second workflow builds and promotes the code | Automation builds, tests, and packages the code |
| Teams reconcile two histories and system states | Git preserves the authoritative source history |
| Language-specific processes remain separate | Shared pipeline practices support multiple languages |
The Git-first workflow removes an intermediary and gives teams one clear, automated path forward.
Don't miss these other great articles
3. It Blurs the Single Source of Truth
Which system contains the authoritative source: Git, the library manager, or the output generated by the synchronization process?
When that answer is unclear, teams spend time resolving differences between systems rather than delivering value. This confusion slows onboarding, complicates audits, and creates opportunities for human error.
A Git-first model provides a clearer answer. Git contains the authoritative source and records its history. The pipeline uses that source to create tested, traceable artifacts for deployment.
4. It Slows Down New Developers Coming Onto the Platform
New developers—especially those accustomed to modern distributed tooling—expect:
- Git
- Pipeline-driven builds
- Pull requests
- Automated testing
- Consistent workflows across languages
When they encounter Git layered over legacy library managers and decades-old processes, onboarding slows and the platform feels more complicated than it needs to feel. This can build frustration.
A modern toolchain removes this barrier. It creates a more consistent, intuitive workflow and allows developers to apply familiar skills to IBM Z development.
Fragmenting Tools by Language Undermines Modern Development
One of the most significant drawbacks of combining Git with legacy library managers is that it preserves the long-standing divide between tooling for traditional languages such as COBOL and PL/I and tooling for more modern languages including Java, Node.js, Go, Python, and other languages.
For example, Java on IBM Z can plug into the same enterprise-wide CI/CD pipelines used across the distributed environment. COBOL and PL/I, however, may remain tied to separate, library-managed processes.
As a result, a single multilanguage application may require multiple pipelines, multiple definitions of source truth, and inconsistent workflows. That fragmentation makes the application harder to build, test, and deploy as one solution.
Moving COBOL and PL/I source into Git and automating their builds alongside Java and other languages eliminates this divide. A change that touches both COBOL and Java components can move through coordinated builds, tests, reviews, and approvals rather than separate development systems.
This creates true enterprise DevOps across the full application stack.
A Transition Must Have a Destination
For some organizations, moving directly from a legacy library manager to a Git-first workflow may not be practical. And that’s fine. A temporary bridge can help teams manage risk while they migrate applications, automate builds, and establish new controls.
The danger comes when the bridge becomes the destination.
Organizations using synchronization as a transitional step need a defined retirement plan for the duplicate workflow. That plan should establish clear ownership, migration milestones, and a timeline for removing the legacy library manager as a source-management intermediary.
“The danger comes when the bridge becomes the destination.”
Without that destination, a temporary integration can become permanent infrastructure—and the organization continues paying the operational and productivity costs of both models.
The Path Forward: Git as the System of Record
Modernizing the IBM Z development ecosystem is not about replacing one storage system with another. It is about enabling a new development model.
Organizations can move toward that model in stages:
- Establish Git as the authoritative source of truth. Move application source and related configuration into Git with a clear repository strategy.
- Automate repeatable builds. Create pipelines that compile source directly from Git rather than relying on the library manager to initiate or control the build.
- Manage dependencies and outputs appropriately. Use dependency and artifact repositories to manage required components, compiled outputs, and deployable packages.
- Integrate testing and controls. Add automated testing, security checks, approvals, auditability, and deployment automation to the pipeline.
- Migrate applications incrementally. Move teams and applications in manageable groups while documenting and refining the new practices.
- Retire duplicate workflows. Set milestones for ending synchronization and removing the legacy library manager from the source-management process.
The destination is a development environment in which:
- Git serves as the authoritative source of truth
- IBM Z source is managed alongside distributed components
- Automated pipelines build, test, and deploy across platforms
- Dependency tracking, artifact management, and promotion are automated
- Developers gain a consistent experience across languages
This model already supports development throughout the IT industry. IBM Z organizations can use it to improve scalability, reduce unnecessary complexity, and create a platform that attracts and empowers new talent.
Modernize the Workflow, Not Just the Repository
Putting IBM Z source code in Git is an important first step. But Git delivers its full value only when it becomes the foundation of the development lifecycle—not a modern front end for an older process.
Connecting Git to legacy library managers may offer a temporary transition path. Preserving that hybrid model indefinitely, however, introduces complexity, restricts developers, and perpetuates the silos modernization efforts aim to eliminate.
The long-term goal is one source of truth, one automated path to production, and one development experience across the enterprise. That is how IBM Z organizations enable multilanguage modernization and build a future-ready platform for the next generation of developers.
0 Comments