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…

Implementing a DevOps strategy on IBM i? Influencing IBM i DevOps maturity and success in the enterprise?

3. Sounds great – how do we start?

If your application is RPG or COBOL, then probably start here ([White Paper] DevOps Transformation: Engage your IBM i teams) and then:

  • Lay the Foundation
    • Analyze your existing resources
      • Skillset, methodology, existing tooling
      • Identify “Champions”
    • Pick DevOps tools that match your needs and experience
      • …not necessarily those that have the largest visibility
      • …seriously consider sharing common DevOps tools with developers on distributed systems (e.g. Git, Jenkins, Jira, Azure DevOps), to achieve a common DevOps toolchain enterprise-wide
      • …remember that open source tools alone don’t cut it on IBM i – so look for an IBM i DevOps vendor that offers ready-made integrations to make the adoption of open source easier
    • Document your existing application (files/fields/programs by function, type, etc.)
    • Conceptualize what “functions” need to be tested
  • Make incremental Development changes
    • Implement source control (e.g. Git)
    • Start using RDi (if you aren’t already)
    • Break up monolithic programs into modules and procedures
      • First step – convert RPGIII->ILE (if you haven’t already!?!)
    • Separate business logic from user interface (aka MVC)
    • Write actual test scripts OR
    • Use an IBM i unit testing tool to create re-usable program and procedure tests
    • Automate your functional regression testing using Jenkins as driver

It probably makes sense to make many of those incremental changes as part of an existing release i.e. do RPGIII->Free form as part of existing projects, not as one “big bang” to try to switch things over (so that the conversion is fully funded and is part of new features that are being developed).

Continuous integration also implies that users will continuously be using the newest versions of the objects, so there needs to be a way to “switch over” to the new objects – this is usually fairly easy (using iASPs) but there are some technical issues that you should be aware of – we’ll discuss those in the next blog article; happy DevOpsing!

“Git Ahead”: from IBM i change management to Git. Make a success of Git and Jenkins in your IBM i development today. 

Andrew Clark

Andrew Clark

DevOps Product Manager

Andrew Clark has been working on the IBM i platform for more than 30 years, beginning with the “secret Mankato Project” on a pre-release version of os/400, and an internship at IBM Rochester working on the Query team. He has development expertise in more than a dozen languages on multiple platforms, as well as a background in green-screen, Windows, mobile and web development. His major responsibilities included coordinating developers from four different offices in three different continents while still maintaining Architect responsibilities. He is proficient at everything DB/SQL on IBM i, and has extensive experience in the entire DevOps lifecycle.

Contact Us


Let’s talk about your project!

Speak with an expert

Customized Demo

Contact our experts