Another blog post on the journey of IBMi modernization for code management. We will cover source hosting on GitHub, moving the source from GitHub to IBMi, and compiling all the sources.
As we all must know that on IBMi we can natively do centralized version control. This is why a
source member opened by one user in edit more cannot be edited by another user which makes sense because we don’t want people to change the same source simultaneously. But with distributed version control (DVC) system more than one user can work on the same source by either making a clone into a local machine or creating a separate branch and working on it. DVC system can help in better source management and collaborations between teams. We will cover more in detail please read on and do try to implement.
a new project on GitHub
clone to IFS and run make file? use a custom program to clone the repo and do a makefile run(time consuming).
Make changes on IFS, and push changes to git.
PR, issues, branches, tags, release
GitHub definition as taken from wikipedia.
GitHub, Inc., is an Internet hosting service for software development and version control using Git. It provides the distributed version control of Git plus access control, bug tracking, software feature requests, task management, continuous integration, and wikis for every project.
Git is a free and open-source distributed version control system designed to handle everything from small to huge projects with speed and efficiency. The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model. More can be read here about git on i. Please do note that it is not mandatory to use GitHub with Git, we can do git version control locally as well but the convenience of GitHub makes it easy to use it.
Though there are a lot of articles, videos, and tutorials available educating about the use of GitHub none of them is IBMi specific which we will be covering here. Using IBMi conventions will make it easier for readers to understand the GitHub features and how can they help in native source management. To make it easier for understanding we will be starting a new project as a reference instead of using existing IBMi sources/projects which we will be covering in future articles.
Sign in/Sign up for GitHub which is as easy as creating any social media account.
Some GitHub terms to familiarize with –
Repository – The literal meaning is a place or container in which something is stored in large quantities and the meaning for our purpose is a folder where all of our projects files and the change history is stored in GitHub.
Branch – When a new repository is created it gets a default branch usually named main in GitHub. By default, all changes you make in the repository are on the main branch. Using GitHub one can create multiple branches easily. When a new branch is created in the repository it is typically based on the default branch unless specified otherwise. That means the main branch is copied within the same repository as a new branch. Branching is a way of isolating changes from the main branch and merging them with the main branch when all the changes are ready. The below image copied from GitHub docs will give you an idea of why branching is important. As a convenience, the main or default branch should be used as the base/production branch which means all the code running in production must go from the main/default branch only.
Pull Request – When a developer is done with his code changes and testing, the changes now must go to the main/default branch to be later deployed to production. But before that, a code review is always done which can be requested by the changing developer by making a pull request from his branch to the main branch. This simply means the developer is requesting another person to review his changes and if everything looks good to him then pull his changes from his feature branch to the main branch thus the name pull request. GitHub very neatly shows all the code changes done by the developer on the feature branch. The reviewer can comment on changes or approve if all looks good and then merge the changes into the main branch.
Clone – A clone of a repository means a copy of the complete repository into another machine. Usually, private repositories will need some setup to do that due to security reasons. Also, git should be installed on the machine where the repository has to be cloned.
README.md – A file that usually resides at the root of the project and is used to write information on the project stored in the repository this is to help any new developer who will be using the repository. A special writing format is used in this file which is Markdown format.
There is a lot that can be discussed but since this blog only covers the parts well to get started we have enough. For detailed reading, one can always refer to the GitHub official docs.
Create a new repository with a name of your choice.
Add a new file to the repository
Congratulations !! you have your first file on GitHub.
Setup git on IBMi
This can be done by following the steps mentioned in my previous blog. how-to-set-up-git-on-your-machine
Getting source from GitHub
Since you have your repository and git setup on IBMi done the repository can now be brought on the IBMi from GitHub by conning the repository i.e. fetching the data from GitHub to IBMi using git clone repo-link command e.g git clone https://github.com/IBM/xmlservice.git.
Since we have created a public repository we don’t need to provide any authentication for this step but if we have a private repository then we need to do an ssh key generation setup for authentication. The generated key on the IBMi will be copied to our GitHub account as well. Use this very simple guide from GitHub ssh-keygen.
Since we do these actions on the IBMi PASE terminal we will be the IFS folder and the repository will be cloned in the path we execute the clone command. If you want to store in a different path then before executing the git clone command change your path by cd /new/path/github/mylibrary.
Once the repository is cloned you will see a folder created with the repo. name in your path. If you go into that folder you can find all your files.
Now a big question might be how to use these sources to build objects on the i. Simply by using MAKEFILE. More about makefile and its use in the next blog. By the time you try compiling each source form the terminal using system command system ” CRTBNDPGM ……….FROMIFS(/path/to/ifs)”.