IBM i DevOps TechTalk
Azure and the IBM i – Part 2 #16

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. Our experts today are Jeff Tickner, our CTO of North America, and Alan Ashley. He’s a senior solutions architect here at ARCAD software. If you follow our techtalks, you know that recently we did a tech talk on Azure DevOps. This techtalk expands on that and covers a few more topics.
Once again, Alan will be interviewing Jeff, so I’ll pass this over to him.

Alan Ashley – So we talked about branches. And you know that seems pretty straightforward with repositories. But Azure DevOps really offers a lot more. And I know one of the items that we want to talk about is their version of a Kanban board, and how that fits into the whole DevOps process. What is your vision of using Kanban in Azure?

Jeff Tickner – So working with our customers, we aren’t directly responsible for the task system that’s part of DevOps. So just like Jira, Azure DevOps has a complete task management system that’s very mature, very full featured, and it can be linked into the development lifecycle and you can link it at different points.
So I can link my initial branch, my feature branch to a task. And the cool thing is Azure manages that link as part of the changes. So the link is on the branch. It’s on the task on the work item. They call them in Azure. And then it just gets carried around. So if I do a pull request to another branch along with the source changes, that link comes along.
And what that means for the end user is that task, that work item is part of the request of, hey, make this change or I’m having this problem, back at the original source of the change. I need this new feature. I have this problem.

A.A. – In the way that I even see it is you’ve got this Kanban board that you now say is being updated by new versions and how they’re being handled together. So when I’m a end user and I call and saying, what’s the status of my ticket, I can even just look at myself and get the status of my ticket.

J.T. – I can clik through and see the pull request, see the actual source that was changed. Besides status updates and like, oh my request is in QA right now or it’s in user acceptance. It’s waiting for me to go review the change and say, oh, that’s okay. But if I’m a developer or a manager, I can go in and see the code changes as well.
So that’s the beauty of the integration that Azure DevOps provides is once we incorporate the IBM i into this process, through our integration at the branch level, suddenly IBM i code can be visible inside of Azure at the task level. So it can be very powerful to be able to see that. And it also can really streamline peer review.
So we talk about the pull request encapsulating the changes. If I made it an approver on a pull request, I get an email with a link to the pull request, similar to the link I get in the task. So we can have the existing task management system be messaging a development manager. Hey, there’s a pull request.
It has these changes. I can just click in and see the changes directly. The IBM i native source changes directly in the Azure interface. And that could be very useful for people that aren’t necessarily native IBM i developers. So I often say SQL that’s the common language across all platforms. So if I have a non IBM i developer contributing SQL changes, I can incorporate some oversight on that, but make it really easy.
That’s the beauty of this. They don’t have to go to the IBM i into a green screen session to look at code changes. They can see them right in Azure. So there’s that beauty right there. And what we’re talking about reviewing triggers.

A.A. – Now you’re supplying to an auditor for a compliance report. You can say, hey, here’s all the changes that took place. The auditor would definitely not know anything about green screen.

J.T. – Right.

A.A. – You know, but he’ll have all the information just straight from the Kanban board in the interfaces that are coming in from the Azure DevOps interface.

J.T. – We’re leveraging that functionality, they’re using it right now out on the other platforms. And we’re just bringing it this visibility to the IBM i development. And that’s normally the case. And in a normal enterprise customer, they’re leveraging all this functionality. And the IBM i is sitting outside looking in saying, how can we don’t have that?
Well, now you can and we can extend this. We have this pipeline that is doing our build for us. We can extend it and do automated peer review, what we call code checker or unit testing or regression testing and automate all of that.

A.A. – So in this pipeline. So that’s just the pipeline is just another segment of the larger Azure DevOps platform. And so now we’re tying into this using YAML or even their built in wizards where you can use Ant and Java projects to begin to manipulate how the workflow is going to go. I know you mentioned code checker and I know we had worked on a code checker one together where a feature is being built, and now it’s getting ready to go into the release and testing, and it’s running a code check to make sure that it passes all the rules.
And if it doesn’t pass all the rules, it stops and alerts. It says, hey, we’ve got a problem here. This did not meet quality code. You need to review it.

