IBM i DevOps TechTalk
Azure and the IBM i #12

Ray Bernadi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. Today we’ll be discussing integrating Azure tools with the IBM i. We’ll talk about some benefits and some key considerations. Today’s experts are Alan Ashley, a senior solutions architect here at ARCAD Software, and Jeff Tickner, our CTO for North America. Alan will be interviewing Jeff.

Alan Ashley – So many folks are coming from using Azure in some shape form or fashion, whether or not it’s Azure cloud, Azure DevOps. So we always come at it from our perspective, Azure DevOps, Jeff. Can you clarify what’s in the different suite within Azure DevOps and how it maybe relates to the other Azure’s that we hear about?

Jeff Tickner – Yes, so that’s a good question. A lot of businesses are using Azure to manage their business processes, their workflow, not just for IBM i or even software changes, but for other parts of their organization. And the thing to remember is that Azure has been around for a long time, almost as long as our kid and it’s grown used to be called Team Foundation Server, and it’s very mature and has this wonderful project management system.
And then it has source control, and they have really added on a lot of functionality to those parts. And our experience is that often the enterprise is using a lot of those pieces on the open system side, and they’re using just the task management for the IBM i development, ending up with a lot of manual steps. And so the core for us, the integration point is the source control in Azure DevOps, which is Git now, used to be source safe. And we integrate with both of those, but we integrate very tightly with get and so that means that we can bring the IBM i developers into the full cycle and take advantage of all the different pieces of Azure. You can use as many or as few as you want, which is what it comes down to.

A.A. – So, Jeff, on that topic, you mentioned Git, and I know that Microsoft which is Azure, but GitHub is not the same Git that’s in Azure DevOps.

J.F. – Yes. Very common question. People use the term Git, but then there’s these packages, these wrappers around Git. And so Azure DevOps is a wrapper around Git. And then separately is GitHub which is a wrapper around Git, and yet Bitbucket and GitLab. And there’s open source versions and so on. And so that’s a common source of confusion what are you using for your project management system. Our experiences that Azure customers are using the tools in Azure, because of the high level of integration between those tools and we’re integrating with those tools as well to provide with automated process. The open systems guys are doing it. We’re going to do it for the IBM i.

A.A. – So just to clarify that. So odds are the IBM i guys are actually already using some of the DevOps processes because of maybe the test management, the Kanban boards. That may go into play. And now we’re going to integrate the source control management aspect of things for the IBM i into Azure DevOps.

J.F. – Yes. And remember the goal here is that you have the .NET guys there commonly working on the front-end: the user interface. And the IBM i guys are working on the business logic, and the database on the IBM i side of things. And so as we use more common tools, more parts of the suite, we offer a higher level of synchronization between your front-end and back-end, which is always good. And so we’re integrating specifically with the source control and the CI/CD process in Azure. Because that’s what we do.

A.A. – So as an IBM i guy, I’m a VS Code guy. I like using VS Code. And I know ARCAD has some nice hooks with VS Code as well. But many of our the teams out there use RDi and some of them use green screens, still just regular SEU. How can I still bring my green screen and RDi to using Azure DevOps and their version of Git?

J.F. – Yes. So is the benefit of ARCAD. And what we call it, bring your own tool, is that you can use any IDE to update the code as long as that IDE is talking to Git, meaning it’s committing its changes to Git. And that’s the commonality here amongst all these packages, Azure DevOps included, is that we’re talking back to Git to deliver the changes, and the developer their level of interaction with Azure. Obviously the more they interact with the workflow, the better. But we have customers where there’s SEU users that are interacting very little because they don’t have a high level of comfort. And that’s where we end up with the gatekeeper model, where you have somebody that doesn’t interact with one of the platforms as much as others, but you can move their changes forward after you review them.
And that’s the benefit of Git itself is the idea of the branches, doing pull requests, and allowing for automatic peer review.

A.A. – A little bit earlier, you mentioned the .Net developers already using the Azure DevOps suite and various stages, to build out the front-end to the IBM i because there’s not an IBM i that doesn’t have a web front-end or some kind of client in the front. As we’ve all seen, how does bringing the IBM i developers into the suite benefit the .NET developers?

J.F. – So we do have customers that are giving their .NET developers direct access to the IBM i database because of the possibility of having a stateful process with Git, with Azure DevOps. And so it’s leveraging the gatekeeper model where we allow a .NET developer to create a new view or create a stored procedure that’s going to be created directly on the IBM i.
But, it can be reviewed via pull request by a native IBM i developer for syntax and so on. And of course, we provide the build. What’s the first threshold of coding? Does it compile? And if it doesn’t compile, we’re not going to deploy it, deploy this SQL into your QA environment. So it allows you to make everybody more autonomous, but still be able to easily review their code.
And that’s really the benefit of Git and DevOps. In a nutshell is that you give the developers autonomy to get their job done, but you have a threshold where you have a review of some kind before you say it’s ready for this QA level or production or what have you.

