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.