IBM i DevOps TechTalk #24
Concurrent Development

R.B. – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. The topic of discussion is concurrent development. With me today is Alan Ashley, a senior solutions architect, and Jeff Tickner, the CTO of North America for ARCAD Software. I’m sure you know that in today’s fast paced development environments, the ability to support concurrent development is essential for agility, collaboration, and continuous delivery. Now, when we talk about the IBM i platform, traditionally we’re talking about monolithic and sequential development workflows. However, adopting a modern version control system like Git can be transformative. In this discussion, we’ll explore how Git enables concurrent development on the IBM i, allowing multiple developers to work on the same codebase simultaneously without stepping on each other’s toes. So let’s pass this over to Alan and we’ll get started.

A.A. – All right. Thanks, Ray. So, Jeff, we’re going to talk a little bit about concurrent development, parallel development and we’re going to go into talking a little bit about some of the advantages and the strengths of maybe using Git to handle that process of concurrent and parallel development. But I think we need to start off with where concurrent development may reside today from our older workflows.
You know somebody coming out of monolithic development, parallel development and concurrent development, they are pain points with customers. We hear it all the time that it’s a pain point, but most of them are coming out of this monolithic waterfall flow, and they’re starting to look at using Git for this, because they’ve heard about Git and they’ve heard about how it handles concurrent development and things like that. So can you give me just a little bit about concurrent and parallel development as it sits today?

J.F. – Thanks, Alan. Yes. So I’ve been working in this industry for a long time, over 25 years. And all change management packages have tools for managing concurrent development. And where it becomes a pain point is, besides that monolithic development that IBM encourages to do a long time ago, where you have these big programs to do a lot of things.
The challenge that the traditional change management packages have is they don’t have visibility to the lines of the code. So they certainly have tools to manage concurrent development by enforcing communication; Oh, somebody’s already changing that. You have to take an extra step before you can also change it. And then when you’re ready to promote that, you have to acknowledge that there were other changes out there, but they can’t really see what the other developer did.
Did they actually merge in the code? And that’s why ARCAD integrated with Source Control ten years ago, because we didn’t want to write it ourselves. That already existed. And we got that visibility to the code and that visibility of the code, the lines level changes is why Git can do some of the cool things it can do around that concurrent development process.

A.A. – So when you start talking about this concurrent development and start talking about maybe using Git, it is around some of their workflow has their workflow practice going to go, how are they going to handle some of this development? And I know the Git offers a lot of advantages to this. And one of the things is and I want to point this out, is we use Git as a common term, but there’s Git and then there’s the vendor wrappers, the Gitlab, the GitHub, the Azure DevOps, the buckets that add function and features around that native free Git that you can see on the internet and just install and use.
But it’s missing some key features like pull requests, which are in the native. So you have to have something like a GitHub and and Gitlab to handle pulling things together. And that’s one of the things I want to ask you about Jeff, is, if a customer is looking at going from their current development packages, because we know all the vendors handle this in some shape, form or fashion and including our head, we handle it today.
If a customer is looking to go to Git and use a GitHub or GitLab or something to that effect, how are the pull requests and the merges going to impact or affect their workflow?

J.F. – So yes, Alan, that’s a really good point about the pull requests there. The merge is a native function of Git. But issuing a merge command on the Git command line. And it worked. You have no visibility. You’re not leveraging that visibility. And GitHub invented what they called social coding. And in turn, the pull request to allow developers to interact before that merge.
What am I actually merging into. What are the impacts of that and one of the big things, is there going to be a merge conflict before I attempt the merge? And merge conflicts don’t happen that often. That’s changing the same line in the IBM i, especially in monolithic programs, we have lots of non conflicting merges. You just go fine. And of course that’s part of the workflow. So we want to leverage workflow to allow us to make sure that we have this great merge tool now that’s I don’t have to manually merge every single concurrent change. But I want to make sure it works. Just because it merges doesn’t mean it works great.
So in our workflow for our customers, if they’re going to be doing concurrent development, we want to make sure that they’re using the pull request feature that they’re merging and then immediately building or compiling the code. And then they want to promote into test. And that’s the other beauty of git is that the interactivity with other tools like automation tools that allow me to say I did the pull request. Good. Merge it. And it’s like kicking off a promotion. It’s going to build. Does everything compile, do all the dependencies compile and boom, it’s deployed to test because I have to test it now. And that’s a critical part of DevOps is leveraging the automation. And, yes, we’re giving you this much, however much higher level of visibility to the code changes.
And now let’s also leverage the automation possibilities.

