Git for IBM i: Enterprise DevOps Without the Enterprise Pain

Maia Samboy 00:00

For get. For ibmi. I’m Maya and I work in marketing here at Eridani. We only have 45 minutes for this session, so I’m going to just do some quick housekeeping and then we’ll jump right into it. I am recording today’s session. You will all receive an email with the recording tomorrow. Feel free to pass that along to anyone you would like. And if you have any questions, they can reach out to me at any time through email. Just my first name, mayaerodani.com secondly, if you have any questions during the session, you can put them in that little question and answer box and at the bottom on your Zoom toolbar, it’s going to be right below there and we will get to them if we can. If we run out of time, we will definitely follow up with you through email. And I am here today with Dan, our CEO and Aaron, our chief architect. We’re really excited to show you some awesome stuff today. And with that, I am going to pass it over to Dan.

Daniel Magid 00:51

Great. Thanks, Maya. We are ready to get started. Okay, so today we’re going to be talking about Git for IBM. I’m going to talk about both about Git itself and we’re going to about IBM I. But we’re also going to talk about the broader DevOps, the entire DevOps tool tool chain. So we’re not going to just talk about git because Git is really just for source control. We’re going to talk about Git for source control. We’re going to talk about how do you do IBM I builds? Because Git doesn’t actually know how to do that and how do you do deployments of IBM I codes. We’re going to talk about the entire DevOps life cycle. That’s why it’s Enterprise DevOps without the Enterprise pane. We’re going to be able to show you how you work with IBM I code. But at the center of all that is git. We’re going to start out with an introduction to what is Git? Why would you want to do this? What is Git going to bring to the table for you? Because it does represent a change from probably how you’ve been doing things. We’ll take a look at that. One of the very powerful functions of Git is its ability to handle parallel development. That is having multiple people working on the same things at the same time. The idea being is you don’t have to wait for somebody else to finish their work before you can start your work. Because Git will protect you from accidentally overlaying one set of changes with another. And it will give you very powerful tools for merging the code. When you’re ready to run, you can work on the things that are highest priority for you. And when you’re ready, Git will help you with how do I merge the changes together. Then we’ll talk a little bit about what Erdani is doing to help make that possible, to help Git work with IBM I code. And throughout this I’m actually going to be showing you demos. I’m going to show you exactly what this looks like in real life. And as Maya said, if you have questions, please post them in the question area of the meeting. Aaron is going to be monitoring that while I’m talking. And when he’s talking, I’ll monitor it so that you can see, so that you can get answers to your questions. And if we can, we’ll answer it as we go.

Aaron Magid 07:59

And Dan, actually, if I can just jump in. You know, one thing that, that we’re seeing these days, it’s very recent, is this is actually also becoming very important for, for AI assisted development. One of the things that we’re seeing is the reason why this was so powerful for development. The Linux operating system is effectively you had a massive distributed team of lots and lots of different people and you needed to be able to review what each one was doing and see exactly what the changes are and keep them isolated and then bring them in in way. Well, when you let an AI loose on your code base, it’s going to act in a very similar way. It’s going to make big sweeping changes. You don’t necessarily know exactly what it’s doing, but when it’s done it’s going to say, yep, I finished your feature and you need to then go in and make sure there are no hallucinations in there. Right? It’s actually achieved the spec that you wanted and it didn’t do any little side effects that are going to be a problem in your application. One of the very, very powerful things that we do with Git in our processes with our, with our programmers, is whenever an AI proposes changes to any of our code, we then review using Git exactly what changes it made to every single object. We keep them isolated in a separate area in Git until we’re actually ready to pull that in. So, you know, with the speed of development, it’s kind of like every developer is a distributed team in themselves because they all have these Coding agents now. And so they’re all using this to manage that development. And that’s, that’s making that, it’s making it possible for them to move a lot faster.

Daniel Magid 09:43

