The Future of IBM i+ CI/CD: In a state of forced change

July 19, 2023

When organizations were first developing on IBM® i, the work was only RPG, native, green screen-based development in a linear, waterfall method: code, compile, test, deploy, and after months of work, release. Development was still decades away from anyone suggesting agile development, let alone implementing the practice. There were no mobile phones, no internet, no cloud. Even when the rest of an organization was beginning to adopt agile development in the 2010s, IBM i teams held fast to their waterfall approach. After all, it worked well for them; and while the storm was brewing, the teams were not yet feeling the pressure to change.

That time is long gone.

In this blog series, we’ll discuss the changing trends in IBM i+ development cycles, including a look to the future and guidance on how you can set yourself up to take advantage of new trends like process discovery and intelligent testing.

Over the last five years, IBM i teams have been expected to perform like other DevOps teams. That means:

• Agile development cycles with fast response times to market and customer needs and quality code in a multi-code environment.
• DevOps is becoming the standard, which means close collaboration between development and operations/IT for better visibility across the entire development and deployment process, tighter controls of sensitive code and data, and more.
• Coordinating with another team—for example, Java developers—across the DevOps process; otherwise, the IBM i developers would also have to learn how to be Java developers.
• They have new stakeholders. IBM i no longer lives in silos and is being pulled into new workflows and UI/UX.
• Organizations are recruiting younger developers due to development skill gaps on IBM i—and these developers have a new, modern view of what development looks like, what tools they need, what the methodology should be like, and more.

Many IBM i developers are entering retirement age or have already left the labor market. These are the developers who have a deep knowledge of the applications, how they were built, and the business logic behind them. Unfortunately, there is very little documentation left behind. Without documentation, teams are often guessing what they should build—and, by extension, what they should test. For example, let’s say you have a customer service representative “enter new customer profile” workflow that is automated with new APIs.

What exceptions do you test to make sure the API is working as intended? With modern development and API technology, you can simply go into “add customer profile program” and let it do its thing. The developer would understand the code and see what it was doing. Because developers working on updates don’t know the code, they won’t know if the API should be calling other programs or if the code is calling other programs under the covers.

The Future is Bright

As an IBM i owner, you’ve accepted your fate. You need to be agile. You need to work with modern toolsets. You need to extend a hand outside your immediate team to the rest of the organization. Modern DevOps is here to stay—and that’s a good thing. It reduces time to market, increases enterprise agility, and makes businesses more resilient.

One of the current trends is continuous integration/continuous delivery (CI/CD), which enables DevOps best practices and benefits more than other approaches and allows DevOps teams to work faster without compromising quality.

Continuous integration is the practice of continuously integrating new features, functions, and UI into applications. For example, a Microsoft developer making a change to Word would write code and then use continuous integration to integrate it into Word somewhere, allowing it to be tested while other developers are doing something else in tandem.

Continuous delivery is about sending code when it’s ready and needs to be tested as an application at the site/server. The test is to see whether it fails within an environment with a specific combination of servers, OSs, applications, and configurations. The developer pushes the code to the testing team, who then delivers it to the environment for testing. There are versions of the applications that are created so developers can send them when their code is ready, not when everyone’s code is ready.

Continuous deployment is about pushing new changes or codes that pass through to production and to end users who ultimately provide feedback. This happens post-test and is sent based on a release schedule, which can be continuous, every x number of minutes, or some variation of an agile deployment cycle.

Once that continuous loop is set up and CI/CD is achieved, organizations have more freedom to innovate and experiment with process, technology, and tools, setting themselves up to be more competitive in the market.

However, there are two important parts to making CI/CD work:

Automated Testing

Without it, the cycle slows down, and the potential for errors entering production increases. Can you get quality code released to the market quickly so your teams can get the feedback they need and fine-tune their applications to fit what the market wants?

The Right Toolset and the Right Implementation

Do you have the right tools, configured and leveraged in the right way, to support and accelerate your CI/CD approach?

Throughout the remainder of this blog series, we’ll be focusing on the automated testing component. And stay tuned for the next post in the series on process discovery.

Learn more about the future of IBM i+ CI/CD and read our whitepaper or talk to an expert today.