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.