IBM i DevOps TechTalk – Getting Started with DevOps #4

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with our Arcad experts. Today we’ll talk about what DevOps is and how you can get there. Our experts today are Andrew Clark, he’s our DevOps product manager and Alan Ashley, he’s a senior Solutions architect. My name is Ray Bernardi. I’m also a solution architect here at Arcad Software and I’ll be your moderator today.

R.B – All right. Thanks for joining us here today. So, Andrew, why don’t you start for us? Exactly what is DevOps?

Andrew Clark – Thank you, Ray. So DevOps, really, there’s a lot of complicated explanations for it, if you look at on the web. But really what we’re talking about is DevOps is a way to take manual processes that you’re doing today, things that people are doing, running certain kinds of scripts or just clicking buttons on screens and turning that into an automated stream of actions.
So once a certain thing happens, all of these actions are kind of triggered on the back-end by certain tooling or processes The really idea is that you want to eliminate the need for people to do manual work that they don’t frankly want to do. Both developers and QA in many cases, both the dev and the ops side of DevOps: things like filling out forms or going into meetings to explain why certain things aren’t working or why certain process is broken and automate that in a in a cycle so that basically the computer is checking those things for you. And the end result is that you get quicker releases, smaller releases to the users with better code quality and the most important thing is actually at a lower cost.

R.B – Now when you say smaller releases to the user, we already took that step with Agile, didn’t we? Or is it even beyond that?

A.C – Yes, there is a difference between Agile and DevOps. So in Agile, there are small incremental releases, but you only do testing at a certain point. So you do small releases, but you kind of build up all of the testing into a bucket and then at some point you test that entire bucket all at the same time.
In DevOps, what actually happens and I’ve got a little chart for it, but no one can see it, is you actually do not only the coding and the testing, but you also do the deploy all in the same step. So Agile builds up a bunch of these little releases and then you run the tests all at once and then you deploy at the back-end of that whole thing.
In DevOps, you continue deploying. So that’s the difference is you’re continuously deploying as everything passes to test case, it just goes right into production. So that’s really the difference between Agile and DevOps.

R.B – All right. So that covers what is DevOps. So why DevOps? Alan, you want to start here?

Alan Ashley – So this goes back to the old return on investment. There are calculators that are out there because what is every business decision made on? Money drives the decision. And so when you start looking at why DevOps, you’ve got to look at what is your return going to be? Now Andrew, as a developer, how can working through and maybe on this ROI calculator with your business team, how can you start to DevOps out of that?

A.C – The biggest thing is that again, this is what we call shift left. So, the important thing is that you can find defects, you can find issues in new code or in fixed code, any kind of change code as quickly as possible. So as a developer, you don’t want to push a change that has a bug in it.
Obviously, when you’re making a change, you don’t think there’s a bug, but if you don’t run any test cases, if you don’t thoroughly test your application, then someone else is going to have to find that bug and it complicates the process. It becomes very expensive because not only is it taking up your time, but it’s taking up a QA resource time.
Plus also, whenever you move something within the cycle from development to testing, there is different people and just different processes involved. So that’s slow and there’s often some kind of manual process. And that’s what I talked about before. There’s some bug. So I got to fill out a form. I got to contact the developer now. This is the QA person I’m going to contact, the developer, and find out this is the bug. And then the developers will be like, oh that’s a bug. So I’ve got to check off my little checklist and then I got to pull my code back. So it’s a huge manual drain of time for someone to catch something that a machine could be checking.
That test case could have run automatically or the developer even could have run it from within his own development workspace before it even got to that human being that’s running their test cases as well. So why are you going through all these manual processes that cost time and money when you can have a pipeline that does all that checking for you automatically?

R.B – So this is what DevOps is really about: automating and making these that shift left and finding this stuff early.

A.C – Yes. And not only is it early, but the other thing is that no one wants to do the manual processes. I mean if your pipeline can check it and find that, then you’re not wasting time filling out forms or getting on the phone and trying to track down Joe who’s out to lunch or whatever.
So, I mean no one wants to do any of that stuff. Coders want to code and QA people want to do exploratory testing. They don’t want to sit there and follow a script and push buttons like monkeys. They want to do original things. They want to use their brains and manual processes kill all of that. It kills developer productivity, kills QA productivity. And the bottom line, like Alan said, is it just costs you money. The biggest thing that a lot of people don’t realize this is DevOps. A lot of people in the IBM i world dont’ realize that DevOps is almost an old science at this point. It’s been around for close to two decades and 60% of the I.T. world is what they consider high or elite performers.
That means that they’re doing multiple deployments either per day or per hour, and their entire DevOps pipeline. So all of their testing is close to or at 100% automated. And when the IBM i people see that and they haven’t even started down that DevOps path, they realize how far they are behind. And the biggest point is even in this IBM i space, there’s other people.
We have customers that are doing that and our competitors are doing this. They’re not wasting all that time on manual processes. They’re saving that money and reinvesting in other projects. You’re following behind the curve when you’re not doing this. Every day that you’re not doing DevOps, you’re losing money, you’re losing productivity, you’re losing competitive status.

R.B – All right. So we talked about what is DevOps and we know why DevOps. So how do I get to DevOps?

