Making Git Part of Your Modernization Strategy

June 26, 2023 Daniel Magid

Maybe the most important part of your IBM i modernization strategy should be modernizing the tools you are using to develop and maintain your applications. Most of the application development world has moved to tools centered around using Git for version control. There is no reason IBM i developers cannot do the same thing. IBM is solidly behind this strategy with their new Merlin product and most of the change management vendors have some kind of Git integration.

By adopting Git for version control, IBM i applications can be managed with the same tools that are being used for development on the other platforms in your enterprise. Millions of developers are using Git because Git is by far the most powerful tool for tracking changes to source code available. Most of the applications you use online are being managed with Git (including development of the Linux operating system). Since Git is the main tool that students learn in Computer Science programs in school, using Git makes recruiting new developers easier. And using Git with graphical systems like GitHub, BitBucket, Gitlab and others makes viewing the history of changes to your source simple.

Easy to view change history with Git: Git tracks every change developers make to the source code. There is no longer any need to comment out deleted lines or put project identifiers into changed lines of code. Git tracks change information automatically. Git users can view what the source code looked like at any point in time and can see the differences between any versions.

Viewing change history is just scratching the surface of what you can do with Git. Git also makes it easy to separate development by projects so you can easily choose when to move the changes related to different projects through testing and into production. Git’s powerful merge functions allow multiple developers to work on the same source without worrying about overwriting each other’s changes. Git will automatically merge their changes together when you are ready. (This is what allows Git to manage open source projects that are being worked on simultaneously by developers at many different organizations.) Git also makes it easy to roll back to a prior version of the application when necessary. And since Git is only storing the changed code between versions, its repository stays much smaller than systems that keep whole source members in their archives.

However, Git based DevOps systems work differently from the traditional change management tools we have used on the IBM i. So, to adopt Git, IBM i developers need to learn to look at the change management process in a different way.

First: What is Git?

Git is a source code version control system. It provides extremely powerful functions for tracking changes to code and delivering versions of your source code in release packages. Unlike IBM i change management tools, Git does not compile code or manage created objects. It is strictly for source code control. It can integrate with other tools for automating build (create, compile) functions but Git does not provide those capabilities.

People new to Git are often confused by the difference between hosting sites like GitHub, GitLab and BitBucket vs the actual Git tool. The online sites use Git as the underlying version control tool and they provide an online place to store your Git repositories. They add powerful features that allow you to increase the power of Git and added functions that make Git much easier to adopt and use. Without the online repositories or other graphical tools, Git is a command driven system. Using the online tools, you get a rich set of Git functions through an easy-to-use graphical user interface.

Git Architecture

Commit-Based System: Changes are tracked in Git by commits. As a developer makes changes to code, they can stage those changes (using Git Add). When they get to a point where they think they are ready to compile and test their changes or they just want to create a checkpoint to which they can easily return, they “commit” those changes. It is then easy for anyone to see what was changed in association with that commit. If a developer is working on multiple tasks simultaneously, they can pick and choose which changed sources they want to include in any individual commit. They do not have to commit everything they have staged. For example, you could just commit the changes you have made for Task1 and not the changes you have made for Task2. Separating changes to code for different projects that are made in a single library can be difficult using standard IBM i tools. But with Git, it is easy.

With Git, it is easy to go from looking at the entire code repository, to the history of commits to the individual changes that were made to each source member for that particular commit operation. The commit history tells you exactly when and why the developer made the changes.

Branching: One of the most powerful functions in Git is its support for branching the repositories. Branching allows developers to work on separate projects or bug fixes in isolation. Branches can then be merged together at your discretion. For example, developers might be working on Feature1 and Feature2 simultaneously. If Feature2 moves faster than Feature1, it can be tested and moved to production without including any of the changes from the other projects. Later, the changes can be merged using Git’s powerful merging function.

This Git repository has a Master branch and two feature branches. Git knows that Feature1 branched off of the master at point B. Until it is merged, Feature1 will not have the changes for points C and D. Developers can make changes for Feature1, build their code and test it without being impacted by other changes. Once they are happy with the changes they have made, they can merge them with the Master branch to combine all their changes with the changes made to master. Meanwhile developers can be working on Feature2 without being impacted by the changes to master or the changes to Feature 1. This architecture allows development to move forward very quickly because developers are not waiting for other developers to finish their work before they can start. It also provides organizations with the ability to decide which changes to move to production in a very agile fashion.

Distributed Repository: Git is a distributed repository system. Every developer typically works with their own copy of the source repository. That way they have an isolated “sandbox” for making their changes. Nothing they do affects the repositories of other developers. Each developer can make changes, build their application and test their changes in isolation.

