IBM i DevOps TechTalk
Moving to Git #3

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with our Arcad experts. Today’s topic key considerations and advantages when moving to Git.
Hi everyone. My name is Ray Bernardi. I’m with Arcad Software. I’ve been here for sixteen years. I’ve been in the application lifecycle management space for over 30 years now at this point in time. And I’ve got a couple of experts here with me today. I’ve got Jeff Tickner. Jeff, why don’t you say hello to everybody?

Jeff Tickner – I am Jeff Tickner. I’ve been working in change management for over 25 years myself with a couple of different companies and I do implementation, so I’ve been kind of the hands on, implement and train on the development processes we set up.

R.B. – Thanks, Jeff. Also joining us today is Alan Ashley. Alan, why don’t you say hello and tell us why you’re here?

Alan Ashley – I am here as kind of the DevOps representative, the one that begins to show and tell part of this, after a long career over at Big Blue.

R.B. – And you’re more into the testing area and things like that, are you not?

A.A. – Testing and anonymization and things like that? Yes.

R.B. – So today’s discussion is on key considerations and advantages when moving to Git. Alan and I interview Jeff on that topic. Let’s go ahead and listen to that.

A.A. – With many companies now moving to Git across the enterprise, now IBM i shops are no different to this move. So how will the Git IBM i exist and work together Jeff?

J.T. – The important thing that you want to remember is that to Git, all of these different languages it manages, are just text. It doesn’t know what RPG is or Java, so it’s just going to manage the IBM i native source COBOL TDS as text files. And really the trick is managing the editing and build. That doesn’t happening yet.

R.B. – So editing happens in tools like RDi and the build is going to be handled by something like ARCAD. So is Git just managing source? That’s all it’s doing?

J.T. – It’s also versioning. The source changes line by line and there’s no other change management package, ARCAD included, that gives you that capability. And that’s why we chose to integrate with Git to provide that functionality customers want.

R.B. – That sounds like a distinct advantage to me.

A.A. – So now that we’re moving to Git, what are some of the advantages that an IBM i shop will get from Git?

J.T. – You’re probably going to find that you’re already using Git, some flavor of Git, at your company on the other platforms. And so you now have the opportunity of working directly with the guys working on the gooey interface or what have you, that while you’re working on the back-end and you’re no longer siloed. And if you can adopt other similar tools like the automation tools, you have the potential for synchronous deployment, which makes life easier.
One of the things that IBM i’s shops generally avoid is concurrent change, which is normal out in the open systems world, and that’s because they have tools like Git to manage my changes line by line. The other nice thing is that you can work offline way to Git because in the traditional what we call distributed mode, everybody has a copy of their repository and so they’re not needed to connect to the server to make changes. Of course, on the IBM i, they compile, you have to have an IBM i.

A.A. – On Arcad I heard the term centralized and decentralized and distributed. Arcad supports all that with Git.

J.T. – And that’s the interesting thing is that because these tools are open, Arcad is open. We work with Merlin, which is kind of our own centralized technique within ARCAD where we don’t have a copy of the source. And that is something that’s important to some of our customers that the developers aren’t walking around with a copy of all their source.
And so it’s just a matter of automation. In Merlin, they have us a central server for editing and everybody’s using a browser. In Arcad, we’re using RDi or even greenscreen because we’re managing the interaction we get in the traditional way. If you’re using Vs Code or even Visual Studio, you can edit IBM i source now and you’re going to be having a local copy of the repository.
They get repository on your workstation.

A.A. – So wait a minute. You’re telling me there’s all these copies of this repository out there and all these developers may have a copy of it on their laptop, they may have parts of it here and there. Where’s the trusted source now?

J.T. – So that’s a great question. That’s a real common early question from our customers when we’re talking about implementing this or even in the middle of implementation; is if I have copies of the stories out in the office and I might have copies in the library for compiling and I might have developers walking around with copies of the repository on their workstation, what do I trust?
And the answer is the Git server. So when we say that we’re going to build, we always build from the Git server. And when we start developing, we refresh our source. However, we have it, whether it’s a local repository or it’s a checkout in Arcad centralized mode, we go back out to the Git server to get it. That’s the trusted location.

