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.