Great. Thanks, Aaron. Yeah, so, so in fact, let me, let me, before we go on with the PowerPoint, just because Aaron brought up some of that ability to see what’s going on, let me bring up here a view of a Git repository. Here. We’re looking at a git repository in GitLab. Now this could be a Git repository in GitHub, it could be in BitBucket, there again, a variety of hosting environments for Git, or you could have your Git repository just sitting on your IBMi. You can have the Git repository wherever you want. That’s the cool thing about Git is it’s designed to be a distributed repository where the code can live just about anywhere. But if you see here, I’ve got a lot of stuff that looks kind of like IBM iSource files, which is exactly what these are. But they’re just showing up here in Git. I’m looking at a view of my repository from the Task one point of view. That is I’m working on task one and I could be working on task two. I could be working in the integration test environment, QA environment. I can have these different stages of my life cycle. But what’s cool here is I can go in and say, okay, you know what I’d like to see? What have we been doing for task? And I can hit this history button. It’s going to show me all the changes that we’ve made for task one. So I can see what they are. Here’s a little information about them. What are the changes that you’re making? And I can say, oh well, gee, for that update for the HR enhancement, or this fixed a bug in my enhancement code, or adding the enhancement, what did I do? What did I actually change? So I can go in here and say, show me what I changed. And so I can see information about it. And I can see here you change this physical file and this is what you change. You change this physical file, this RPG program, and I can actually see the changes that I’ve made for that particular task, that particular thing that I was working on. So a lot of information about the history. Beyond that I could go in and say, I can say, okay, you know what, I’m really interested. I’m having a problem with a particular program.

Daniel Magid

Maybe I’m having problems with this CUA PGM1 program, I’m going to go in here and say, let me go look at that and I’m going to hit the blame button here. What it does is it shows me now for every line of code that’s changed, it’s showing me who changed that code, why they change it. If you think about this, a lot of us use the change dates in the source lines to try to figure out what was changed, things that were changed, and have the same change date, they must have been changed for the same reason. Here in Git, I don’t have to worry about that. I can actually see for every line of code that was changed, why it was changed. I can see who changed it, when they changed it, why they changed it. What’s really cool is that I can roll backwards in time. I can say, okay, so the last change to this line was adding new function requested by end user. That was the project I was working on. But I can say, well, what was the change I made before that? Now it says, okay, well, you made changes for dispatch. Then I say, okay, well what was the change I made before that? I can go back and I can just keep rolling backwards in time and I can see every change because Git is tracking every single thing that you do. So it knows who did it, when they did it, why they did it again. As Aaron was saying, if you’ve got code that’s being generated by an AI, you can see, here’s what it changed. These are all the changes that it made. We’ll see in a minute. When I walk you through the development life cycle that you can have people who have to review that code. So you can require that somebody look at that code before it actually moves forward. You have lots and lots of options about how to work in this environment. That’s just a quick view into what Git can do for you if you’re using it again. I’m going to show you in a minute. We’ll actually walk through an actual change or set of changes using Git for your IBM I code. Let me go back over here to the PowerPoint.

Daniel Magid (continues)

We talked that you can do that branching like we saw in that GitLab view. I had the Task one branch, I had the Task two branch, I had the QA environment, I had the integration environment, I had production. Each of those are a Git branch that you can look at and say, okay, well just show me what’s in production, what’s in qa, what’s in integration test, what’s in task one. I can see exactly what the status is of each of those stages of my life cycle. Parallel development, that ability to do that branching allows you to have multiple developers working on multiple projects simultaneously. Those streams can then be merged together later on, so you don’t have people waiting for somebody else to finish something before they get started. You can increase your velocity through this continuous integration environment.

Daniel Magid 17:51