R.B. – Now, Jeff, even though that’s the trusted location, the source still resides on the IBM i, does it not?

J.T. – Yes. That’s part of the magic of Arcad is we need the source in the library. So we keep the source in our library for the developers for debug, etc., and we keep that in sync. We have a process to make sure that we’re still in sync after we’ve been using it for a month or a year or what have you, because people are worried about that, getting out of sync. They have copy and Git and they have a copy in the library.

R.B. – So to a developer using Git with the IBM i, there’s really no difference. They do the same thing. They’ve always done. They work in a library on the IBM i.

J.T. – In the Arcad centralized method, but you can still have developers working in the more common Git distributed method alongside those centralized ones because the Git server is where all the changes go. It’s the common area where you merge those changes together and that’s another magic of Git is that merge. I can have disparate ideas, disparate methodologies as long as I have a common Git server and I have that Git merge and conflict resolution, all that fun stuff to manage that.

A.A. – Jumping back just a little bit, you mentioned concurrent development and I know everybody loves to do concurrent development these days. In Git there’s things we hear called branches and merges. Is this how this all comes together with concurrent development?

J.T. – Yes. So essentially you have the trunk main branch, master branch, and you branch out after that and you’re essentially branching off individual projects. So you have kind of a copy of the source in your branch and you can have people working on multiple copies of the same program source in different branches, and that provides the isolation. And then the merge back to a common branch is where the concurrent development potential issues are resolved.
That’s merge conflicts, that kind of thing. And we’re leveraging the fact that we can track where those changes came from on a line for line basis. So if I merge four versions of a program into a common branch, say a release, so commonly we use features into a release, I can look back and say: Where did all these changes come from?
Git actually calls it blame. So I can say show me blame and it tells me where each change that did align came from if I merged four different changes in.

A.A. – So you’re not losing any changes like normally when you do an IBM i change, you just overwrite what’s there and it’s gone.

J.T. – Yes. So my long experience with traditional change management, we did have to deal with those problems no longer because Git does not overwrite, Git always merges and if Git can’t merge you get a merge conflict and it has a mechanism for resolving that intelligently. And what’s cool is that conflict resolution is a specific separate change event, separate from the actual source changes.
So it’s this really granular history that if I have a mess, I can sort that mess out intelligently. It’s not magic, but it’s pretty close from my experience, 20 years of experience in traditional change management.

A.A. – So Jeff, all the things you’re saying, it sounds kind of complicated and how it all kind of goes together, you’ve got features and branches and merges. Is there a way to help simplify the process? Can we tap into any kind of automation that’s out there?

J.T. – We can’t skip any steps, but we can make the steps less painful and we can take any tedious steps and automate them with validation. So that’s where automation comes in, is I have to do the merge, I can make the merge as stateful or as simple as I want because they get packages, provide merge requests or pull requests for peer review, etc. or I can streamline it.
And then when I say that merge happens, all of the follow-on actions can be completely automated. So typically I’m merging into a release to go into integration to see how things work together. I can say I merge in my changes; now build them, build all the dependencies and deploy that, if they build a successful into the integration environment and depending on the package, I can do messaging and tell there’s new changes I can link back to if I’m using JIRA or another cast package. I can link back to the task. Maybe as a test plan I can automate unit testing along the way so we can’t skip steps, but we can streamline the steps by automating the tedious ones. And the nice thing is when we’re using pipeline tools and we did a session on automation previously that was good.
But using pipeline tools, we can have a logic in there and we can do all kinds of fun stuff in there.

A.A. – So as we move from a traditional change management into Git as a ACM, what are some of the milestones or checkmarks that we need to look for as we move in to using Git?