J.T. – Right. So if you have standards, at your company coding standards, right now most people do, but it’s very ad hoc. Oh, this is an important chain. That’s an important program. That’s a key program. I should review those changes. Well, let’s just apply that consistently to all the code changes that are made and automatically do it.
Not have to have somebody involved with it. You might still have peer review about the use of the logic or the coding. Sometimes coding is subjective. You don’t have an easy standard to apply. So the security standards are easy to apply. It’s like, hey, you can have open ended SQL. That’s easy. I don’t want you to use move() anymore or nomore goto().
Those are easy. But some of the other coding standards, might be subjective, so we can set different thresholds. And, code checker to say what is an absolute failure, like a security issue or what is just a warning and alike I did this, and obviously the customer controls the standards that are going to be applied, but you still have access to the the pull request to actually review the code.
And maybe it passed code checker, but you don’t like the spaghetti code that the developer wrote.

A.A. – Code checker is always good about finding the rules that apply, but it doesn’t necessarily keep you from creating bad code. That’s where an eyeball looking at it is still valuable. So you don’t built the spaghetti code that nobody understands. It’s going through. So we’re not taking the people out of the picture.
We’re just allowing them to focus on the important parts of the picture. Whereas they don’t need to worry about the stream. They can focus on the fish in the stream.

R.B. – Guys, let me just jump in here just for a second. Let me just back up for a second and come up about 60,000ft higher for a moment. That isn’t the key here that I mean, JIRA has Kanban boards. Jenkins can do pipelines, GitHub can host a repository isn’t the key here that Azure DevOps has all of these elements in one place at one time?

J.T. – Yes, that’s a good point. So Azure is very mature. I mean, we’ve been integrating with this tool since it was called Team Foundation Server ten years ago. And I remember longer than that. And they’ve been adding functionality just like we’ve been adding functionality and they’ve gone to Git, they used to use Source Safe, and now they use Git just like we migrated to Git, we’re kind of heading in the same direction there, go for the best tool for the job.
And so now that we integrate with Azure, we get to leverage these strengths and provide a really good experience for the customer.

A.A. – Yes. Becomes a one stop shop for all your DevOps needs within the Azure DevOps platform. And like they’re saying, at ARCAD one of the things we’re doing is we’ve worked with them for a while now through their different iterations, but we’re now bringing our tools deeper into the integration within the pipelines, within to the Kanban boards. Of course, we’ve got the Git repository part of it handled, really well.
But now we’re expanding out. We’re opening up the possibilities for customers that have Azure DevOps, that maybe only thing they use today is the repo. Now, this allows them to start to expand out and have some familiarity with the rest of the toolset, along with what ARCAD can bring to the table.

J.T. – Yes. What I find is that the customer when I’m going to a customer is using Azure. The IBM i developers are often already using the Kanban boards and then manually typing in the task ID into the IBM i for tracking purposes. And here we get to integrate right from the beginning. There’s no possibility for user error because we’re just putting that link in at the very beginning and letting Azure carry it around. And we have a consistent process that’s easily traceable. That’s the important thing.

A.A. – And the key thing is the developer can focus on developing. He doesn’t have to worry about tracking a ticket number and ensuring that he put it in correctly to get his version that he’s going to work out of all he wants to do is fix the code and write the code. This is taking that off of him or her and allowing them to do what their job is, which is develop and code and create great applications for the company. This automation takes the overhead away.

J.T. – Yes, exactly. So and the other benefit of this is that since we’re not requiring the user to manually key stuff in when to worry about developers forgetting a step not to worry about developers miss keying, we’re just tracking what they’re doing along the way as they’re doing their normal job through this integration.
And we’re extending out what we might ask a developer to do, like we talked about code checker and peer review. You know, maybe code checker and peer review is going to be used to manage the complexity. But unit testing we can automate unit testing also. So we’re doing that for a customer right now integrating our ARCAD iUnit with the Azure pipeline so that everything is automatically unit tested as part of the normal development process.
But the developer has less responsibility about the unit testing itself.

A.A. – I wouldn’t even say less responsibility as much as a guaranteed backup to him. In case he forgets to run a unit test over a particular module. He’s working in 15 modules and he’s doing his unit test. The boss calls, he forgets to run the last two. The pipeline and our integration with unit testing is going to catch that.
It wasn’t his fault. It now has a guaranteed backup.

