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.