If your internal development process has not changed in the last couple of years (or even worse, if it has not changed since COVID or even Y2K…) then you are probably missing out on two of the most seismic changes in DevOps tooling: Artificial Intelligence (AI) and git.
In our last blog, we stated that “AI + git is not equal to DevOps” – i.e. AI and git cannot replace DevOps, but adding AI and git to DevOps can truly be more powerful than anything that existed even just a few years ago.
We’ll talk much more about AI in later entries of this blog series, but for now, let’s concentrate on git - specifically, how Rocket DevOps (RDO) has taken the (notoriously PC-centric) git workflow, and adapted it so that it can address the needs of IBM i development teams.
Square Peg in a Round Hole
When you are using open-source tooling like git on the IBM i, it can often feel like the “Square Peg in a Round Hole” idiom where things “don’t fit quite right”. The biggest issue is that open-source tooling almost always assumes that everything is encoded in ASCII (like on the PC) and everyone reading this is probably aware of the EBCDIC encoding issues that occur with IBM i.
On top of that, git assumes that all source is stored in stream files, but in the IBM i world, most everyone is still using source files in libraries – even with stream file support for some languages like RPGLE and C++, traditional source like DDS or CMD still isn’t supported, and users have so many processes that assume library/file/member storage that changing is simply not an option for many.
Common open-source build tools that work with git, like Jenkins, also typically assume that the local system can compile the entire application e.g. Java/C++ etc. will compile every class, object and resource into an executable artifact; in IBM i development, it is completely impractical to recompile the entire application (it can take several hours to recompile even a medium-size IBM i application) so instead, the workflow has to accommodate the need to deal with only the minimum number of changed objects.
Rocket DevOps is there to fill the gap – it knows how to cleanly move the source between source files and the stream files that git requires, and it is optimized to only create the minimum number of objects in a release.
In version 10.2 RDO introduced a hybrid git workflow that is probably more comfortable for existing IBM i developers than git-specific techniques like Gitflow; essentially, RDO allows existing IBM i developers to continue to work how they traditionally do, checking out and promoting source between environments, and RDO takes care of all of the (very complicated) rules of when and how to push source to the git repository.
Version 10.5 of RDO also introduced two-way git support, which allows developers to work from either 5250 or from VS Code – each developer is free to “mix and match” and choose whichever IDE is appropriate for whatever task they are working on.
More recently, Version 11.2 of RDO introduced sparse clone support to dramatically improve the performance and disk requirements of the git process, essentially pulling only the minimum source to the IBM i (instead of the entire repo); and from the IBM i, RDO has always used native git support, which can be significantly faster than the typical jGit implementation that other change management ISVs implement.
Mortise and Tenon
Ironically enough, in carpentry terms, “Square Peg in a Round Hole” is actually a common technique; it is simple to drill a round hole, and with a little brute force, carpenters pound in square pegs which actually have a stronger hold than a round peg would (who knew?!?).
But the best way to create a carpentry joint is actually to create a square hole (called a “mortise”) and drive a square peg (“tenon”) into it; the technique requires a different way of thinking and some additional tools, but it creates a joint with the maximum strength and hold, without the need for additional brute force.
Version 11.3 of RDO will introduce a more modern git integration with the support of git delta releases; delta releases have always existed in RDO, but until 11.3 you could not use delta releases and git at the same time. If we go back to the “Square Peg in a Round Hold” analogy, then we can say the hybrid git workflow is somewhat of a “brute force solution” that works extremely well with the traditional checkout/promote workflow that is common on IBM i, but it also creates a number of headaches when you try to implement a more modern git workflow like Release branching or Gitflow. Git delta release support closes this gap with an expert-level “mortise and tenon” solution that allows you to much more closely match how modern git implementations work - and RDO will continue to do all of the IBM i-specific dirty work that git simply does not know how to do.
Committing to the git Journey
Obviously the first step in this journey is making sure that you’re taking advantage of the newest git features by upgrading to the most recent version of Rocket DevOps (11.2 was released in Q2, 11.3 is planned for Q4). Beyond that and even in the meantime, I encourage you to explore the plethora of git training and learning tools available and start to learn as much as you can.
Git is an incredibly powerful tool, and fully taking advantage of all of its power and functionality will probably take a considerable amount of time, and a fair amount of trial and error to find a solution that fits your own requirements - but if you’re interested, here are some (external) links that might be a good place to start:
A relatively simple, but thorough git workflow comparison from Atlassian
The official git user guide
A very concise, high-level overview of different git branching strategies by Dr Milan Milanović (with the cleanest visual representation of the various flows that I’ve seen)
A discussion on Release flow (which Microsoft strives to use in all of its products) the RDO recommended “best practice” for git workflow implementation
