3. Making Git ‘smart’ about native IBM i components
Ok then… next issue. Git has no clue what an IBM i is. It has no idea what a PF or a Table is. It has no clue about dependencies. So, how can a build with IBM i components possibly work? By passing what’s changed to a tool that knows the IBM i, that’s how.
At ARCAD we call that tool Builder. It’s a smart IBM i build. If you change a table using Git as your source code repository, Git will pass what you changed to Builder. Builder will then identify all related components and recompile them automatically, in the correct order, in the correct development libraries. Again, automation is the key here. You don’t need a make file, or to script every change. It’s done for you.
The best part is your source is always available on your IBM i. ARCAD using Git will push source to the correct libraries as needed. Developers work on the IBM i in libraries with source files that are all native to them. RDi and 5250 are both supported.
4. One CI/CD pipeline to rule them all
So, with this kind of tooling, your IBM i code can follow the same pipeline as your open source. Are you starting to see the light here? Now we can use the same type of automation for IBM i code that’s used for open code. This opens the door to true DevOps on the IBM i.
For example, you could use Jira to create a task. ARCADs interface with Jira will create the related maintenance report at the appropriate time. That could be when a developer drags the task from Backlog, to In-Development on a Kanban board as shown here.
A branch is created for the developer and using ARCAD Skipper, they develop as they do now, no big changes, no new workflow, no huge learning curve, no slow down in productivity.
When they are ready, they push the change and automation takes over. The branch is updated in the Git repository. The push event triggers a webhook, something has happened, and action is needed. What kind of action? Let’s examine some possibilities. Take a look at the illustration below.
That’s an example of an automated pipeline for IBM i code moving into a unit test environment. This is Jenkins shown in this example. When the developer did the push, Git and Builder together created everything needed. During Integration, the source code was copied from development to a test environment on the IBM i. Objects were either moved or compiled into the test area, that’s a choice you make.
Once the source and objects are in place, the pipeline triggers ARCAD Code Checker. Code Checker automatically examines the source code for quality and security standards that you can set. It’s the first step of the quality gate for your IBM i code.
ARCAD iUnit can then test the procedures in your programs to make sure they still function as expected. Then ARCAD Verifier can run full regression tests over the environment to see if the change had any unexpected results you could not have predicted. All this is automated.
You get reports and results all along the way. You can view them from your automation tool, like Jenkins, so you have one place to look for issues. All this because a developer took a menu option or did a right click in RDi. Can you imagine the time savings?
So without changing things too much for your development teams, this could be your IBM i workflow.
You can see the production line of code on the master branch at the top. Each of the feature branches is a change under development. The feature branches get created from the master branch. Developers work on those feature branches and use the automation we have already talked about. They push to the feature branches. You can also see push events off each of the feature branches, this is not the developer doing this, let me explain.
The developer only pushes back to the feature branch. You can have as many feature branches as you need. The developer can push to them as often as they wish. Now, imagine you’re creating a new release of your software, here is a question for you. When you’re ready to update production, would you prefer doing it change by change, feature by feature, like you did in test? Or would you rather promote the aggregate in one motion as a release? The later sounds a lot easier to me.
That’s what that release branch at the bottom of the diagram is about. It’s there to collect the changes delivered by developers on the feature branches. The push events shown here might be done by your QA department when the change is accepted, for example.
Now remember, a branch has an associated IBM i library. So yes, you would be correct in assuming that when the release branch got created the same thing happened. A library was created to store the release as a whole. The illustration below is a CloudBees pipeline, Jenkins isn’t a requirement, automation is the requirement and there are lots of tools to help you like CloudBees, Azure DevOps and Jenkins.
Once the changes are accepted for the release, the push events shown on the diagram would trigger everything seen above. The process first uses the branch information to determine the correct release library on the IBM i. Before the code is put into the release, it is scrubbed by Code Checker for quality and security compliance. If it passes that test, the source is placed in the release(version) library and compiled during the build. Once the objects are created, ARCAD iUnit tests the procedures again, if that goes well the changes get automatically promoted from the unit test environment, to the QA environment in the Integration step. Then a full regression test is done, and if that goes well, the changes get deployed to a test LPAR.
All that happened because a feature got pulled into the release branch. That’s serious automation and it is true DevOps on the IBM i.
5. True DevOps with Git on IBM i
I’ve been working with the tools I’ve talked about here, and many others, for a long time now. I’ve been talking about DevOps for the IBM i for at least the last 6 years or so. These tools let you shift left. Issues are found early in the development cycle when they cost a lot less to fix. They are redundant; they check things multiple times during the lifecycle of a change, automatically. They automate the steps you now do manually. This is a modern toolset that allows you to treat your IBM i code the same way you do your open code. With agility.
The only thing that confuses me is the rate IBM i shops have adapted to the new ecosystems we are seeing. It’s not the platform; it can handle whatever you throw at it. It’s not the lack of tooling. As you’ve seen here, the tools are available and mature.
This solution allows open and IBM i developers to work together, it includes cross-platform cross reference capabilities, and they can “see” each other. It allows a senior 5250 developer that’s been with the company for years to work like they always have. It allows you to attract new talent because the (young) developers coming out of college today, already know Git, Jira and tools like Jenkins and they will feel at home with it all. This is a solution that works. It’s available today. So what is it then? What are we waiting for? An invitation?
Well then, I formally invite you to examine the rest of the ARCAD site and see what we can do for you and your organization. Now that that’s out of the way, Git Going!!!!