By Alan Ashley
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.
Now for the Move to Git
Once the connections are in place, it’s time to make the move from the IBM i Source Control under Arcad as seen through the eyes of the Skipper RDi plugin to Git. If you use GitLab, GitHub, Azure, BitBucket or others, Arcad has the hooks to support this move. From the skipper perspective or even green screen, it’s one command to start the move. Just a Load SCM. Depending on the size of the repository, location of the repository, and the communication path, this can be a decently fast process.
When the load has completed, it will look something like this. So now your source code management has started. This is the view from the repository in GitLab.
The next version
So you are now in Git, now what. To keep this simple, we’ll leave out all the possible connections and triggers to tools like Jira or Jenkins. We’ll stick with just SCM and Arcad integration. Keep in mind, this flow is high level and can be highly customized to fit your needs.
- You create a new branch from master in Git.
- This triggers a webhook connection to builder to create the version on your IBM i.
- You then open your IDE, you can begin to check out components into this version library that was created from the above trigger, you edit some code and are done.
- You may have done some testing here, such as code quality or unit testing.
- Now you are ready to send it to Git and to be moved into production. Export your version to SCM or we can have it as a macro to fit into your process flow.
- In Git, you submit a merge request, this will then trigger a review between the master or release branch and your feature branch.
- More than likely you will have multiple feature branches that will be merged with a release branch, prior to merging with the master. Remember, Master is Production.
- But this merge request can trigger the actual build of the version, all the components that are needed, like Tables, Data Areas, Data Queues, Programs, etc.
- At this point you have an artifact ready to be deployed or released to production. Or depending on your flow, off to QA
I know, that’s a lot to take in, it sounds complicated, but it just sounds that way, in practice it flows nicely. It may look something like this when you are in full flow when using Git as your Source Control.
In Summary, with Arcad’s Centralized approach:
- It’s the LEAST disruptive option for the IBM i Developer. A ‘pull’ occurs behind the scenes with a checkout. A ‘push’ occurs when the Developer takes a menu option or right clicks to export to SCM.
- IBM i Developers continue to work 5250 or with RDi.
- IBM i Developers enjoy true concurrent development with the powerful merge features of Git as well as history of a change at the line level as well as who made the change.
- It’s modern development that comes with many benefits from integration to a flexible phased approach to move from classic change management.
Now think back, I stated this “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.” This is where Arcad will shine, just sit back, and watch the magic.
Alan Ashley
Solution Architect, ARCAD Software
Alan has been in support and promotion of the IBM i platform for over 30 years and is the Presales Consultant for DevOps on IBM i role with ARCAD Software. Prior to joining ARCAD Software, he spent many years in multiple roles within IBM from supporting customers through HA to DR to Application promotion to migrations of the IBM i to the cloud. In those roles, he saw first hand the pains many have with Application Lifecycle Management, modernization, and data protection. His passion in those areas fits right in with the ARCAD suite of products.
REQUEST A DEMO
Let’s talk about your project!
Speak with an expert