IBM i DevOps TechTalk
Phased approach to DevOps and Git #11

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. My name is Ray Bernardi from ARCAD Software, and I’m today’s expert. I’ll be interviewed by Alan Ashley. He’s a senior solutions architect here at ARCAD software. Today we’ll be discussing the benefits of a phased approach when moving to DevOps and Git.

A.A. – So we’ve been going down this DevOps and going through phased approaches. Now we’re ready to move into Git. How can ARCAD help drive Git implementation within DevOps as the next step in their phased approach?

R.B. – Transitioning to Git especially for an IBM i shop is a daunting task really. We’re behind the scenes or behind the times when it comes to that. Now ARCAD does understand that, and we have several different strategies for helping with a smooth, phased implementation to Git within your shop. We like to say, crawl, walk, run and fly.
And really what we’re saying there is start small and then scale up. That’s really what you have to do in order to do this and minimize risk at the same time. Instead of starting with your entire code base coming out of the gate, what you should do is choose a smaller project or a smaller module and experiment with Git.
First, learn the workflows, and so on. Let your developers become familiar with the tool and the workflow while they still remain productive. This strategy allows you to educate without disrupting daily workflow. Of course, there’s other things to think about as well. For instance, what flavor of Git will you use? ARCAD has multiple ways of working with it, and it really depends on the maturity level of your organization.
We can interface with Git and with 5250 screens. For developers that really don’t want to know Git, maybe your legacy developers who’ve been around forever and they don’t want to learn this new technology yet they have to be part of it. So we can help that person. We can also bring this into things like RDi.
We have Git functionality within RDi. We have what’s called a hybrid approach that we can use as well. We can combine different methods based on individual preferences within the organization, different project needs, different education levels, and so on. This phased approach allows you to take one step at a time without trying to do everything at once, which typically leads to problems.

A.A. – Right. So when you are working with Git, and this is one of the things that I’ve heard others within ARCAD mentioned is use the resources that you have available within your enterprise. So for example, I’m not talking just maybe Github or GitLab as your repository. We’re talking about the people that manage. There’s branches and there’s repositories that are already there so that you can help with this training and understanding of how what a GitFlow would work and then how it ties back into an ARCAD application?

R.B. – Yes. What you’re doing there is you’re leveraging your existing tools. You’re leveraging existing knowledge within the organization. If you’re already using a pipeline tool like Jenkins or something like that, then there’s no reason why your IBM i developers cannot also use that same tool, that same pipeline tool: Jenkins, Cloudbees, whatever it happens to be.
So looking at your organization and seeing what’s happening within the organization now can change the way you’re going to approach the implementation of Git. It will also reveal to you what level of expertise is available to you within your organization to assist you with that transition into the new workflow.

A.A. – As we begin to move into this new world of using Git for source control management and expanding out the maturity levels within DevOps, some of the things that ARCAD can really help here with is some of the automation that takes place behind the scenes, to aid in that development from walking to running to beginning to fly and to really get there. You’ve got to have this automation within the toolsets to really take advantage of it and start to see some real good returns on investment. So how can ARCAD help with some of the automation aspects of this?

R.B. – Automating Git workflows in the IBM i environment is all about basically boosting efficiency, reducing all your manual efforts, and freeing up your developers. ARCAD does an awful lot in that area. We’re talking about CI/CD type integration here. ARCAD integrates with most of the popular tools that are out there.
It connects seamlessly with a lot of CI/CD tools like Jenkins, GitLab, CI and whatnot. So we can automate the entire software delivery process. ARCAD can trigger builds. It can trigger tests, it can do all these things in an automated fashion. Just a change in a Git repository can automatically trigger a build through a Jenkins pipeline or kick off a Code checker test for example, and do a peer review basically of all the code that’s being brought into an environment.
So what we’re doing there is automatically ensuring code quality, functionality and so on. Doing all that before deployment and again all automated. We can also deploy those updates automatically for you obviously. So if we get a successful build, for instance, that we can seamlessly deploy that code update, put that out in production. So again, manual intervention is minimized.
The other thing that you have to think about in these situations is rollbacks. If you’re going to fail, fail quick. But if you fail quick, make sure you have a way out. So we also automate rollback procedures, which should be part of what you’re thinking about when you’re talking about any type of automation you want to automate getting there and out if you can.
Now some of the specific ways we do that is we use webhooks. Those things are available within Git. So those can trigger all kinds of relevant functions at the right point in time within your workflow. We also have a smart build system in ARCAD, that’s Builder. So what it does is it analyzes the changes in the source code and identifies all the dependencies and all the other components.
So you tell Git here’s the delta on a branch. And then ARCAD automatically recompiles and updates everything else that’s related. And that eliminates all the manual steps that the developer would have to take there. And again I said automating the testing and so on. So The benefits here are obvious. You’re reducing errors. You’re getting faster delivery cycles.
You’re increasing productivity and you’re reducing risk.

