MDNA Speeds Up Git Transactions In Big IBM i Environments
February 24, 2025 Alex Woodie
With the latest release of its change management software for IBM i, Midrange Dynamics North America (MDNA) has addressed a thorny issue impacting the use of Git in large IBM i environments. The company also enhanced how it handles custom IBM i definitions in Git environments.
The use of Git to manage source code has nearly doubled in the IBM i community over the past five years, according to Fortra’s IBM i Marketplace Study, growing to 30 percent in the most recent survey. That indicates a strong push to adopt DevOps technologies and techniques, which is a good thing for the community as a whole.
However (there’s always a but), there are some things in Git that don’t work the same way they work in a traditional IBM i development. In some ways, things work worse in Git. But the advantages of Git more than compensate for the disadvantages, so IBM i shops must find a way to deal with the differences.
That’s what MDNA is doing with the latest release of MDChange, its change management software for IBM i. The issue has to do with how Git behaves in very large development environments, which aren’t unusual in enterprise IBM i settings.
Git works just fine with a few hundred items in an individual code repository running on IBM i. The cloned repo on IBM i is able to communicate with the main Git repo running on a Windows or Linux machine in a timely manner. In smaller coding environments, groups of developers can check out pieces of code, make updates, and commit the changes without noticeable slowdowns.
However, things begin to slow down as the number of items goes up. By the time you have 50,000 items in the repo, it slows to a crawl. According to Michael Morgan, the founder and CEO of MDNA parent Midrange Dynamics of Switzerland, it’s not uncommon for an IBM i programmer to wait up to eight minutes to check an item in or out of a local repository when working in these large environments.
One way to adapt to this situation, which is not exclusive to IBM i development environments, is to move the code from a single, monolithic Git repo into a larger number of smaller repos. However, having the code dispersed across multiple repos can leads to other code management challenges.
The update that MDNA recently shipped can help IBM i shops in either case. “We’ve wanted to make sure that MDChange can help them regardless of the choice they make,” Morgan told IT Jungle.
If the IBM i shops wants to keep a monolithic repository, then what MD Change does it automatically generates several clones of that repository directly on the IBM i development partition, Morgan said. “Then it uses load balancing across multiple MD Change service jobs to ensure that the transaction wait times are minimized, especially when they’ve got several different branches of their code being worked on at the same time.”
In this situation, MDChange will automatically look at which Git branch has the shortest queue, and then assign transactions to that branch. According to Morgan, that ensures that the developers get a much faster turnaround, no matter the size of the repositories.
MDChange can also help customers that want to break their large repositories into a large number of smaller repositories. The software will automatically track the dependencies that exist across these repositories, enabling the customer to continue developing code without worrying about what’s going on under the covers.
“MDChange automatically performs that orchestration,” Morgan said. “It’s aware of what dependencies are in which repos. If you create a branch in one, you have dependency in another, it can create the branches automatically across the different repositories, both on the remote server, like the GitHub server, as well as locally on the IBM i, and to make sure that all the artifacts are pulled in for deployment in the correct order.”
If customers choose to logically break their code up into smaller repos, MDChange will provide load balancing to keep everything running in a performant manner. If it knows it has to pull source from five different repositories for a given feature, Morgan said, then it’ll have five different client jobs running in the background, doing those in parallel to speed up the process.
“So with all this parallel processing, whether you’re doing large repositories or lots of small repositories, you can work much, much faster than what we’re seeing anybody else be able to do if they’re just using a homegrown Git client on the i, or if they’re trying to use one of the other vendor products,” Morgan said. “It’s just massively quicker.”
As previously noted, this phenomenon is not restricted to Git on IBM i. Any sufficiently large coding environment will face the same problem. Git wasn’t written for IBM i – it’s a universal platform, Morgan noted, and the distributed nature of Git brings certain performance differences compared to the ultra-fast and responsive native development patterns that RPG and COBOL on IBM i programmers are used to.
The large file problem was widely known before, but MDNA hadn’t addressed it until now. That’s due to the surge of interest in Git-based development that’s occurring in the IBM i ecosystem, Morgan said.
“Nearly all customers we’re talking to now are at least considering switching to Git to standardize,” he said. “It’s what developers know when they’re coming out of college. It’s what the rest of the divisions within their IT departments use. When then coming up against this, and I’m sure it is a surprise for some organizations…when they’re trying to do everything via Git. And we do advocate for it. But you have to have the right tools in place to keep it from just being a basically an anchor for your development team.”
The other improvement that MDNA is bringing to IBM i shops adopting Git environment involves the handling of custom definitions.
IBM i development environments often have a slew of objects besides the source code itself that needs to be managed, including custom commands, scripts, data areas, and binding directories. Developers often expend a lot of effort making sure these IBM i-only objects are where they need to be.
However, these objects can’t be managed in Git. That would normally require customers to manually rebuild their environments with these objects at every step of the development journey. But with the recent update to MDChange, MDNA can help customers manage those objects as their source code makes its way from development to testing and deployment via Git.
“If you’ve taken the time to get all that in place in your initial branch environment, it would be a high risk and a high amount of effort if you had to repeat that as Git then merges into higher environments,” Morgan said.
“MDChange tracks all merges that occur for Git repositories from a feature branch into, for example, an integration branch, or from integration into a production branch,” he continued. “And because it tracks all of that, it can then go back and look at what custom definitions requirements were needed for that particular feature, and then reapply it to the higher environments as they go in automatically, so that nothing is forgotten. None of that work has to be repeated manually by the developer or the operator that put it in place.”
