DevOps maturity on IBM i: let go of the past

When speaking of the IBM i and the lifecycle of application development, it would be easy to stick to the old ways of working. But in today’s world, those old ways just do not cut it. Forward thinking enterprises have massively adopted the Agile and DevOps philosophy. Source control is distributed and tools from the open-source world deliver changes continuously bringing new features to users faster. I will argue that with all its differences – and its advantages – IBM i belongs in this open-source DevOps world too. The risk of staying put is just too great.

Today, I’ll cover the following:

1. My perspective (keeping IBM i applications up and running)

To start, I grew up on green screen while supporting customers across the spectrum for more than 30 years. I have seen the pain of controlling the source code, testing the code, and fixing the bugs in production. I cannot count how many times I was called at 2am to fix a level check error in production. While the IBM i has changed a lot over the years, growing up from the AS/400 through the iSeries years to where we are today, one thing stayed constant during this time. The pain of moving through the Development to Production process.

When I joined ARCAD Software earlier this year, I had the chance to dive into the suite of tools available. My first thought was, I can think of a dozen former customers that could benefit from just a part of this suite. ARCAD starts with the analysis and audit of your code, and this alone is a game changer. How many times have you wondered if you are working off the correct source? This analysis aids in cleaning your development environment, which is especially important when moving into the future of DevOps and the use of open-source tools. But the ARCAD tools don’t stop there. The application knowledge – or metadata – that is derived from this initial analysis phase is re-used across the entire end-to-end CI/CT/CD cycle making each of the downstream ARCAD tools smarter and faster. More about that later…

My perspective on code development is a bit different as I am not a developer. I was an admin for most of my career, and my coding skills focused on code that would make my life easier or help me debug 2AM errors. In my duties, I usually had to start with hunting the source code. The DSPPGM command was my friend along with DSPDBR. What I have found with the ARCAD products, they take away the need to do that level of hunting. Why? Because it will not let the developer push to production without a few dozen checks along the way. Here is how this works…

2. The ARCAD workflow: nothing is wasted

Lifecycle and Source Code Management are at the heart of what ARCAD brings to the table. You can see in the diagram below how it can touch and assist in each area of the CI/CT/CD flow. ARCAD manages the entire versioning process either with Git or natively as you prefer. Then as you check-out, edit and compile your source code directly from LPEX, you can right-click on any text field, file, procedure, program, data area, or even literals to see everywhere that construct is used which is a great time saver. Then, ARCAD will analyze your source code to highlight any areas that break quality or security rules. Once you are done and you commit your change, a build is automatically launched, compiling any impacted dependent code. No more manual sequencing of compiles! ARCAD optimizes the build to compile only what is needed and in the right order. After the build, then unit tests and functional regression tests are executed for you in a continuous flow. Once the release is validated, it is deployed automatically to production, with a rollback on error.

With all this automation, the developer only needs to worry about writing code. All those pain points from where is my source, who tested this and why was the defect not found, to controlling the roll out of code across not only your IBM i Environment but your Open and Distributed systems are all taken care of.

3. Automation and ‘shift left’

Wait, am I saying the developer will have to go through a checklist to push the change to production or even just to the UAT environment? No, that is the great thing with ARCAD, all is handled behind the scenes. If you update the format of a file, it will find all the programs and objects that need to be recompiled. So, no more Level Check errors. If the file changed involves a dozen other screens, programs, files, or menus, those are all known thanks to the repository created at the install and those objects recompiled as needed. Now the developer can focus on the code rather than the ‘what ifs’. This is a great time saver or moreover a great money saver to your company. All part of the ‘Shift Left’ mentality. When you hear Shift Left, the first thing you should think of is, the cost of creating code and moving it into production. The closer to production defects are found, the more expensive the fix. So, ‘shifting left’ massively lowers the cost of a defect fix.

4. Open source tools on IBM i

So now you’ll hear scary terms as you embrace DevOps on IBM i like Jira, Git, Jenkins. You’ll hear things like Pipelines and Branches. But don’t worry, I have found that the Arcad Software Suite makes this painless. As I said before, I’m not a developer, but to learn the basics to make and promote code in a DevOps environment was made easy with ARCAD. So let go of the old way of thinking with SEU and PDM, embrace RDi, Open Source, SCM, Git, Jenkins and Pipelines, because ARCAD will be there to guide you through the CI/CT/CD process. ARCAD is at the center of this universe and driving the movement forward.

At this point, you are thinking, what does this have to do with letting go of the past? This just seems like more work instead. Well as you probably know by now, we are all knee deep in the DevOps/Agile philosophy which applies equally well to IBM i as to any technology platform. You will see from the case studies below that we have rapidly rolled out DevOps on IBM i with Git and open source tools in some of the most traditional IBM i development teams. Because the ARCAD layer makes the Git interface totally transparent, even the most senior IBM i developers are happily branching from the same Git repo and CI/CD pipeline as their (probably younger) peers developing on Windows or Linux!

5. Git on IBM i – RDi or green-screen!

Many will fear that new DevOps paradigms will replace them as developers in favor of those that grew up on Open Source. This is where the thinking is wrong. What I will say is that DevOps opens the door for you to do your job more effectively and with ARCAD solutions in the background, the task of bringing a new enhancement into the hands of your users will be way faster and more secure.

Other traditionalists will say “I don’t want to learn about Git,” well that’s the nice thing. Odds are someone on the distributed systems side of your organization is already the master at this. They would handle the up-front configuration of your SCM environment. Then the ARCAD technology layer shields you from having to work directly with Git itself. You would just be given a version to work in and then ‘just code’. If you don’t want to let go of green screen, that’s also okay as you can code in ARCAD Skipper using either RDi with the LPEX editor or in 5250 as below:

Is it really that simple, in a way? There are a few new steps needed to get you started, but the automation is a major time saver. The next thing you know is you’ll be an old hat in this new game.

5. Next steps

So, what is next now that you have let go?

Embrace the automation. Embrace the Open Source. If you are like me, the exploration of new ideas and concepts is what energizes us and the guarantee that IBM i applications will continue to benefit the business for years to come. Reach out and research the DevOps landscape. The greater the automation, the more time you have available to innovate new functionality and satisfy your users and the business!