The IBM i (aka iSeries, AS/400) community is talking about DevOps, continuous integration, continuous testing, and continuous deployment. These processes that are commonplace on distributed systems have become a priority on the IBM i. As part of their modernization initiative, organizations are seeking to integrate IBM i development into the same enterprise DevSecOps pipeline as used on other platforms. By sharing the same methods and tool stack, organizations can simplify their processes and ease collaboration between experienced IBM i developers and those new to the platform.
CI/CT/CD is what ARCAD does. The ARCAD for DevOps tools are second to none in the industry, and sold by IBM as ARCAD Pack for i. What I’m about to describe is a toolstack that allows IBM i developers to make changes and to use the same pipeline as open teams.
In the diagram above you see tools like GitLab, Jira, UrbanCode. Look to the far left, you’ll see IBM i development in 5250 or RDi. ARCAD interfaces the IBM i with these modern tools. IBM i developers can use the same workflow and toolstack as the open team. This article describes one possible method of doing this, there are many.
In my example today, I’ll talk about GitLab and UrbanCode Deploy (now DevOps Deploy). I’ll mention ARCAD CodeChecker and possibly some other tools as well. The tools I talk about might not be the tools you use. However all tools are interchangeable when creating a CI/CT/CD pipeline, the concept is the same so don’t stop reading if I don’t mention the exact tooling you have. The point of this article is to show you how the IBM i can fit in and play nice with all the tools available today. Here’s one way to do all this…
Using ARCAD, I’ve declared an application as seen above, and gotten it loaded into the ARCAD repository. The repository is really the backbone of this setup. The source control in my example today will be done using Git. Git has no clue what a physical file is. Git has no idea about the architecture found on an IBM i, but the ARCAD repository and process does.
This repository is meta-data about your production environment that’s used for analysis, and during the build process. When a change is made using Git for source control, ARCAD Builder uses this repository to automatically perform the IBM i build and get it right.
The application is configured to use Git, and once connected, the application can load all your IBM i source to a Git repository. A single command does it for you. Here you can see all the native code for a business application stored in Git.
As seen below, a build process has been configured in ARCAD Builder...
...and ARCAD CodeChecker has been thrown into the mix as well. CodeChecker reviews codes for quality and security issues. It’s part of a good quality gate for your IBM i code.
Finally, I am using IBM UrbanCode Deploy to automate the deployment of my iSeries application into my target environments. In this case, I am using JFrog Artifactory as my artifact repository behind-the-scenes.
Those are the main tools in use in my example. So, how would this work? It’s actually a lot easier than you think. The process I have setup starts in Gitlab with the creation of a branch as seen Below:
In the example above, you see a developer or project manager creating a sandbox branch from a release branch. The sandbox branch is where the developer works. When they are done with their changes, once accepted, they are merged into the release branch. The release branch becomes the aggregate of all changes made in the sandbox branches. When ready to update the next environment, the release is transferred, not dozens of sandbox branches.
ARCAD supplies webhooks to use in Git when things like a merge or branch creation is done. In today’s example, when the sandbox branch was created, the webhook created a version on the IBM i in ARCAD as seen above. The version is associated it with the correct branch in Git
Any number of sandbox branches/versions can exist. The same program can be worked on in any one of the versions with no issues. When the branches are merged into the release, Git will resolve conflicts. This workflow is well suited for concurrent development.
The IBM i developer works as they always have. To begin the change, they perform a checkout as seen here.
This “checkout” is actually a pull from the sandbox branch. Under the covers, ARCAD pulls the correct source from the correct branch and places it in the version library on the IBM i. Developers edit source in RDi on the IBM i as they always have. They could even use 5250 to perform these actions. Checkout would be a menu option instead of a right click.
The idea is to make sure IBM i developers, who might be very set in their ways, feel comfortable with this new technology. The workflow doesn’t change for them; the change is under the covers.
Developers use ARCAD as always to analyze the change. They edit and compile on the IBM i. If they can develop now using 5250 or RDi, they will be able to develop once you start using Git for source control. Nothing changes for them as far as workflow is concerned. They already know what to do.
Above you see the context menu option to perform the “push” back to Git, ARCAD calls it Export to SCM. Once an IBM i developer is happy with their change, this is how they deliver it back to the branch in the Git repository. It’s not rocket science!
The developer can now work on any other change while this one is reviewed and quality checked. If there is an issue the developer can be notified, they can make further changes and push again. There can be tight control and approval processes even though Git is the source control.
Above you see a merge request. On the left is the change on the sandbox branch that was just delivered by the developer. On the right is the release branch that’s collecting all the sandbox changes. The way they are collected is through this merge process.
This merge is taking place using GitLab, and whichever collaboration tool is used, the results will be the same in the Git repository. No matter the tool, ARCAD can use a webhook at the right time in the process. In my example today, this merge into the release is using a webhook to start up a pipeline process that’s going to do some serious automation for me.
From Gitlab you can see the pipeline and all the steps it will take. This entire process was triggered by the merge. First ARCAD Builder is told what changed by Git. Builder then performs a build on the IBM i of the components, the correct relationships, and does it all in the correct order. Below you can see the results of the build. ARCAD automatically created everything required in the Release Version! The change we just worked on is part of the release now and can be tested.
So then let’s automate testing too. In this example, ARCAD CodeChecker gets triggered. It's part of the quality gate for the IBM i code headed for production. CodeChecker automatically performs a code review and points out quality and security issues that need to be addressed. We could also trigger ARCAD iUnit or ARCAD Verifier, other IBM i-specific continuous testing products.
Then you see an upload of the artifacts to an artifact repository. We are getting ready to perform a deployment using UrbanCode Deploy (UCD). This example uses JFrog as our artifact repository, there are others. The artifacts getting loaded in this process are inside a save file. That save file is the contents of the release version. Here you can see it in JFrog:
Remember, all this started because the developers change was accepted and a merge was performed to the release branch. There is no person performing these steps, it’s all automation.
Finally, this pipeline deploys the changes using ARCAD’s technology and UrbanCode Deploy.
The process of deployment was configured in UCD and is reusable. This process is setup to place the release in a user acceptance test are where needed. Today we are targeting another IBM i. This deployment could also contain open artifacts and be deploying to Windows, Linux and other servers as well.
Here you can see every step taken in the process:
That’s CI/CT/CD for IBM i. What we just walked through means your IBM i developers can be as agile as your open team. It means you can use the same toolset for management and deployment of changes even if those changes are on the IBM i.
Like I said at the start of this, the open world has worked like this for a long time. The IBM i as a platform is ready to use this modern tooling now. ARCAD Software provides this modern tooling with the IBM i knowledge required to make it all possible.
Thanks to the ARCAD Software team for their help in putting this article together. You can find a high- level summary of the ARCAD Pack for i solution here:
[Datasheet] ARCAD Pack for i – Include IBM i in your enterprise DevOps Strategy
For more information about DevSecOps on IBM i, please contact our team of IBM i experts at https://www.arcadsoftware.com/about/contact/