J.T. – And the big takeaway there is as people are using more and more, ideally you’ll have recompile because you’re changing a module for example, each in your procedure in a module. And you obviously unit test that procedure, which we provide the ability to do unit tests that procedure. But all of the recompiles can be automatically unit tested also to see if they’re impacted by that procedure change.
And that could be that you have a ripple effect where you change the logic in one procedure and another procedure in another module or service program is impacted by that because it’s doing something to a variable value that the other one doesn’t expect. And so we’re going to go through and follow through on all of the objects that are in that package.
So that changes, the recompiles, we can say let’s unit test all these guys. They shouldn’t have changed. They’re just recompile us. I wouldn’t expect the developer to go through and unit test every single possible program that could be impacted by that. But ARCAD can because ARCAD knows what that list is.

A.A. – That’s a good point. I didn’t think of it that way. The developer’s focused on what he’s changing, what he’s working on, not the ancillary cross-referenced programs that he may not even know about or he could, if he were to use our cross-reference from observer, see those. But that’s not in his really his job description that day is he doesn’t need the unit tests.
So that’s a really good point that we can cover the things that get recompiled as part of that version as it’s going through the normal cycle of going from feature to release to production.

J.T. – Yes. And it’s no extra work for anybody. It’s happening automatically. The developers today are used to change management packages, helping them out with recompiles. They don’t want to manage recompiles manually because they don’t have to now. And so now we can say let’s extend that out and validate those recompiles as well.

A.A. – Right. And you know going back we’ve talked about CodeChecker and we’ve talked about looking at the quality code. We’ve talked about unit testing. Now remember this is all done with inside the Azure DevOps suite. So what we’re doing is we’re now allowing them to expand out. What’s being used. So the repository with the version information is being passed into this pipeline because they’re integrated. They can see their own variables and things like that. And then we’ve got a call in the pipeline that says, hey, reach out to CodeChecker, reach out to iUnit, run this across this. And this is all because of the beginning integration within the entire Azure DevOps suite that we can start tapping into, which makes it a nice little bundle that all works well together without having to go out and buy 15 different packages.
I need a pipeline for this. I need a Kanban for this. It all falls into the Azure DevOps, and we just ARCAD just slides right in. Mostly in the pipeline. But we do have integrations into the Kanban as well to handle some of those version releases and creating the versions of branches and things that would trickle down.
So we do have a lot of integration in there from the ARCAD side of thing.

J.T. – Yes. And again, this is what they’re using Azure DevOps for. On the open system side, we’re just bringing the same functionality that they already have. We’re bringing it to the IBM i.

A.A. – Ok. So we’ve talked about all this integration within the Azure DevOps suite. And I know bringing the i into this is going to be complex. It’s going to be hard. And I know we’ve got some expertise in doing this because we’ve worked with customers going through this. What can people look forward to? You know how complex, how time consuming might this be going forward if they begin to integrate pipelines into the IBM i and ARCAD suite tied in into the Azure suite?

J.T. – So in my experience of doing this for a few years with Azure, you normally the customer has Azure resources, that they’re working with for the open system side. That’s why they want to integrate the IBM i with Azure, because they’re using it on other platforms. And we can leverage those resources to speed up this implementation and reduce the amount of effort on the market side.
Now, those guys don’t know how to talk to an IBM i, but really, we’re making an interface to that. So we have Azure extensions for some of our tools. We have C allies for all of our tools. And those guys don’t care that, that the target is the IBM i. We’re abstracting all that. So they just have to do what they always do, which is: I want to call a command in a build script in a YAML file to do something.
And you know obviously there’s profile management etc., but it’s not as complex as you think because we’re extending out the workflow you are already using. The goal is to take the known existing workflow from the open system side and extend that to the IBM i. So we’re just leveraging the knowledge you have internally and connecting it to the IBM i.
We’re providing those interfaces not as hard as you’d think, but the more complex the workflow, the more complex the requirements, the more complex the implementation.

R.B. – Azure DevOps really is a comprehensive suite of development tools Azure boards, repos, pipelines, test plans, Azure artifacts, and more. It’s designed to promote a collaborative culture. It unites development, IT operations, quality control, and all your security teams as well. And of course, ARCAD can work with it and we have expertise in it.