A.A. – And I know that with this workflow, and we hear the workflow a lot as it comes into this, because that’s going to be kind of the key to driving the DevOps flow of your development, of your pull request of your deployments on repeat and driving that through there and using that automation. And we’ve had other talks about where automation comes in to this.
And that is a big function. In fact in this because without the automation there’s so many manual steps and things get missed. But I do want to highlight one thing you said, Jeff. And this kind of drives at home is when you’re doing these pull requests and putting these different changes to the same file together. You do the build, do the test again, because you changed line 50 and I changed line 1000 are changes together may not work. Independently they’re totally fine. Separate together, they don’t work because it’s like why wasn’t that a conflict? Well his line 50 mine was line 1000. They weren’t even close to each other.
And you’ll see that probably more I’m guessing here is in monolithic code where you have these huge programs, and that’s where you’re going to get a lot of concurrent development. Today we’re trying to go more modular, kind of quick hit programs that do a function that gets called by the programs. You probably won’t get as much concurrent development on those.
But not everybody is totally modular today. So going into kind of a closing here, what does ARCAD do with this concurrent development using Git?

J.F. – So we try to leverage the Gitflow principles that again GitHub really reinforces in any package, all of the packages have some type of pull request or merge request. And they all want you to use what Gitflow or hierarchy of branches. So you have an opportunity to merge changes together before you go to production
That’s a key principle. There is that you’ve made this process easier to do. So let’s make sure we leverage it and then identify any kind of problem before we go to production. “Shift left” another tenet of DevOps. Let’s try and identify problems early on. Even if you can’t have a bunch of test environments like the open systems folks because of resources, you can merge branches and promote again into the same test environment and retest and make sure if it works.
Otherwise, you’re pretty much testing in production. And you know that’s not a good idea. You don’t want to promote something over the weekend and find out on Monday that it might have merged okay, but it doesn’t actually work. So, let’s leverage this, leverage the automation, leverage the visibility, and not have problems monday morning.

A.A. – Right. And I do want to point out, even though some customers are using Git, many are still not making that move yet. Most will probably end up there at some point, but some are not getting there. And with this concurrent development within ARCAD without Git, we do have functions around that to help that and make that a little bit.
I guess you could say use the advantages of ARCAD to help with concurrent development so that you can start to see some of those changes.

J.F. – Yes. And really, just like other change management packages, ARCAD is about any concurrent change is an extra attention action in Git. I can easily merge stuff together. And then I want to make sure I test. But in all of the other packages, just like ARCAD in traditional change management, because we don’t have that easy merge, we are worried about overwriting code on promotion.
So we have every concurrent change is considered; Oh, stop, check, merge. And we don’t have that high level of visibility of a pull request or whatever say; oh, this isn’t a problem. Just let’s keep going. Obviously we always want to test, you know, whenever we change code, we want to test it. And those folks that have gotten modular that are using, leveraging ideally, now we have the cascading dependencies of, I had a concurrent change in a module and it’s bound in a service program, which is bound in a bunch of programs. And, I might have multiple test cases to run to validate that, whether I’m using traditional or Git, what’s the impact of that change. And that’s true of the cross-reference tools. They’re going to identify the impact of that change. ARCAD down to the procedure level I change this procedure but uses it to limit the load there.
But again “shift left”. Do your your analysis of the concurrent development, whether you have Git an high level of visibility, whether you’re using traditional test any code changes before you put them together in production.

R.B. – Thank you Alan. Thank you Jeff. It’s pretty obvious that concurrent development on the IBM i using Git and ARCAD can enable the team to modernize their workflow, and they can integrate traditional IBM i development right into their modern DevOps practices. With this solution in place, multiple developers can work simultaneously on different features or fixes, and they use Git for version control and ARCAD bridges the gap between Git and IBM i unique architecture.Thanks for your insight guys.