19th May 2021

Benefits of DevOps on IBM i

Benefits of DevOps on IBM i

What does DevOps provide for your IBM i development team?

The cultural change of removing silos

The main change with DevOps is the cultural shift of removing siloed working teams.

DevOps is a dialogue process: A business files a change, then a team assesses it and moves it onto the developers to develop, who then do an impact analysis. They do the changes and then the next step is quality control, which is made up of three parts: unit testing, review, and end-user testing. Then the final step is deployment.

DevOps aims to make that process as smooth as possible. The two ways this is achieved is by moving the change back into production as quickly as possible, and by making the process as automated as possible. The goal of DevOps is to design a process that will achieve that aim.

Everybody on the team is always part of DevOps – and should always be considering what they can do to make the process even better.

Developers develop.

Testers test.

Operators operate.

So, when something goes wrong in the deployment process and the team doesn’t know what was programmed wrong, they have to roll back everything because they can’t fix it. They have to wait until Monday when the developers get back to fix that issue, and then they have to wait and try it again the next weekend.

DevOps tries to avoid that, by removing those silos of expertise where possible.

In DevOps, the developer is equally as responsible for the deployment as the operator, so when the operator has to do the deployment on a Saturday, they need to have support from the developer in case something goes wrong that the operator cannot fix. They are both responsible for the process.

That can be a big culture shift.

In another example, when a developer wants to change a programme and it is just sitting in a test because nobody is testing it, the developer might complain about that – but in DevOps, they are also responsible for the test.

If the test does not flow, in the DevOps process, the developer should chase the test. The whole team takes care of each step. If a developer can’t develop, then they have to test. That means that testing has to be set up in such a way that it’s easier for people to test, to make the process flow better.

What is involved in implementing DevOps?

It doesn’t matter whether it’s on the IBM i or any other platform, DevOps implementation requires a cultural change within the I.T. team, and collective responsibility for that, with everybody playing their part in the DevOps team.

First, you must figure out what parts of the development process aren’t working.

A common example of this could be that the testing process is so involved that it hinders development progress. This slow testing process is often accepted as a given. If you only go to production once a month, it makes some sense that the test will sit there for the rest of the month.

But that can then cause issues for developers – say they want to make the next change to a source that is currently in test, then the developer will have to retrofit the change, which can be difficult.

With DevOps, once an issue is fixed, why not move it to production? If it’s a small change with a small risk, then it probably won’t even disturb the user.

That’s a change we can make easily, but there may be some resistance at first. The old way of doing things may be “just the way it is”. It may be that a development process was first implemented in the early ‘90s in which case, the people who invented it may no longer even be in the company. The people that are now implementing the process are only doing it because “that’s the way we’ve always done it”.

DevOps is more of a continuous development and deployment strategy. In our example, the first thing to do, when implementing, is to see how quickly you can put a change in production and then to just put changes straight into production, going forward.

Things to Consider

One of the first things to consider is to look at what the process is now, and identify where the irritations are in that process. Step back and analyse to find out what people are complaining about most. Where are the bottlenecks in your process? Do you want to accept these bottlenecks as a given or can you actually change that?

In the DevOps process, we would try to find steps to fix these issues, with workflows for these scenarios.

As an example, it is often assumed that the bigger a programme is, the more changes will be required. But is that actually the case?

In an application that consists of 5,000 files, programmes and display files, there may only be a dozen of those that are core programmes, where everything is happening. Those core programmes grow and grow as more code is added – because they are in the centre of that application. As they grow, they also become more complex, to the point where nobody really understands them anymore.

Because they are core programmes though, any change made will usually contain one of those programmes.

Everybody wants to change the core programmes for their specific change request, which makes the development process harder, as developers have to fight for access to the programme. One developer may have the source to make a large change, which would typically involve a lot of other programmes. But on the IBM i, while that programmer is working on it, other developers usually can’t access it.

This is one of the problems that can be fixed by looking at it from a DevOps angle.

Simple Steps to Setting up DevOps

Once you have accepted and identified those bottlenecks and the need for change, you’ve already started to implement DevOps. You can get insights into how a problem can be approached in a
different way. Even simple solutions will help you improve your process by a significant amount.

Continuing our example of those big core applications, that everybody is fighting for to do a change.

First, the developer has to do the change in isolation. If the developer on task 1 is doing the change in isolation then developer 2 on task 2 can also do their change in isolation, independent from each other.

If this is working, then we can also do the test in isolation. If task 2 is a small change, then it might jump to production straight away. Developer 1 on task 1 now has to retrofit their copy of the source to include the new changes from production. This can be done without fear because the change on task 2 is the newly tested production version.

Learn more about DevOps & IBM i:

About Remain Software and TD/OMS

TD/OMS is a collaborative multi-platform software change management tool from Remain Software. It follows industry DevOps change management standards, adapting them for DevOps on IBM i. TD/OMS supports change and application life cycle management on IBM i, from development and testing to acceptance and deployment. TD/OMS  enables business of any size to go-to-market quickly, with high-quality software applications and minimal bugs.

Posted by Paul on 19th May 2021.

Return to Blog