Changes are shared among repositories by “pushing” (git push) or “pulling” (git pull) changed code from one repository to another.

In a Git environment, there will be multiple copies of the source code repository. A new copy of the repository can be created at any time simply using the Git Clone command. Once a developer has their copy of the repository, they can immediately begin to make changes and commit them to their development repository. When they are ready to share their changes, they can do a Git Push which will “push” their changes to another repository. Alternatively, they can do a Git Pull request which tells the person in charge of the target repository that some changes are ready for them. For example: a developer might initiate a pull request to move some changes to QA or to Production. The approvers for that environment would then decide whether or not to accept the pull request.

Pushing and Pulling Changes: Since each Git user has their own copy of the repository, users need a way to move their changes from one repository to another. For example, if two developers are working on the same task, they may want to work in isolation on their own changes but then share those changes when they are ready. One way of doing this would be to pull the changes directly from one developer’s repository to the other developer’s repository.

However, this technique can lead to confusion over time as to what is the latest version. So, since creating repositories in Git is very easy, a better technique is to create a shared repository for the task being worked on. Developers then push their changes to the shared task repository.

Of course, that kind of simultaneous development on the same code base can expose you to the problem of one set of changes overlaying another. But Git protects you from that. If you try to “push” your changes to a repository that has changes not yet included in your code, it will prohibit you from doing the push. You will first need to “pull” the code from the shared repository to your repository. When you do that, Git will attempt to automatically merge that code with the versions of the changed code you have in your development environment. As long as the changes are not made in the same place, Git will perform the merge for you automatically. However, if you and the other developer have changes to the same lines of code, Git will mark the code and give you the opportunity to resolve the conflict.

With Git, users can set up automated processes around these push and pull operations. For example, you might decide that changes can only go from a task branch to a QA branch and must pass through a QA branch before reaching production. You can set up approval lists to ensure the changes are reviewed and tested before moving forward. You can even add in processes like code scans or automated tests to the pull process.

A Day in the Life of a Git User

If all of this sounds unfamiliar, don’t worry. It is different from how development has traditionally been done on the IBM i. Once you start using Git, the operations quickly become second nature. And the benefits to your organization can be significant.

On a day to day basis, this is typically what you would be doing:

Choose a task to work on
Start making your code changes using whatever tool you want to use (PDM, RDi, VS Code, etc.)
Add the changes to the Git repository using Git Add
Repeat steps 2 and 3 as you make additional changes
When you are ready, commit the changes to your local repository using Git Commit
When you are ready, push your changes to the shared repository using Git Push

These steps can be made even simpler by using IBM i tools for handling the synchronization between Libraries, Source Files and Source members and the Git directories. In that case, you just make your changes in the normal way and let the tool handle getting those changes into the Git directory structure.

Benefits of Git

Some of the significant advantages of moving to Git include:

A Single Repository for All of Your Code: With Git, you can manage all of your IBM i native source in the same repository where you manage your Java, PHP, JavaScript, Python, .Net and other open source code.
Automatic offsite Backup: If you use a hosted Git environment (e.g. GitHub, BitBucket, GitLab, etc.), you automatically have a secure, cloud hosted backup of all your code and all of your change history.
Simplified Audits: Auditors can go to a single place to see all the changes that are being made to code across all environments. They can see who made each change, why they made the change, who approved the change and when the change was made. They can see that the appropriate approvers accepted the changes and that any automated scans were performed.
Developer Productivity: Git’s ability to effectively manage concurrent development allows projects to move forward simultaneously while ensuring that no changes are lost along the way.
Facilitate Recruiting: Git is by far the most popular tool in the world for managing source code. That popularity means that finding developers who know Git is easy. It is the tool that is used in most computer science courses whether they are online, through coding bootcamps or in university computer science curriculums.
A Huge Number of Integrations: Because Git is so popular, almost every software solution related to development can plug into it. IDEs like Visual Studio Code and Eclipse have out of the box Git integrations, issue tracking tools like Jira, Smartsheets, ServiceNow and Salesforce can integrate with Git. Code scanners and testing tools have Git integration. Using Git makes it easy to build a comprehensive DevOps tool chain.

At my company, Eradani, our developers have been using Git with IBM i code for more than a decade. They love it and love to talk about it. So if you would like to learn more about using Git with your IBM i code, give us a shout. You can reach us at www.eradani.com or via email at info@eradani.com.

Daniel Magid is founder and chief executive officer at Eradani.

This content is sponsored by Eradani.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search