Built-In DevOps Tools for IBM i
Many organizations are resigned to the belief that there’s no way to integrate their IBM i environment with the DevOps tools they use on their Windows, Linux, and Unix platforms. But these organizations are working from an outdated playbook. Today, IT and R&D teams can run the latest open source tools like Git and Jenkins on IBM i. Some organizations even go so far as to store all their source code—including RPG, COBOL, and CL source—in Git.
Functions like continuous integration and continuous deployment (CI/CD), process enforcement and workflow automation, and audit and regulatory compliance have been part of IBM i DevOps solutions for decades. Sure, version control tools like Git and Apache Subversion offer the latest modern functions, and build tools like Jenkins and Bamboo are also known to be very powerful. But as distributed systems users were still figuring out how to string together full-fledged DevOps, IBM i DevOps solutions users were already making good use of all that functionality right out of the box.
DevOps Approaches: Distributed Systems vs. IBM i
From the beginning, IBM i was particularly well-suited for DevOps because, while distributed systems users typically think of software change management as a version control issue, IBM i users have always looked at it as a process management and automation issue. I’ve met many Unix/Linux developers who are surprised to learn that IBM i DevOps tools typically handle builds, dependency tracking, promotions, and audit tracking out-of-the-box.
Meanwhile a tool like Git only really handles one aspect of the DevOps process: version control. This isn’t a knock against Git—quite the opposite, as Git is one of my favorite open source tools. It’s very good at what it does; it just doesn’t handle builds, promotions, or deployments, and it doesn’t track dependencies.
The limitations of tools like Git help explain why developers in the distributed systems world are so used to stringing multiple tools together to create an end-to-end DevOps chain. It’s also why it comes as such a surprise to those new to the IBM i world that there are native IBM i tools designed to do not just version control, but all the other DevOps functions, too.
Out-of-the-Box DevOps Functionality
Change management users on IBM i know that when they promote a change to a testing environment from the developer’s personal library, everyone who has that testing library in their execution library list will immediately see that change. Since everyone is always working with the latest committed changes, this is true continuous integration.
To get the same result in a distributed system, developers would need to first commit their change to the version control repository. Those changes would then need to be replicated to a master build repository and then the source code would need to be extracted and built. Furthermore, the entire application must typically be built each time (rather than just the changed objects and their dependencies), because distributed DevOps tools don’t typically track or handle object-to-object dependencies.
By comparison, most IBM i change management tools include automated deployment. Once the code has been approved for promotion, the system automatically deploys the appropriate objects to the required testing or production environments and installs them. In the distributed world, this requires deployment tools and scripting for automation.
Wrapped around all this functionality on IBM i are tracking functions. This makes it easy to create audit reports of the history of every change and how those changes made their way from request to development to testing and into production. Meanwhile, since DevOps on distributed systems requires multiple tools, there is little-to-no holistic reporting on the process. Users need to look at multiple systems to understand what happens in the life cycle of even just a single change.