• September 22, 2019

Modern DevOps and the IBM i

As I travel around the world visiting with IBM i customers and discussing the challenges around managing a modern development environment, I am increasingly hearing a common refrain: “My company wants us to manage all of our development with Git.” It is completely understandable. Companies would like to have a single repository for all their source code. They want to be able to take advantage of Git’s powerful branching and merge capabilities. Most importantly, they want to allow new engineers to work with a tool with which they are familiar.

Immediately after they say they want the source managed with Git, they go on to say that they want automated DevOps with continuous integration, automated builds and on-demand or automatic deployments. Typically, these initiatives are being managed by people who have little knowledge of the IBM i. The tools they want used are typically Jira for issue tracking, Jenkins for continuous integration and builds and Puppet or Chef for configuration management and deployments. The problem is that none of those tools have the IBM i domain knowledge that is built into most existing IBM i change management tools.

For example, Jenkins requires that you provide it with Make files that identify the build dependencies for your application components so that it can build properly. Most IBM i change management systems provide that dependency information automatically. They discover the dependencies and use that information to ensure that all of the appropriate objects (and only the appropriate objects) are created when you need to do a build.

In the open source world, users are just beginning to move to continuous integration. Yet, in the IBM i world, we have ALWAYS done continuous integration. When a developer commits a change, the change management system typically creates all the objects necessary and deploys them to the appropriate target environments. As long as the developer has those environments in their create and execution library lists, they will be working with the latest version of the code.

Trying to recreate the automated DevOps already provided by IBM i change management tools requires a significant amount of scripting and day-to-day management. So, why not get the best of both worlds.

Getting your IBM i source into Git allows you to have a single repository that includes all your source, across all your platforms. You can branch the code together. Tying your IBM i promotion and build process together with Jenkins builds for non-IBM i code allows you to synchronize your promotion and build process across platforms. You can still use your existing IBM i change management solution to manage the overall process across platforms while taking advantage of the open source tools for managing and building your non-IBM I code. Meanwhile, you can manage all of your programming tasks across all of your platforms using popular issue tracking tools like Jira.

By integrating the solutions with deep domain knowledge about the IBM i with new, powerful open systems tools, you can get the best of both worlds. You get highly automated, auditable processes that cross all the platforms and technologies involved in modern application development. If you would like to learn more about modern DevOps and the IBM i, check out the Rocket Webinar on November 27th.

Dan Magid

Dan Magid 25 Posts

Daniel Magid is VP of Solution Sales at Rocket, and is a recognized authority on helping leading organizations achieve compliance through ALM solutions and DevOps best practices. He has written a variety of articles for leading IT publications and is a regular speaker at technology conferences.


Leave a Comment

Your email address will not be published. Required fields are marked *