J.T. – So the most important thing is that management is on board with this adoption. What I found in implementing Git in IBM i shops is there’s a significant cultural change for the IBM i developers and I won’t deny that there is a learning curve. And so management has to be prepared for that learning curve. The way to minimize the learning curve for the organization is to look at how you’re using Git in other places in the organization.
What kind of surprised me was when we started this process of adopting source control we thought would be small organization, small companies that adopted at first, but it was actually a big company because they were already using these processes and other places. They saw the benefit they want to extend it to the IBM i. And what that means is you often have someone in your organization who’s familiar with Git and you want to leverage them and hopefully you have someone that came from the IBM i and has gone like IBM i’s developer, is doing Java now and is using Git and understands both worlds or vice versa.
Somebody that was a Java developer is now doing some freeform RPG and they can be a very useful person to translate the unique requirements of the i to the Git subject matter experts at your organization. Someone has to manage the branches. Even if we hide the branches as much as possible. And the extra complexity of Git from the more traditional IBM i developers, someone that understands IBM i’s code has to manage the branches.
So especially with those merges, remember, Git doesn’t know what RPG is, so somebody has to make those decisions about the pull requests and emerges and merge conflicts. So it certainly helps if you have IBM i developers with an open mind, it’s still source control. It’s not source control as an afterthought.

A.A. – So knowing that and having worked with a few IMB i shops in my day. Some IBM i guys are not big on change, so they’re going to need some help getting to the step. So how can Arcad help someone who’s not fluid with Git.

J.T. – Arcad has a benefit because we’ve been doing this for almost nine years now. So we have the benefit of a lot of experience. We’ve identified where the unique requirements of the i can be an additional challenge and we can help translate those requirements to the folks you might have in an organization that are already using Git.
We have a high level of integration with automation tools. There are plugins for all our tools and Jenkins. So the implementation is easier and then we have a lot of experience training on using Git. We for years did not have a relatively easier centralized method and I had to teach everybody how to use Git directly, which wasn’t much fun sometimes.
Now we can provide an easier path for some developers, but some of your IBM i developers have to be fully immersed in Git. You just have to anticipate that. One of our techniques is to do a kind of pre-training where we both train the subject matter experts and test the workflow to make sure it meets your requirements.
And then once everybody’s happy, we roll out this process to the rest of the developers, those pre-trained subject matter experts are now helpers in the training. We’ve already tested all the use cases and so we have a go live right after the general training we have. You can do a system where the pre-trained folks, the subject matter experts can help that people that are newer to Git.
So we have a way to kind of reduce the learning curve and get people up and running as fast as possible and try not to bury anybody under a large learning curve where they’re not productive.

A.A. – Jeffrey, you must have read my mind, because I was about to ask a question about training and you covered it: you’re going to get training from your peers, your gurus or your champions as you go through the process and I think one of the things I took away was that just because you’re an IBM i developer doesn’t necessarily mean you have to change all the ways you do things differently.
You can still develop right in 5250 if you want, and you can develop right in RDi. But now you’re getting kind of a more enterprise level of source management that will in the end make your life a little bit easier.

J.T. – Yes And that’s the benefit of Git is I can choose whatever interface I want. Some of that enabled by Arcad functionality and some of that enabled by Git and the efforts of other folks in the open source community code for IBM i has completely opened up Visual Studio and Vs code. So it’s really an exciting time because we are getting a lot of choices and we can really leverage those. Training is super important, we want to have our champions that can provide internal resources. We certainly don’t want you tied to Arcad for the rest of your lives because you have no idea what you’re doing. We want you to be successful on your own is our goal. And it’s a new world for some folks, a very new world.
So we definitely want to have some people comfortable with it when you go live.

A.A. – Thanks, Jeff. This has been an outstanding little session here that we had today. It covered a lot of areas of Git and I know going forward as we have these talks, I know we’re going to have one on feature release and merges in and of itself.

J.T. – A very important one.

A.A. – We hear about it all the time, so I’m looking forward to this session. And thanks again for speaking with us this afternoon.

R.B. – Thanks for listening.