A.A. – So we’ve talked a lot about how the open side of things fit into the Azure DevOps world. And now we’ve talked about bringing in the IBM i team as well, bringing those into a cohesive unit. We’ve implemented Azure DevOps and ARCAD several times over the years now. What have we learned? What are some of the key factors of when you’re going to start implementing and bringing in the IBM i developers?
Are there any trends, any things that we need to be on the lookout for? Because we all know in IBM i workflow, it doesn’t necessarily fall into that DevOps process today.

J.F. – Yes. Exactly. So that’s one of the challenges. I always say, when a customer use your in-house subject matter experts, you don’t have to have us do everything. So if we’re going to be using the tools that you’re already using, which is what I always propose, you already have SMEs in-house, you have Azure DevOps engineers or admins, that have some understanding of the tools there.
But the problem is their understanding of the use of the tools in the context of the open systems world. And one of the most common points where we have to get it across that IBM i’s difference, is the full build versus what we call the Delta build. And what that means is on the open systems world, especially in .NET, you build the whole project. So you commit your changes and then you might change ten source members, but you compile everything and you probably are exporting a binary. And meanwhile on the IBM i side, we want just the changes. We don’t want to build 10 or 20,000 members, never mind the time. So we want to build just the objects that are changed and of course, anything that’s dependent on those changes. And so other thing we’ve learned is, it’s pretty common on the Azure side to have static branches or environment branches where you have a QA branch and they commit their changes to it and then build the QA branch into QA.
And we’ve learned that to manage just the changes, the delta changes, we want project focused branches. So I might have a big project like field refactoring or what have you. And I might have small fixed projects like PTS. And it’s really hard to manage those in the same branch because they have a different cadence entirely. And so we always push on multiple branches, more dynamic branching.
And meanwhile the .NET guys, the Azure DevOps folks are more focused on static branches because they’re building everything. So we have to make that case. And sometimes that’s where the difference in the workflow is. We’re all going to go to QA, but how we’re going to get to QA might be a little bit different.
And we’ve learned to accommodate those differences and explain those differences, and help with how our pipeline might be managed differently when the branch is a different one every time versus you have a static developed branch or a static QA branch, or your build main and push that to production. So that’s kind of the difference in culture there. That can be a challenge.

A.A. – It sounds like we have some nice history on the experience on bringing this in there, but also knowing that a customer, when they do this integration and then bring the IBM i team in, that there’s going to be have to be some education on both sides of the platform, whether or not it’s IBM i side on the open side, so that everybody understands how the integration is going to play out in the end, just so the enterprise can be successful. And it does sound like we have the expertise to really help ensure that’s going to be a successful transition.

J.F. – Yes, we always encourage our customers, the IBM i developers to get some Git training. But the challenge is to Git training that’sout there is normally in the context of the open systems world. So they get the core concepts, but then they might get surprised and how we’re going to leverage those core concepts.
But because of our experience, now we’ve been doing this for a long time, we can explain why we’re doing what we’re doing. And that’s one of the benefits is that our audience is technical: the admins, the engineers, and the developers. And if I can explain the mechanics behind it, they can understand it and accept it.
So that’s the benefit. And sometimes that’s the learning curve for everybody. And we’ve learned it’s very important to get everybody comfortable, and not just push stuff, but also show the IBM i developers the benefit why they’re learning these new tools and show the open systems guys what we’re doing for the IBM i guys and what that integration is going to bring to everybody. Because really it makes the whole organization work better by integrating them together, by synchronizing the changes where it makes sense.
And that’s the point of DevOps itself is to bring everybody together. But we do have to overcome those cultural differences that people are starting with.

A.A. – Thanks, Jeff. When you go down these DevOps kind of roads, it can just go into so many different directions. And I know we’re not talking and thinking, oh, we’re only talking about the Git side of the Azure suite. We really didn’t even dive into the automation behind using maybe some of the pipelines in integrating your Kanban boards into your task management, into your pipelines, and how all that still integrates with your IBM i.
Which I think that’s a podcast in and of itself, where we kind of dive into some of those other parts of the suite, that can really benefit the IBM i as well.

J.F. – Yes. And that’s the interesting thing is that a customer can use a small part of that, that automation and integration, to meet their requirements. Or they can dive in with both feet and really leverage that incredible functionality. All of our tools, all of our testing tools, code scanning tools, etc., integrate in with Azure Pipeline.
Some of them even have extensions, to make that integration easier. But like you said, we could do another whole hour long talk about that integration with, the Azure pipelines and their CI and CD processes.

R.B. – Thanks, Jeff. Thanks, Alan. That’s a lot to take in. But the key point here is that even though IBM i developers differ from open system developers, they can work together with Azure and Git. Open system developers are used to continuous integration and continuous deployment using tools like Azure and Git. The IBM i is no different. More and more businesses are using Microsoft’s Azure Tool suite, and with ARCAD’s help, the IBM i can fit in seamlessly.