Whether you are a current Arcad Customer or one just looking to move from your current or nonexistent source control process to one that makes use of Git, then you have found the right blog. Arcad Software is the only vendor to offer a less disruptive transition for your development teams with easy implementation, and a quick move to the Git Source Control process. Not to give away too much this early in the story, but it’s about the “Build.” This is where Arcad stands apart from the others.
To start, lets figure out your current process and future needs:
- Do you have source control, either 3rd party or “manual?”
- Is your Application Life Management more like the wild west and anything goes?
- Are you still one version at a time?
- Do you have a Git repository in your company that your team is being moved to?
- Do you want to have pure and more functional concurrent development?
- Do you want to move to modern standards?
- Do you want to move the IBM i out of its silo and into the Enterprise?
Those are just a couple of the questions that can define your current and future ALM environment. But when it is time to make the move to a more modern methodology, such as using Git, then there is only one true path, that’s Arcad Software. There are many vendors who claim to support Git, but it’s not making use of functions of when it comes to the use of branches and merges or push/pulls or webhooks. Don’t worry about the terms as Arcad will handle a lot of the heavy lifting when it comes to those areas. Notice I left off the term build. See how I tease that.
So why are many moving to using a centralized source repository? This stems from the Open-Source side of the technology world. Open systems opened the way for communal coding and review. Now that we have an entire generation that is growing up on this process, it only makes sense that the IBM i world moves that way as well. Many worry about the transition, but fear not, Arcad has the expertise and tools to handle this and to ease any pain you may have in this transition.
So where does Arcad come into the picture? We’ll break this down into a few areas. Migration of Source, Building/Compiling, Concurrent Development.
To start, we do a cleanup/audit and build a repository within Arcad. If you are currently using our DevOps tools like Audit/Observer/Skipper, that’s done. If not, then Arcad has the tools to help with this process. Meanwhile, in the background we are just configuring a few settings to make the move to Git.
For the behind the scenes, we need to connect your Git repository to the Arcad Application via webhooks. This is followed by connecting our Builder application to Git and the Arcad Application. As you may or may not know, Git does not speak IBM i. Git doesn’t even know what an IBM i is. This is where Arcad begins to pull away from the competition. To get from Git to production, you must compile, and of course, Git can’t compile IBM i source code. Since the Arcad Application holds the requirements for the Build, the process to compile is passed through the Builder Application to ensure all the parts are wrapped accordingly, then it’s handed off to the IBM i for processing and compiling.