10th May 2021

Demystifying DevOps on the IBM i: What is DevOps and why is it important?

Demystifying DevOps on the IBM i: What is DevOps and why is it important?

What is DevOps?

When we talk about DevOps, what do we actually mean? What exactly is it?

Quite literally, DevOps is a contraction of development and operations.

It’s a set of practices used by developers and IT teams to speed up the development process and speed-to-market of applications.

DevOps sees the development process, not as a series of silos of different expertise, but as a team effort with development and operations taking care of the people with those skills – and of the entire process.

In the past, deployment was a complex, manual and high-risk process.

Despite being the most critical phase of the application development lifecycle, it was often only done monthly, quarterly, or even annually and as such, the scale of change would often be the cause of tension between development and operations teams.

DevOps redefines the whole process of a change request, aiming that changes go into production as soon as possible.

The DevOps Process

Taking a very high-level view, the DevOps process ensures that the changes in the software flow are as easy as possible, pushing high-quality changes back into the production environment, as fast as possible.

Basically, DevOps is the definition of your software development process.

First, somebody files an issue or a change request. That issue needs to land somewhere.

The person it lands with is part of the DevOps team.

Once they get the issue or change request, they need to do some steps to figure out what needs to change. Then they move that to the developers.

Developers don’t work on an island. They can use the team lead and the user to make sure that they are fixing the right thing.

Once it’s developed, the operations part of the definition starts. That ensures, for example, that a test environment can be filled with sufficient test data.

Eventually, it also means making sure that the deployment of that change into the production environment is taken care of without any issues.

That team will make sure that there are no locks on any objects, and take care of that entire technical process.

Why is DevOps important?

The difference between DevOps and other development processes is that DevOps looks at the complete process.

The DevOps process doesn’t only look at the development efforts, but it also looks at the other steps that have to be executed post-development.

When you keep the development process in silos, developing a new release would look separately at each different stage: one team looks at development, one at testing, and a third at deployment.

DevOps looks at the whole process from a holistic point of view.

Those three major blocks in the development process (development, testing, and deployment) are equally important. One cannot be done without the other.

The development, testing, and deployment time won’t necessarily be split into equal thirds. If you have a well-honed DevOps process, then it’s likely that the development stage will take the most time.

Traditionally, in testing, the developer would put something in test and request that somebody else comes and tests it.

This person would then perform a test, often causing a delay between lead time and testing time, and then if something is wrong, there’s a further delay as it needs to be returned to the development team to affect the change.

The developer would fix the issue and then call the tester back to test once more, otherwise, the development wouldn’t be able to move forward.

The tester may even feel that they shouldn’t have to come back next time and test it again.

What if the developers and the testers could say to each other “this test doesn’t really require my assistance”?

Testing is equally important with development, but we can automate parts of the tests to take some pressure off that step of the process.

Automation is so important in many different parts of the business and developers can spend all that time developing something to automate a process, but then don’t automate the testing of it.

Automation helps you to stay on time, it can mitigate the risk of errors.

In Unit Testing, you are able to automate the tests of software components. Once the developer has fixed something, they may be able to remove user testing by proving mathematically that it works.

By running Unit Tests, the developer can prove that not only was this problem solved but also that all the adjacent parts of this process that could go wrong with this change are still functioning too because those Unit Tests have been highlighted as green/successful.

The more you add to Unit Testing, the less time you actually have to spend on manually testing.

That doesn’t necessarily mean that testing has become any less important, but it does mean that by utilising Unit Testing, and automating the process, you can reduce the overall amount of time that your team spends on testing and maintain high quality.

Every time a fix is made, you should be asking yourself ‘can this change be tested with a programme?’

If it can, then make the programme that can test it.

If you spend 5% of development time on Unit Testing, you can build a library of little programmes that test your programme for you, and eventually, you’ll be able to run Unit Tests that test all of the important processes.

When they all come out green/successful, you can be confident to ship that change. Unit Testing gives you quality assurance and peace of mind

How do we manage the process on IBM i?

As with the IBM i, DevOps has gone through a number of name changes over the years.

From the AS/400 to iSeries to System i and finally IBMi, so DevOps over the years has been referred to as simply change management and then application lifecycle management (or ALM to give it its acronym) – and now, probably not finally, DevOps.

Remain’s change management system was first introduced in 1992, with the purpose of making the process work on the IBM i due to high demand from businesses and people requiring a better way to manage application changes as a complete end-to-end process.

From ticketing, development, support, deployment to testing, testing support, and then finally automatic deployment to production, that whole process needed to be managed.

A key difference between DevOps on IBM i, versus other platforms, is that IBM i development is server-based, so developers are working together on the same system.

Other platforms tend to have a PC-based process, whereby developers work on a copy of the system on their own PC. They pull in the source, work on branches, compile it locally on their PC, and do local testing.

On the IBM i, developers share the development environment with the rest of the development team. In DevOps, it’s all about tooling and how these tools can be joined together to make this whole process flow better and make your team more productive. Remain Software’s change management solution follows industry DevOps standards and adapts them to IBM i server development.

Though Remain’s roots are in the early ‘nineties, when requirements were completely different compared to the requirements of a far more complex IBM i world today, the software continues to anticipate and keep up with innovative IBM i DevOps solutions for today – and into the future.

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 10th May 2021.

Return to Blog