1st July 2021

How do you manage the DevOps process on IBM i

How do you manage the DevOps process on IBM i

Managing the DevOps process effectively on IBM i

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

Short for development and operations, DevOps relies on the entire team working together to get software changes through development faster.

It helps you to design the entire software and application lifecycle process, from idea to change, to test and then into production with deployment.

IBM i is perhaps one of the most secure, reliable and flexible development platforms available for enterprise IT teams.

In fact, 92% of IBM i users rate the platform higher than any other server options in terms of delivering ROI – and 25% plan to increase their IBM i footprint in 2021.

 

Managing-DevOps-IBMi-Proximity-Remain-1920x800

It all starts with a change request

The first stage of the DevOps process – as with any change management – is the change request. Requesting a change – and making the change in the right way – is where it all starts.

You need a place for businesses to request changes. This can be documented in an Excel spreadsheet or Google Sheets, or in a dedicated solution. You just need a way to gather all the requirements for a change request from the organisation.

Impact analysis

That change request will then at some point land with the technical team.

The technical team needs to be able to make an impact analysis of that change.

They need to have the tools to decide whether it’s a feasible change (hint: you could investigate X-Analysis from Fresche for impact analysis on IBM i).

As an example, if a customer were to request a change to add a field to the customer database, it could be the case that this change would touch half of the application.

Using a tool to notice potential issues early allows you to potentially decide on a different strategy, instead of diving into the development and finding all these issues as you go.

There could be other solutions that will allow you to reach the same goal without having such a big impact on the rest of the application.

Coding

The next step is your coding.

Figure out what kind of development environment to provide for your developers. Even if they have always worked in the green screen, there may be other solutions and tools out there that can help them to be more productive.

Those tools could include graphical editing outlines in the application or in sources, so you know the structure of your application, conversion from old style to new style, or putting the debugging process at the fingertips of the developer in the coding area.

All these things can be improved significantly on the IBM i.

Quality control

Unit Testing

The DevOps process itself gives you quality control, with Unit Testing the preferred method.

Even just one Unit Testing program is already infinitely better than having zero Unit Tests – and they can build up quickly.

With a team of 20 developers creating just one Unit Test a week, you will have 20 in a week. 80 in a month. By the end of the year, you’ll have 1000 Unit Tests, which is a significant number.

Peer review

An alternative to Unit Testing is peer review. Instead of putting changes to test, developers can ask a colleague to compare the sources side by side and see what was changed. Just by looking at the source code with a fresh pair of eyes, quality is already improved.

In fact, just the prospect of peer review tends to improve code quality, as no developer wants their mistakes pointed out by a colleague!

Ticketing system

You can also manage the whole chain of development in a ticketing system.

If the developer has the ticket at the fingertips, they can easily mark changes as fixed.

The user who filed the request will then get a message that it has been resolved. That improves user satisfaction, as they get to approve the change before it goes into production. When users sign off on a change, the quality of the testing process will also improve significantly.

Deployment

Finally, of course, you need to deploy the changes.

Once it is tested and the user has given their final approval, any automated process can pick up those tasks that are ready to go and then deploy them in a window when it is possible.

 


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 businesses of any size to go to market quickly, with high-quality software applications and minimal bugs.

Posted by Paul on 1st July 2021.