These are the things that have come up as the benefits of being able to do this. It really comes down to much faster time to market for getting the code out more quickly. That’s basically the Git parallel development thing. It is the modern way of doing things. But there are challenges for IBM I users for using Git. First of all, Git does not understand libraries and source files and source members. It has to have things in directories. You have to have a way of managing that relationship between the directories and then the source files and libraries where you might be keeping code. If you’re still doing creates, which almost all IBM I users are from the library source files and source members, you need to make sure that that’s being kept up to date with what the Git repository says is the source of truth is where things should be. You need to make sure that those things are staying in sync. Git doesn’t do builds, so you need some way to say, I’m now ready to test the changes I’ve made. Go ahead and create the things I changed and by the way, create all the things that use the things I’ve changed. Git does not understand IBM I create commands. It doesn’t understand create options, it doesn’t understand dependency relationships. Because the whole build process is really outside of what it’s designed to do. Its mission in life is source code and managing source code, not the whole build process. Then IBM I Users again tend to use the check in process or checkout and promote process, whereas Git uses a process that is a git add, a git commit and a git push. I’m going to show you what those processes look like then. IBM I tools typically rely on a structured, rigid promotion to production process. Code goes from my development environment to test environment to production or development to test the QA to production, whatever that process is. Whereas Git offers a lot of flexibility and that’s a double edged sword. Having a very fixed rigid process makes things very, very easy, but it limits what you can do. Git’s ability to create branches and all kinds of different paths to production can introduce a lot of flexibility but also management issues. Things that are hard to manage. You can, if you want to, using Git functions, you can lock that down and say, well no, code only goes from development to test to QA to production. So you can actually mimic that kind of a process if you want to. And git, it’s just a matter of setting up your branching rules to enforce that which you can do. So.

Aaron Magid 20:39

So let me hold you for one second because we got a question that I think is very relevant to what you were just talking about. Question says, that’s all well and good, but does this mean that if I want to work with Git, all of my developers have to work with it? Is it impossible to have a mix setup where some developers are working in SEU on the IBM I while others are working against the Git, repo and Azure?

Daniel Magid 21:05

Great question. I think it’s a setup for this particular screen. It’s a really great question and it’s why Eridani exists. And that is our objective is to make it so that IBM I users can use Git in a way that makes sense for IBM I users. So we want you to be able to say, now I use PDM and SCU and I want to be able to work in my libraries and source files and source members and do things the way I’ve always done them. And other people are going to be working in VS code and other people are working in rdi and yet I want to be able to manage all that stuff together. And that’s really what Eridani is adding to the mix is we’ve set it up so that you can work in the libraries and source files and source maps and I’m actually going to show you this and you can use SEU and you can use whatever IDMI tools you want to use and yet still have Things kept in sync with the git repository, still have things work with the git repository. You can work in both ways simultaneously. You can work in the traditional IBM I way, or you take advantage of things like VS code and RDI and use some of the more modern tools and still take advantage of all the benefits of git. Now when we go to do the build again, if you go out to go do a build, there’s no way to do that with native git. Git doesn’t know how to do that. Eridani has a module called I build that goes out and figures out all of your objects, where their source code is, how they’re related to other objects, all the dependency relationships modules to programs or views, to tables or programs to tables. And whatever the things you have set up, it goes out and it builds that database of all those dependencies so it knows if you’ve changed some things and you say go do a create, it will create the things you’ve changed plus the things that use the things you’ve changed. So you don’t have to worry about getting level checks in production because you change the file but didn’t change the things that use it. Then I deploy the the third part of the Eridani set of modules for this environment is something that will then take objects and deploy them out again. Git doesn’t do distributions of objects. Eridani IDemploy will take a set of things you’ve just built and say, now I need to give each of my testers their own copy of the database changes and it can go and do that. Or I need to move the code from my development box to my production machine. Go ahead and just deploy it over there. Ideploy will do that. You have IGIT that allows you to work with git, but work with it from standard IBM environments or from the more modern IDEs you have. I build that will do the build process and then Ideploy that will deploy the code for you. Our idea is that you should be able to work in the way you want to to support that.

Daniel Magid 25:50

Let’s go ahead then. Actually, let’s go ahead and get into it. Let’s go say we want to make a change. So we’ll go in and say I’ve got some things I want to do. So again, if I go back here to my repository, I’ve got this task one and I want to start making some changes for task one. I want to go in and do some things that’s been assigned to me. I can go in and make my changes. Let’s go in. We can start out. Let’s start out here. I’m going to do a work member PDM and say I want to make a change to this RPG program.

Daniel Magid 26:27

We’ll say it’s a change I’m making for the webinar on 1 29, 2026.

Daniel Magid 26:42

And I’ll make the same change here,

Daniel Magid 26:51

Right? So I’ve made my changes in pdm, go ahead and save those changes. I’ve made the change here in pdm, but somebody else, let’s say, or even me, maybe sometimes I use pdm, sometimes I use Visual Studio code. I’m going to come over here into code and say I want to make a change to this physical file in Visual Studio code. We’ll just change this to 29 also. We’ll go ahead and save that change

