DevOps for Mainframe

In our earlier video blogs on mainframe systems, we discussed why the mainframe topic is again so hot and how we can automate support of mainframe business applications.

This time we are focusing on DevOps for mainframes.

I invited Yuliya Varonina, one of IBA’s leading DevOps engineers to enlighten us on the subject because I know she is a real DevOps evangelist. The technology writer and analyst, Mark Hillary, is with us once again to help Yuliya share her ideas.

Mark Hillary: “When I started developing code in the 90s, there was no concept of DevOps.”

When I started developing code in the 90s, there was no concept of DevOps. I’d write my code, manually compile it, test it, and if everything looked OK, arrange when I was going to move the test code into production. After that a separate operations team would support it.

DevOps comes from the combination of software development and IT operations – development and operations shortened to DevOps. It’s really a set of practices that combines the development process with ongoing operations and support.

I left coding and started writing about technology before I ever worked in a team using DevOps so I’m happy to speak to a genuine DevOps expert to find out how it works and also how can this be applied to the mainframe environment.

Yuliya Varonina: “All mainframe vendors and IT organizations already build their tools with an eye on DevOps.”

• What is DevOps?

One question but a billion answers. Some people say that it’s about cool tools, others are sure that it’s about methodology and ways of working. Another group of people says that it’s about culture and all of them are right.

Let’s imagine that you need to meet your customer’s requirements quickly, piece-by-piece and with the highest quality. What are you going to do? You will try to collaborate with your team to find the best tools and a new methodology like Agile. You will also try to automate all repetitive manual tasks to achieve the goal of your customer. 

So DevOps is a culture of automation and collaboration. It’s a set of the best engineering practices complemented by mindset changes.

• How does DevOps work in the mainframe environment?

Organizations that have mainframes are not an exception. Just like others they need automation and collaboration. All mainframe vendors and IT organizations already build their tools with an eye on DevOps.

Mainframe is a modern computer technology mixed with supporting applications created in the previous century. Mainframe developers today have a possibility to work using the best engineering practices during their z/OS code development.

We can write mainframe code using the most popular Integrated Development Environments – IDEs. The number of DevOps tools and Plugins available for the mainframe platform has been growing every day.

So currently we think that the question “How DevOps belongs to the mainframe?” is not valid, because all development teams around the world accepted the DevOps transformation and agreed with its advantages.

• How do we build DevOps for mainframe?

We built pipelines for the mainframe code inside our organization using the tools, which were available for us. We tried to integrate all of them into one pipeline. Initially, it was mostly based on IBM solutions, such as IBM Urban Code, and then we scaled to use more and more open source technologies.

Now, we also use Jenkins as a pipeline engine for some of our projects. It was not a one day decision. We started with automation of a small scope of manual operations and kept expanding. We saved time for innovation and then came up with the idea of ​​a pipeline constructor and DevOps as a service.

• What is DevOps as a service?

We talk about DevOps as a Service, when we talk about our flexible pipeline architecture. We understood that we can’t build a common CI/CD pipeline for all mainframe organizations and share it as a best practice. There’s no silver bullet. We need to be flexible enough and organize the technical part of DevOps for every organization as something unique. Because each organization has its own set of platforms, infrastructure, culture, and rules. So we need to be ready to use the integration engines, bug tracking systems, and test management tools available at a customer.

We also need to take into account programming languages, test automation frameworks, and a hundred of other issues to prepare the best technical solution. We can share the architecture we built for our organization, but we know that it should be built for each customer in a unique way, just like a children’s construction set with the same cubes assembled in a different order.

We at IBA played with our cubes for mainframe products, and now we know how we can help others take the path of DevOps. We research the infrastructure, tools, and challenges and can advise how to rethink all of these to be technically close to DevOps. We can also give advice about cultural changes, based on our own experience. I don’t want to go into detail though. As Irina said, I am a DevOps evangelist, and I can talk about DevOps for hours.

This is our third blog post in a series of video discussions on mainframe systems. Please share your thoughts about the discussion or offer your topics for future videos by leaving your comments or suggestions here.