By Jeff Tickner
Summary
1. Source control – then and now
All of us in the business of IBM i application development have been using some form of ‘source control’ for versioning our RPG and COBOL code for years already. Until now, the current change management (CM) tools have dominated the IBM i market providing some elementary versioning of application releases, only ONE version of the source per release. But today the term ‘source control’ – or SCM – has taken on a whole new meaning.
The greatest contribution has come from the open source world. The emergence of Git as de facto source control tool has radically changed the way we work – for the better, by allowing incremental versioning of changes, greater visibility, and easy merging. So why are so many IBM i shops struggling to realize the advantages that Git’s continuous and distributed change control can bring? The answer boils down to a kind of collision between two very different worlds. In this article, we will examine why Git implementation on IBM i has been so challenging. We will reveal how to bridge that gap and define what constitutes a ‘true Git’ approach that brings measurable benefits to both traditional and distributed teams alike.
2. Git on IBM i – the friction and the challenges
As more and more companies look to adopt Git as source control tool for their legacy systems, there is often ‘friction’ and pushback from more traditional IBM i developers. This is especially ironic because the intent of DevOps is to reduce friction with its process. So where does this friction occur and what can be done to resolve it?
There are 2 major areas of friction – the tools used in the DevOps process, and the people adapting to these tools and the new process.
The root cause of the friction is the shift from traditional tools and Waterfall process typically used on legacy systems to the DevOps-friendly tools and Agile process commonly used on other platforms.
I often refer to this difference as the ‘pessimistic’ method versus the ‘optimistic’ method. Pessimistic because the traditional legacy process locks the code so only one developer can work on it at a time (pessimism = you can’t trust developers not to overwrite each other); optimistic because the DevOps process allows collaborative (concurrent) editing and modern tools facilitate this (optimism = it will all work out in the end because the process is designed for this).
This ‘optimistic’ methodology is already a huge cultural shift for many IBM i shops.
In essence there are 2 main obstacles that hold back the IBM i customer base from embracing modern source control techniques.
1) the ‘modern’ tools from other platforms cannot work out-of-the-box on the IBM i platform, as they don’t handle or understand the unique requirements of IBM i technology; and
2) traditional IBM i developers have to learn and adapt to a new process and new tools.
3. Open-source tools cannot handle the IBM i ‘Build’
The ‘build’ or recompilation process is the biggest tool challenge as there is no open-source build tool that can ‘build’ a legacy project without someone writing a whole series of scripts to provide the legacy rules. For many traditional IBM i developers, the gap is too great and most are unwilling to hand-code the extra automation required.
4. New Tools, New process
On the people side, the cultural shift for traditional developers and development managers to Git-style source control can be overwhelming for an organization. I have been training traditional developers on these new tools and processes for 8 years now, and I have seen first-hand the challenges they face in making this transition. Developers will sometimes try to work the (pessimistic) way they always have, and then try to “force fit” their code changes into the new process as a very last step. At that point the DevOps process is actually extra work instead of streamlined development.
5. Don’t be fooled: if it’s not Git push and Git pull, it’s not Git
To try to ease that culture shift, many legacy ‘Change Management’ vendors on IBM i have attempted to “shortcut” the Git source control process – I call this “Process Based Source Control” based on some of the information I have seen out there.
Process based source control is where the interaction with source control tooling is not driven by the legacy developer, but instead by the vendor change management (CM) process itself. This partial solution does allow non-traditional developers who happen to be comfortable with the new tools AND the legacy languages to work directly with the source control. However, traditional developers keep working with their same CM process they are familiar with, and it is only later in the process that their changes pushed to SCM. We can say that this allows the source control tool to provide tracking of their changes and brings together both types of developers at some point. Normally when the changes go up to the master source code management branch they also go to the ‘production source’ on the legacy system.
However this method fails to exploit the many benefits of Git such as concurrent changes and branching. By far the greatest downfall to this approach is that the changes that the non-traditional developer makes (directly in Git) are not visible to the traditional developer (using the traditional change management process). That means that a merge conflict must be resolved outside the process-based change management tool directly in Git (command-line or client), and the traditional IBM i developer won’t see the result of that resolution until it goes to production. Most companies would agree that is actually worse than traditional-only development.
6. True Git integration with ARCAD
The better method is when the traditional CM tool is so tightly integrated with Git that it allows direct interaction with the SCM.
With this level of integration, the developer is able to see all the branches, the source being worked on in those branches, start from a specific member and see all of the past and present activity, pull the current source when they do a ‘checkout’, push their changes to SCM, pull additional changes from SCM, etc. directly in the CM tool. THIS is true Git on IBM i. Now the developer has the comfort of a familiar process that has been extended with additional functionality at their fingertips. They don’t have to learn command line syntax to resolve a merge conflict and most importantly they have visibility on what changes are going on around them. That is the real value of SCM in the DevOps process!
Choosing the right path to Git brings measurable returns in the speed and quality of application development on IBM i. Here are just a few of the gains of ‘Git done right’:
- Flexibility of development thanks to true distributed version control
- 360 degree visibility of changes made by other developers
- Easy merge of parallel changes
- Faster delivery of more reliable code
- Rapid reversion to a stable system state
If you are in the early stages of Git adoption on IBM i, you are right on the point of raising the capabilities of your team to a whole new level of productivity and accuracy. Don’t just add process-driven Git so you can check the box saying you’re using Git for your source. That won’t cut it – either for your developers or your management team. Instead embrace the change and really USE Git to get value from it. With the right tools your traditional IBM i developers will learn Git-style SCM techniques and see the benefits of doing so, both conceptually and in their day-to-day work. DevOps is not just a buzzword, it is a change in the way of working that empowers developers to deliver faster and better code. Adopting a ‘true Git’ approach on IBM i with CM tooling that tightly integrates with the Git model is probably the most important milestone on your DevOps journey.
Jeff Tickner
DevOps Consultant, Arcad Software
Why use Git on IBM i (aka iSeries, AS/400)?
How to use Git on IBM i (aka iSeries, AS/400)?
REQUEST A DEMO
Let’s talk about your project!
Speak with an expert