Transition to Git Source Control: Benefits of a Phased Approach

By Ray Bernardi

In the IBM i world, software development version control systems are used to track code changes, track project history and more. Traditional Source Control Management (SCM) systems use libraries on the IBM i to store prior revisions and perform this tracking. Other options are now available, and Git stands out as the most popular and the easiest to use. Most open teams are using Git already. It’s the industry standard. However, transitioning to Git can be a daunting task.

The driving factor is your codebase and its complexity. The size and complexity of your projects is also a factor in how difficult moving to Git will be. This is why a phased approach, where you make gradual small changes to the development process and allow developers to adapt is usually the best approach.

Navigating the Transition with a Phased Approach

At ARCAD, we like to say, crawl, walk, run, and THEN fly. What we mean is, break down the transition to Git into stages. Don’t start with the largest most mission critical application on the system and shoot for a 100% transition in a month. Don’t tell your IBM i staff they need to learn the intricacies of Git in order to stay productive. In short, do your best to minimize disruption to the workflow as you make this transition.

ARCAD offers several “flavors” of Git implementation, and we can actually mix them together as well. Let’s take a hypothetical IBM i shop and see how we might transition to Git. This shop has 5 IBMi developers. Three of them have been with the company for a long time and use 5250 for most of their development. One of them is a newer hire and is using RDi to perform his development tasks. The last is a brand-new hire right out of school that is familiar with Git, uses VS Code and has seen RDi.

In a phased approach, one of the main goals is to reduce risk. Let’s start there. Working as a team, first choose a business application to be the first to transition to Git. As I said earlier, pick one that’s easy to understand and has a clearly defined workflow. Given the example above, the mix of developers would indicate the use of ARCADs centralized version of Git to start. This version shields IBM i developers from the complexities of Git, while allowing them to use Git for SCM.

In this example, we are moving a small, manageable portion of the codebase to Git. Using this subset, we can identify and resolve any potential issues without impacting or disrupting the existing workflow. This lets you iron out issues and still be productive during the process.

Our next goal is education. Once we identify the code we will start with, configuration of the software begins. We create application definitions; we hook those to your Git repository. We make sure communication between Git, ARCAD, and your automation tools is working. We teach along the way so you end up with a deeper understanding of Git, Git concepts and Git practices as they relate to the IBM i world.

Another goal is to eliminate development silos. In many cases, companies we speak with already use DevOps on the open side of development. Our goal is to hook the IBM i into that existing workflow if it’s there. The idea is to use the same tool stack for change control regardless of the platform the change occurs on.

Real collaboration between the IBM i and open teams starts to happen. The IBM i team can join the agile workflow that is already in use, without the need to learn a whole new way to develop. In this example, the 5250 developers can access the ARCAD application as easily as the RDi and VS Code developer. The application communicates with Git. As the developers open an ARCAD version to make changes, a corresponding branch is opened in the Git repository, they develop on that “feature” branch.

When they checkout, the source comes from the associated branch. It’s delivered to an IBM i source physical file in an IBMi library. They use the editor of their choice. When they are done, a menu option or a right click sends their changes to the Git repository. They barely interact with it, yet their changes are now on a feature branch that can be merged onto a release branch and can kick off your automation software to distribute it where it needs to go. That’s DevOps with IBMi components.

The point of this article is the phased approach. In this example we went from classic change management using libraries on the IBMi. To the use of Git for source control and interfaced it with what’s happening on the IBM i. We took a manageable codebase and workflow and learned the new process. We found and corrected issues along the way as well.

We have now entered the next phase of our project. The education phase never stops, but now, we monitor our results, get feedback from the developers, and improve the migration plan as needed to avoid the same issues as we go after the next codebase we want to migrate.

Now we can start to expand the scope of our migration to Git. We can add more complex code lines and expand the existing workflow to deal with more complex projects. The IBM i developers will understand the new workflow, they will have a good idea of feature branches and release branches, and they will have a good understanding of Git concepts.

The approach here allows you to minimize disruptions, foster collaboration, enhances learning, and allows your teams to successfully make this transition. ARCAD and Git work together and complement each other’s strengths. ARCAD knows the IBM i and Git is the most popular source control tool in the industry.

Using ARCAD and Git together will improve the productivity, efficiency and accuracy of the IBMi development team. You’ll reduce the risk of errors and problems in the development cycle. You’ll be modernizing your tools and your staff at the same time, gradually. You can plug in new features and tools to the DevOps tool stack As you become ready for them. You control the pace.

In conclusion, a phased approach is typically the best approach for an IBMi shop with limited exposure to Git. It’s the starting point for further expansion. Your organization’s maturity level in the area of Git will have a lot to do with how you proceed. ARCAD and Git are a powerful combination that can support you in whatever approach you choose.