DevOps on IBM i: Beyond the hype

By Andrew Clark 

So you’ve probably heard the buzz around two terms in DevOps: Continuous Integration (CI) and Continuous Deployment (CD).  You probably also have heard about things like Ansible and Docker and Kubernetes and how they relate to CI/CD and DevOps and are completely confused about how they apply to the real work that you are doing on your IBM i today.

The answer is that CI/CD concepts are completely relevant to what you do, but the tooling that you’ve probably heard about (Ansible/Docker/Kubernetes/etc.) really don’t apply (yet!) – and in fact aren’t really necessary because the unique architecture of the IBM i (i.e. integrated database, independent ASP support, ILE) takes care of most of the things those tools do.

You’ve probably also already know about all of the supposed goodness of CI/CD:

• Quicker deployments
• Fewer errors (and lower cost)
• Better response to end-users

…but the question remains, how do I get from where I am today to “real” DevOps?  Maybe nothing that you’ve seen has given concrete examples of what needs to be done?  Here’s a good head start:

CI = automated build and regression testing
…if you strip away all the hype, continuous integration is really (conceptually) very simple; when a developer makes a change, all of the necessary related objects are automatically built, and an automated test case runs to ensure that no existing function is broken (that’s what “regression test” means).  If any of the regression test cases fail, then the change is rejected and sent back to the developer to fix.

Notice that automated is the key word here – no human being needs to press keys on their keyboard or click on their mouse to run those tests, it is all handled by a build process that might be as simple as something like a CL program or as sophisticated as something like Jenkins.

CD = micro-versions
…if you strip away all of the hype, Continuous Deployment really just means that when a single functional improvement/change is complete (a “micro version”) then that change is pushed to end-users  immediately – the concept of waiting to bundle lots of changes together into a single “big bang” version is obsolete.

1. Seriously?!?

Seriously.  Instead of building “Version 1.0” now, and then waiting 3 months to build “Version 1.1”, and then waiting another year to build “Version 2.0” changes get implemented immediately.  In traditional “big bang” versions like this (1.0, 1.1, 2.0 etc.) here’s how development reacts to end-users:

End-user: “Hey, development, I’ve got this great idea {…insert great idea here…} could you make that change for us?”

Development: “That is a great idea!  Should take about two weeks to develop, so we’ll try to get it into Version 1.1 at the end of next month, but if we miss that deadline it won’t be available until 2.0 next year.”

Here’s how development reacts to end-users with DevOps:

Development: “That is a great idea!  Should take about two weeks to develop, and will be ready for you to try out then“

2. That’s not possible…

…actually, it is possible, but you might need to make some changes to get there…

1. Your application must be “scriptable”
   This is often the most difficult hurdle for implementation of DevOps. By “scriptable” we mean that each and every “function” of your application must be able to be called by some kind of “script” (e.g. CL program) with expected inputs and return expected results.For instance, you might have a “New order” function – you must be able to call that function from a batch process (no 5250 i.e. must be runnable from a submitted job) and must be able to return success/failure based upon various inputs.This means by definition that you must have “business logic” separated from your “user interface” i.e. your single interactive RPG order entry menu-driven 10,000 lines-of-code program is not going to cut it…
2. You have to have a real test script
   Testing is said to be a pillar of DevOps because delivering “faster and more often” means accepting the risk of frequent updates in production. Continuous testing offsets this risk.
   The sad truth is that many companies don’t have any kind of test script in place, whether it just be a simple document or some existing automated test process – when a new version is generated, it’s released to a QA team and they may run through some kind of manual process or might just randomly test a few of the major functions of the application to make sure that they work – that’s not going to cut it either…

There is much scope for automating this part of the process.  Once you’re in the habit of of creating specific test scripts for each new function you want to deliver, you can go one step further and automate the “unit” testing of your new code. There are tools out there that understand your application code and help you create your unit tests so you can re-use them for “smoke” testing later (check out ARCAD iUnit).  The goal of course being to catch defects even before they are deployed to QA for regression testing…

Then once in QA, the IBM i regression testing tools (like ARCAD Verifier) can trigger functional tests to run over your ready-to-deliver IBM i application to give you a final safeguard before your code reaches production.

Once you’ve reached this level of automation, you’re already well on your way to achieving a “continuous test” (CT) approach to development…

Andrew Clark

DevOps Product Manager