A.A. – That sounds like a nice way to approach this. And no matter what conversation we have we always seem to come back to the shift left. You mentioned fail early. That goes right into that whole shift left mentality. Find it, find it early, find it fast. So it goes right into that.
And with these approaches that you talked about, you literally went through almost a walk run fly scenario here, going and getting from just the basics of your application, understanding the workflow to full blown rollbacks and distribution and deployments. That’s really when you’re starting to fly through this. So taking this phased approach really can reduce errors. You can work on the training through this and you can improve the workflows as you continue through the crawl, walk, run, fly.

R.B. – Absolutely. The concept of the shift left is you embedded in DevOps. DevOps emphasizes finding issues of quality, and security early within the cycle as quickly as possible. Early testing and integration leads to the discovery of those errors. And that’s why ARCAD doing something like automatic builds and automatic tests, automatic unit testing with iUnit or something like that; doing that static code analysis with CodeChecker. That automation right there leads to shift left because you will find things earlier. This is what we call DevSecOps integration basically. So we’re scanning for security issues. We’re scanning for coding issues, quality issues. So again, it all falls under reducing risk. This is all about.

A.A. – Within ARCAD, I know we have several ways of working with Git. Can you maybe explain the centralized approach because that seems to be very popular with our IBM i shops?

R.B. – Yes, I think the centralized approach is definitely the most popular centralized server management really is what’s going on here. Basically, what happens here instead of each developer’s machine hosting its own Git repository, ARCAD centralizes the Git repository itself. It uses a central server for that, and it manages basically all the code there. So that’s really going to kind of simplify the administration, the access control that ensures that everyone works on the exact same code base. What ARCAD does is it provides ways to access that code through menu options and so on. For instance, you have this centralized repository that everybody is going to be point to that, a developer creates a version within ARCAD that automatically creates a branch within the centralized repository.
And again, nothing is transferred to the developer’s PC at that point in time. So that makes it fast and simple. A 5250 green screen developer can work with Git with this centralized approach to it. We integrate with all kinds of different tools. This centralized approach works within Skipper. It works because of Builder.
And Builder is our smart, build tool. Really what builder is capable of doing is saying, look, a developer changed a physical file. Git has no idea what that is. When the developer takes a menu option, this is again centralized. They take a menu option. It updates the branch on Git.
As we’ve discussed earlier, we could trigger a webhook at that point. Figure out what the delta is. It’s a physical file feed that the builder. Builder knows. The physical has this index, this logical, these other dependencies. So ARCAD understands that has these other dependencies, and it does all. Builder does all that. So it’s streamlining the development cycle. And again it’s making it really, really easy. I mean the benefits of a centralized Git within ARCAD.
You’ve got improved collaboration between everybody because they’re all working on the same code base in the same centralized repository. You streamline your DevOps workflow because we can trigger automation at the right points in time and so on. So you gain efficiency, you gain speed and hopefully with centralized again one repository to manage. It’s going to simplify your administration as well.
It’s much different than the decentralized version. Decentralized does offer flexibility and offline capabilities and things like that. But it can also lead to issues within the repository. It’s more difficult to maintain control over that repository in the code base. So centralized kind of prioritizes control and collaboration and brings it all into one place at one time.

A.A. – When you start talking about DevOps, it’s really never ends. It’s always a growing. You’re always continue to mature as new tools and new processes are developed. You continue to implement that slowly through your environment until everyone’s comfortable and then you keep going. So I think we’ve about reached the end of our time here today on this little techtalk.

R.B. – A phased approach is really going to allow you to minimize disruptions and foster collaboration between your teams. It really should enhance your learning capabilities as well. And it should allow your teams to succeed in making a transition to Git. ARCAD and Git work together. And they really complement each other’s strengths.
ARCAD knows the IBM i and Git is the most popular source control tool out there in the industry. Using ARCAD and Git together is going to improve productivity, efficiency, and accuracy of your IBM i development team. And you’ll also reduce the risk of errors, problems in the development cycle. Really what you’re doing is you’re modernizing your tools and your staff at the same time. The whole thing is a win win situation. I guess my final words would be just get started. Do something, even something as simple as implementing code checker and automating code review is doing DevOps. It’s a beginning.