A.C – That’s a great question. And that’s one of the things that I think stops most people is that they’re worried about how to start it. And I think, Ray, you said this before, the hardest part is really just taking that first step. So deciding that you’re actually gonna go down this path is often the hardest thing.
The very first step isn’t really difficult. It’s just collecting information. So you need to figure out your existing systems and if you are anything other than a one or two person shop, you probably have both IBM i developers and open systems developers, people that might be doing Java or PHP or some other language like that. And I bet that those other people are probably doing some kind of DevOps process, maybe not a full pipeline.

R.B – They already have that mindset though.

A.C – They already have that mindset. And what you’ll also find is that people fresh out of college younger developers will 100% have this knowledge. So that will be burned into them from the very beginning. That’s their culture.

R.B – They grew up in this culture.

A.C – The culture they grew up in. It’s just assumed. Even if they were hobbyists at home, they understood this entire process because it drives the world. The whole DevOps process is kind of really actually driven honestly by Linux. And that ecosystem drives the most popular operating system in the world for web development.
It’s all based around kind of this DevOps cycle because there’s millions of people involved in it. So anyway, the biggest thing though is they’ve got that mindset and you probably have that experience and knowledge somewhere already in your company. Leverage that, take advantage of it.
There are sometimes where the workflow for the open systems is different from the IBM i but a lot of times they have great knowledge and they’ll have great ideas. And they can share that knowledge. And if you can figure out which tooling you have and an existing workflow and you need to really establish the culture of your different silos, your IBM i developper, your RPG developper, and your Java developper actually working together.
That’s kind of a mindset change and a cultural change that’s important to kind of agree on so that you can before you even move forward, agree on how you want this process to work. You can get some technical details about different repositories in the back-end and all those kinds of things and build systems.
And you can get all that. And then and that actually is kind of a great first step just to bring your different teams together.

R.B – All right. So we’ve covered a lot of ground, but we’ve talked about automation again and again. What kind of tools are out there? Can Arcad help with some of these tools? Alan, Andrew, you guys want to cover that?

A.C – Yes, absolutely. I want to reiterate again that it’s not just tooling that we’re talking about, but really the mindset and the process. That’s an important critical first step. But the tooling is important, too. And obviously, if you can consolidate your tooling across your IBM i and your open source, you’re not an IBM i project, that’s really important. So in the DevOps space, the big tools that you think about are Git for source control. And if you have a ticket or issue system, obviously JIRA, and Atlassian is a huge tool which is linked with Bitbucket, which is kind of the Atlassian version of Git. We have many customers that are using that tooling and GitHub obviously both on prem and cloud based GitLab.
GitLab has a partnership with IBM, so there’s a real good relationship. You can actually run GitLab on your power systems, the same system you’re running on your IBM i. The other big one we see a lot is Azure DevOps, Azure Pipelines. So we have integration with all of that tooling as well as tools like SonarQube and Sonatype.
So those are things that actually check for code defects. So make sure that your code doesn’t have any kind of vulnerabilities in them and any kind of exposure. So that’s all part of the pipeline. So those are all tools that are out there already that you may have heard of. And we’ve got integration with all of those.

A.A. – And, you mention all these tools and we can’t be remiss without mentioning how Arcad works with every tool that you mentioned through some shape, form or fashion. For example, you mentioned SonarQube. We have ties in do our testing with CodeChecker so we can slide right in there and help from that aspect.
But each area that you talk about, whether you’re a GitHub or GitLab shop or and as you shop, one of the things that’s behind the scenes that you don’t hear a lot about is you have to build it. And this is really where Arcad comes in. We have the ability to take what has been done and adopt different approaches.
Was it a push out or was it a merge that triggered an event? This event talks to builder and builder and make sure that your IBM i code guest developed correctly.

R.B – Because Git has no idea what a physical file.

A.A. – Yes, it’s a text. I think somebody said it’s basically a text file to Git. That’s all it is.

A.C – Yes. Now the biggest thing for the IBM i guys this seems obvious but for the non IBM i guys, it’s a completely different world. And most of these systems are designed around non-IBM i. And you can’t do a build for IBM i objects without doing it correctly. So on the IBM i has unique characteristics that are completely different than every other platform.
All the Java guys and that .Net guys will just have no idea what you’re talking about. On the i, you first have to create physical files, then worry about reference files, modules, service programs, views and finally logical files.
It’s just all of these layers that are really complicated. They have to be done in a certain order that I can get my script in this.
You’ll be writing it all out by hand. You’d have to figure out all those relationships. If someone added something new and you forgot about it, you make file. Your script isn’t going to work anymore. The magic of Arcad lies in the fact that, whatever changes you make, you can never forget something, or lose something, or propagate something and cause a level check that would bring your production system to a halt, because Arcad checks all this automatically.
And that’s really the beauty of it. No matter what tooling you decide to use, you’ve got to have something that really understands the specifics of the IBM i and ARCAD is the only tool that has that integration level throughout the entire DevOps line. We’re talking about the CodeChecker and the i Unit and the ARCAD Builder.
All of these things and even the deployment step is crucial. In every other platform when you do a rollback, you’re just talking about deleting files or moving files to a different director. And IBM i, you can’t do that. You got to you’ve got to extract them in the exact reverse order. You’ve got to pull out the logical before you can do the physicals, all those kinds of things.
So it’s each step in your DevOps pipeline has to be completely IBM i aware. And that’s where the ARCAD magic really comes in.

R.B – Thanks, Andrew, and thank you as well Alan. I think we could probably sit here and talk about this all day, but that’s all we’re going to have time for today. So thanks everyone for listening. And for more information, please visit our Web site at www.arcadsoftware.com.