{"id":39095,"date":"2021-02-02T18:14:47","date_gmt":"2021-02-02T16:14:47","guid":{"rendered":"https:\/\/www.arcadsoftware.com\/?p=39095"},"modified":"2023-11-20T12:54:25","modified_gmt":"2023-11-20T10:54:25","slug":"true-git-the-right-and-wrong-approaches-to-git-on-ibm-i","status":"publish","type":"post","link":"https:\/\/www.arcadsoftware.com\/arcad\/news-events\/blog\/true-git-the-right-and-wrong-approaches-to-git-on-ibm-i\/","title":{"rendered":"\u2018True Git\u2019 \u2013 the right and wrong approaches to Git on IBM i"},"content":{"rendered":"

By Jeff Tickner <\/h3>\n<\/div><\/div><\/div>

Summary<\/h2>\n
    \n
  1. Source control \u2013 then and now<\/a><\/li>\n
  2. Git on IBM i \u2013 the friction and the challenges<\/a><\/li>\n
  3. Open-source tools cannot handle the IBM i \u2018Build\u2019<\/a><\/li>\n
  4. New Tools, New process<\/a><\/li>\n
  5. Don\u2019t be fooled<\/span><\/span>:<\/span><\/span>\u00a0if it\u2019s not\u00a0<\/span><\/span>G<\/span><\/span>it\u00a0<\/span><\/span>push and\u00a0<\/span><\/span>G<\/span><\/span>it\u00a0<\/span><\/span>pull,<\/span><\/span>\u00a0it\u2019s not Git<\/span><\/span><\/a><\/li>\n
  6. True Git integration with ARCAD <\/a><\/li>\n<\/ol>\n<\/div>
    <\/div>\n

    1. Source control \u2013 then and now<\/h2>\n

    All of us in the business of IBM i application development have been using some form of \u2018source control\u2019 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 \u2018source control\u2019 – or SCM – has taken on a whole new meaning.<\/p>\n

    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 \u2013 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\u2019s 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 \u2018true Git\u2019 approach that brings measurable benefits to both traditional and distributed teams alike.<\/p>\n

    <\/div>\n

    2. Git on IBM i \u2013 the friction and the challenges<\/h2>\n

    As more and more companies look to adopt Git as source control tool for their legacy systems, there is often \u2018friction\u2019 and pushback from more traditional IBM i developers. This is especially ironic because the intent of DevOps is to reduce<\/i> friction with its process. So where does this friction occur and what can be done to resolve it?<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    I often refer to this difference as the \u2018pessimistic\u2019 method versus the \u2018optimistic\u2019 method. Pessimistic because the traditional legacy process locks the code so only one developer can work on it at a time (pessimism = you can\u2019t 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).<\/p>\n

    This \u2018optimistic\u2019 methodology is already a huge cultural shift for many IBM i shops.<\/p>\n

    In essence there are 2 main obstacles that hold back the IBM i customer base from embracing modern source control techniques.<\/p>\n

    1) the \u2018modern\u2019 tools from other platforms cannot work out-of-the-box on the IBM i platform, as they don\u2019t handle or understand the unique requirements of IBM i technology; and<\/p>\n

    2) traditional IBM i developers have to learn and adapt to a new process and new tools.<\/p>\n<\/div><\/div><\/div>

    Git on IBM i? Live and face-to-face over the Web, our experts address YOUR questions around Git and open source.<\/strong><\/p>\n<\/div>

    Watch the webinar<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div>
    <\/div>\n

    3. Open-source tools cannot handle the IBM i \u2018Build\u2019<\/h2>\n

    The \u2018build\u2019 or recompilation process is the biggest tool challenge as there is no open-source build tool that can \u2018build\u2019 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.<\/p>\n

    <\/div>\n

    4. New Tools, New process<\/h2>\n

    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 \u201cforce fit\u201d their code changes into the new process as a very last step. At that point the DevOps process is actually extra<\/i> work instead of streamlined development.<\/p>\n

    <\/div>\n

    5. Don\u2019t be fooled: if it\u2019s not Git push and Git pull, it\u2019s not Git<\/h2>\n

    To try to ease that culture shift, many legacy \u2018Change Management\u2019 vendors on IBM i have attempted to \u201cshortcut\u201d the Git source control process – I call this \u201cProcess Based Source Control\u201d based on some of the information I have seen out there.<\/p>\n

    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 \u2018production source\u2019 on the legacy system.<\/p>\n

    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\u2019t see the result of that resolution until it goes to production<\/u>. Most companies would agree that is actually worse <\/u>than traditional-only development.<\/p>\n

    <\/div>\n<\/div><\/div><\/div>

    Git on IBM i? Advanced Topics : Live and face-to-face over the Web, our experts address YOUR questions around Git and open source.<\/strong><\/p>\n<\/div>

    Watch the webinar<\/span><\/i><\/a><\/div><\/div><\/div>
    <\/div>\n

    6. True Git integration with ARCAD<\/h2>\n

    The better method is when the traditional CM tool is so tightly integrated with Git that it allows direct interaction with the SCM.<\/p>\n

    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 \u2018checkout\u2019, 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\u2019t 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!<\/p>\n

    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 \u2018Git done right\u2019:<\/p>\n