IBM i DevOps TechTalk
Moving to Git – GitFlow #7

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. We’ll be listening to Alan Ashley, a senior Solutions Architect here at ARCAD, discusses Git and Git related topics with Jeff Tickner, our CTO here in North America. They’ll talk about Git, Git workflow, they’ll talk about how ARCAD integration relates to all of this.

A.A. – So, Jeff, why can’t I just move my workflow to Git using my current change too? I mean, my vendor says, they’re Git ready.

J.T. – Some of our customers have been able to do that, but it’s pretty uncommon. Generally, your workflow is designed around the IBM i and the pain points that people has with it, they’re trying to solve with Git need to leverage the Git functionality, the merging and branching and so on. That’s part of Git. The other problem with using a regular traditional change management package is often it’s not a two way integration with Git, I can’t pull and push, it’s really designed around pushing your changes to Git. And now you’re missing out on the merge capability and you need to have the developer interact with Git because that’s where the power is, where I can see somebody else’s changes and go grab it if I want.

A.A. – So you mentioned this two way integration. You mentioned a little bit about it. Why should I care about using push/pull at the developer level?

J.T. – That’s part of the power of Git. We have this branching model and we have the ability to merge branches and really one of the promises of Git is to facilitate the management of concurrent development. So if we have two developers changing the same source and we merge it together, I really want to be able to pull that merge source back down into a library and test it.
And that’s also where GitFlow comes in, leveraging the branching. Most of our customers are using a feature release model where we can take two features that have the changes to the same member and merge them into a common release. And we want to obviously test that. And if we have a merge conflict, we want to be able to pull that down so the developer can resolve that conflict and test the result of the merge.

A.A. – You mentioned GitFlow. I’ve seen a little bit about it when I do some of my Git research. Can you go into what GitFlow is and why I should care about what GitFlow is?

J.T. – So GitFlow came out of the concept of branching. You have a main branch, a trunk that’s often called master, but now it’s called main and that branch represents production and you branch off of it just like you’re checking out source right now and work on your changes. And what they developed in GitFlow was an intermediate branch we call the branch. The developer works on a sandbox or a feature and then you have a release that’s going to go to production and the concept of merging those working branches into the release allows me to test the integration of the changes or the merge of concurrent development at a test environment instead of trying it out in production. You don’t want to test in production, right?
So you need to have that GitFlow. And we have customers using all different kinds of GitFlow sandbox feature release. We have a customer doing a feature to a test release to a production release. It all depends on what your needs are and that’s pretty tough to do in traditional change management and Git makes it easy because of this merge concept of I can take a hundred changes and just do a merge of the branch and then we’re going to build and test.

A.A. – Okay, now that I understand a little bit about GitFlow, what does ARCAD bring to the table with its integration and making use of GitFlow?

J.T. – I guess so ARCAD really brings the automation part. We have plugins for Jenkins. We can automate any of our tools, but the build is the most powerful thing. That’s why IBM uses our build for Merlin, because there’s not a lot of choices out there. And the build means that when I leverage GitFlow, when I merge these branches, it’s so easy to merge our branch but now we have a several hundred changes to build. ARCAD does it automatically and can automatically deploy into a test environment because when I’m merging changes together or concurrent development together, I better test that stuff. And that’s kind of where the two way integration goes. If I merge branches together and have a conflict, I have to resolve that conflict.
That usually means a source change. The developer should be able to pull that source down and test that conflict resolution because it involves changing the source. If the source changes or the environment changes for a dependent object, we want to build it and test it.

A.A. – Now, is ARCAD flexible enough to handle this? As I go through this and I’ve matured down this path and I’m using all the different features to GitFlow branches, releases or rather, let’s speak truthfully here, I’ve bitten off a little bit more than I can deal with when I’ve made this change. Is ARCAD had a flexible enough to go with me?

J.T. – We’ve been doing this for a while for nine years and one of our first customers, we had to go back in after a year and change up their workflow because we used environment branches and it just wasn’t working with the IBM i requirements. So one of the things that we’ve learned is that people do need to change their process.
They might design something very complex or complex GitFlow that their Java developers are using, that’s just too much on the IBM i side and they might start out simple and start leveraging the more powerful aspects of Git by adding in more complex branching structure. That’s the point of the Git packages like GitHub and GitLab is they can enforce those workflows around the branching and who can merge into what branch and so on.
But the cool thing is you always have a branch, you always start with a branch. It doesn’t matter if you say I have three levels sandbox feature release and I don’t need the feature anymore, I just want to do sandbox release. You have the sandbox branch to take the release of the feature out of there and the same goes in the opposite.
If I have just a release branch, I’m starting out simple. I can tack on that additional level of branching because I see the benefit of it. I see that it’s not as hard as I thought it might be. So we can go on either direction. We can also start from just traditional change management and we now have a relatively automated process to migrate that on to Git branches.
We’ve done it for some pretty good sized customers now where they started out with traditional change management and in ARCAD and we can in a very short time. But all those changes into Git branches automatically because of the level of our automation. We’ve already done all this. We’ve already learned all the hard lessons. And so we’ve tried to make it as easy as possible for ourselves and our customers to make these decisions and modify what they started with to what works best for them.

A.A. – That’s a lot of information there, because I know that when I’ve studied Git and I’ve looked at it, there’s just so much information on it and knowing that with ARCAD has been working on it now for a while that it can kind of grow and flex as I do things. That’s nice to know. So thanks for joining us today, Jeff, and I’m sure we’ll be back for more Git questions as we go through this, because I know off the top of my head I’m already ready to talk about really making use of merge conflicts and things like that.

J.T. – Thank you Alan and Ray. It’s great talking about this. I love sharing my knowledge on my long experience. I’ve been doing change management for 25 years and source control for nine. So I love to be able to share my experiences and help people to be the best they can be.

R.B. – Thank you, Jeff. It’s always great to listen to you. You are a wealth of knowledge on these topics. As Alan said, there is a ton of information that was just delivered in this little discussion. I think the point to take home, though, is that working with Git, with IBM, i native source is definitely possible.
Bringing IBM i developers into a DevOps environment using tools like Git, GitLab, GitHub and so on is possible. So again, guys, thanks for your time.