Daniel Magid 27:25

and then we’ll go ahead down here to this physical file.

Daniel Magid 27:34

And we’ll change this one as well.

Daniel Magid 27:41

Right? So I’ve made some changes now to A couple of physical files to an RPG program in git. The next thing you would do is what’s called a git add, where I say, okay, I want to add this thing. So I can. I can right click here, go down here and say, okay, do a git add. Now, I could have done this against a particular file and said, I just want to add this one program. Or I can say, no, go out and find everything I’ve changed and add them all. Which is what I just told it to do. If I go in here now and do my git status, if I’m doing my work and I want to just see, well, where am I right now?

Daniel Magid 28:19

It tells me you’ve got these three modified things. The physical file, the two physical files in the rpg. Even though I made the RPG change over there in PDM in my libraries, Git knows about it, it’s there and it’s updated. It tells me that, okay, those are the things you’ve changed. I’ve now added those things to my list of changes in git. That’s typically how you work. You make changes and then when you’re ready, you say, okay, I want to add this. Now, the reason you have this add step is add in Git is basically a staging process. It says, okay, I’m happy with the changes I’ve made to these four things. Maybe I’m going to go change a bunch of other things. But these four things, those I’m happy with, I want to stage them for what’s called a commit. A commit in git is a very important thing. A commit is it’s a set of changes you’ve made that puts you into some known state that you’re happy with. You say, okay, I want to commit these because I finished bug fix 1, 2, 3, or I finished this little piece of the enhancement and I want to be able to identify what are the things I changed in order to implement that particular thing. What I could do now is do a commit. But maybe before I do that commit, I actually want to build the code. I actually want to go out there and say. I want to go out and say, you know what, I actually want to do a create of the things I’ve changed and all the dependencies.

Daniel Magid 30:58

It’s actually running that build process for me and it actually will tell me right here in VS code or in rdi if I was using rdi. It shows me here’s what was built. So you can see a lot of things were built because I changed the physical files and basically everything is dependent on those. It’s showing me here’s what was built. The only thing it didn’t build was a command because it says the command doesn’t need to be rebuilt based on this. If I go back over here to my library and I refresh the library now, see, I’ve got all that stuff in the library, so I can go in and do those creates now in a minute we’re going to see that you can just automate this whole process to say when I move to test or when I move to production, just automatically build stuff for me. And it will do that. But so, so we’ll take a look at that in just a second.

Daniel Magid 33:40

So now I’ve made my change here.

Daniel Magid 33:49

And now I’ve got. I have the same. I’m in the same place now. I’ve got this change out there, but it has yet to be staged for git. So I can go in and say, okay, do a git add,

Daniel Magid 34:02

Okay, and then I can do my git commit. So I’m going to do a git commit again for this change. So I’m going to get a second commit. And this one I’m going to say, fixed bug for webinar change. I can separate those two things now. I’ve done that and if I do my git status again,

Daniel Magid 34:31

It’s going to show me that I’m ahead now of the origin by two commits. I’m two commits ahead, have those two things to do. Let’s say that I say, okay, you know what, I’m good. I’m happy with those changes. I want to share these because up till now, if I go and look at my shared repository here in GitLab, let’s go ahead and refresh the screen. We’re going to See that those changes are not here yet. I don’t see those webinar changes here yet. They’re not in the repository. What I’m going to do is I’m going to go say, let’s do the next thing we need to do, which is a git push. I need to do the git push to push things forward. Now here’s an interesting thing that’s specifically for people working in the IBM I world, and that is in the git world, typically everybody is working from what’s called a fully populated repository, that is that each developer has a complete copy of all the source for the application. In the IBM I world, people don’t typically work that way. Typically in your development environment, you just have the things you’re working on and when you’re done, you promote those forward and you clear out this stuff from development. We have actually put in our git support the ability to work that way. You can say, I only want in my development repository things I’m currently working with this clear outsource function, which you can set the default for, says, when I do this commit, when I move this stuff forward, clear out the changes from my development library. So I don’t have them there anymore. So you can work in that sort of partially populated environment. I’m working the typical gateway with a fully populated repository, but you can work either way. So now I’ve done that git push. I’ve gone ahead and pushed the code up to the shared repository. So now if I go back over here into my shared repository, I can see. Okay, let me go in and take a look at the history of task one here. And I can. Oh, okay. So I have the, the enhancement for the webinar request and the fixed bug for webinar change. And I can go in and I can look at either one and I can see, well, what did you do for this particular commit? What were the changes that you made? So again, you have this very, very detailed history of everything that’s happening and it’s all happening for you automatically. So all of that tracking is done for you. You don’t have to do anything to make that happen. It’s happening for you automatically as part of the process. Now I can say, okay, we’re done with task one. Everything’s great with task one. I want to move it now to the integration test environment where maybe I’ve got task two and task three and whatever. I’ve got all the other tasks to work on.

Daniel Magid 38:00

And now it’s going ahead and it’s merging that stuff up from task one into integration. Now notice it checked first to say, can you do this merge? That check was to say, are there any changes in integration that aren’t in task one? Maybe task two changed some of the things simultaneously. It was checking and it said, no, there’s no issues there, go ahead and do it. So it’s now done that merge.

Daniel Magid 38:28 – 40:33

Right, I now have the webinar changes here. So I’ve got that stuff here. It’s now in my integration test environment. And same thing, if I want to move to qa, I can do the same thing. I can say, okay, we’ve done integration test, everything’s ready to qua of webinar changes, whatever. So I’m going to put my comment in there now I’m saying, okay, move this stuff into qa. So I’m going to create that merge request to say, okay, I want to move from integration test to QA up. And it says, wait a minute, you can’t do that. And that’s because I’ve set up a rule that says you can’t move things into QA until you’ve had somebody review the the code and tells you it’s okay, or until you run the source scan or until you run the automated tests, it’s not letting me move this. I need an approval. I’m going to flip over here to my other user here I am in that same repository as a different user. I as that other user, by the way, would have gotten an email saying, hey, you’ve got a merge request out there. So I’ve now got a request out there. I can go and I can look at that request so I can see this request that it’s currently blocked. I can hit the commits button here and I can see, okay, well here’s what’s in it. Here are the things that were done. And again, just like we did before I can drill in and actually see and review the lines of codes, the lines of code that have been changed. And I’m going to go ahead and say, okay, yeah, I looked at the code, everything’s good, go ahead and approve that. So I’m going to go ahead and improve that merge. Now that I’ve done that, I think I’ll go back over here to my original user and say I’ve gotten my approval by the way, it tells me who approved it. And I can say go ahead and run that merge. Now when it’s doing that merge, if I go back over here to my green screen, Look at my QA library, notice there’s nothing in there right now. There’s nothing in my QA library. And that’s because I now have an automation set up that says, okay, when you do that pull request here in the repository to say, okay, I want to move stuff to qa, I want you to then pull the code down to the IBM. I then run the build process, then run the deployment process and put things out into my deployment library for me.

Daniel Magid 46:20

The idea is in your IBM I environment, you can work from whichever tool you want to work from and you can still take advantage of all the power of git. You can do the parallel development kinds of things, you can do the comparing and merging, you can run your builds automatically, you can have that be part of an automation, you can do your deploys, you can take advantage of all the power of git and yet still work in the environment you’re used to working in. So you can continue to work the way that works for you. So basically that I know that’s a very brief, very fast overview, but those are some of the basics of being able to use Git based DevOps tools for an IBMI environment. And with that Maya, I think I’ll turn things back over to you.

Maia Samboy 47:10

Yes, thanks Dan. Sorry we ran out of time today everybody, but I will include the question and answer report as well as answers to these questions we didn’t get to in my follow up email that you’ll receive tomorrow so you can have all of that information as well as the recording. We’re so excited you joined us today again. If you have any other follow up questions after the fact, feel free to email me at any time and I can get those answers for you or get you connected with Dan and Erin for a demo or for them to get your more complicated questions answered. Again, thank you so much for joining us today. We look forward to seeing you soon and keep an eye out for that email. Thanks everyone. Have a good one.

Daniel Magid 47:57

Great, thanks everybody.