DevOps Means Using The Tools You Already Have Better
April 24, 2024 Jeff Tickner
In this world, there are always more than two ways to skin a cat, but the best way to skin any cat is the way you already know how to do it.
The same is true of application development from within a DevOps toolchain. When modernizing development processes on IBM i, the most efficient thing to do, always, is to make use of enterprise tools already in place within the organization and integrate these into a cohesive IBM i workflow that shepherds code from idea to production all along the way.
It may seem obvious to say so, but trust me, it isn’t always obvious to companies and their IT organizations that, as far as possible, sharing the same tools across IBM i and distributed systems is always the most efficient approach to modernization. And that the most inefficient thing you can do is to require developers to switch back and forth between different development tools to accomplish their task. We always advise our IBM i customers to identify which DevOps “flavors” are favored by the full-stack teams and from there, we build a progressive roadmap to help IBM i teams add more and more automation into their development workflow, step-by-step.
This is possible with ARCAD because we deliver plugins and extensions to most of the standard DevOps tools today. Having a tight integration is so important to avoid developers needing to exit one tool and go into another tool to accomplish some part of the DevOps workflow. Anytime you do that, you are going to take at least a 10 percent productivity hit.
We hosted a webinar recently, and one of the things that we were showing off was the way that the ARCAD suite of DevOps tools integrated with Azure DevOps and Azure Repos from Microsoft, which is increasingly in demand across our customer base. This trend surpasses even the GitHub collaboration platform, which Microsoft gained control of by paying $7.5 billion over five years ago.
We are getting more and more Azure customers. And somebody asked if Azure DevOps could be used with something other than GitHub as the source code repository. This is kind of ironic because it used to be that everybody thought you had to use GitHub, that that was the only flavor of Git. Our IBM i customers using Azure DevOps are telling us that ARCAD’s tight integration has led to a reduction in work and time savings. They are enjoying the tooling and well advanced on their DevOps journey.
The focus here at ARCAD is this workflow, this functionality, and this methodology and we propose that our tools and your tools should work with any Git tool. And when you get into the broader workflow, if you are wondering which of the plethora of CI/CD tools you should consider on IBM i, look out for emerging standards and always try to choose the tools your company is already using now.
This does not always occur to people. When they hear Git, they think GitHub, and the irony is that after the GitHub acquisition by Microsoft it is actually getting less popular and GitLab, an alternative repository, is gaining momentum. Now, the Azure cloud and its application development tools are very popular because Microsoft is providing a lot of functionality for the enterprise and so customers are adopting Azure for task management in DevOps. And it just makes sense to use Git for source control. The funny bit is that everybody is using Git under the covers.
Now, what used to be Team Foundation Server at Microsoft has been transformed into Azure DevOps, which among other things is a task management system for developers. Microsoft deprecated SourceSafe (which had been their staple source control system since the 1990s) and adopted Git as a standard.
IBM is partnered with GitLab and for good reason. GitLab comes with robust CI/CD pipelines and integrated security features. GitLab is also interesting in that it is one of the tools that can be installed “natively” in the PASE AIX runtime environment for the IBM i operating system. If you are using the Jira project management tool from Atlassian, which is super popular and which is part of the ARCAD stack as well, you are likely to be using BitBucket as a repository. ARCAD is neutral in this regard, and our tools integrate tightly with all of the Git repository variants. Our advice to our IBM i customers is always to share their RPG, COBOL, and CL code in precisely the same Git repository used for other platforms.
When it comes to efficiency there is nothing more important than the quality of integration. In software development everything we need to do starts in a task system. No modern enterprise is not using some kind of task system to report and track an issue with applications or requirements for those applications coming from managers and end users. That task system should be integrated with the day-to-day actions of the developers, and not require the developer to leave their coding system and go update a task system. As a developer, you want to sit down at your workstation, get into your IDE, and develop. That’s what you are being paid for. You don’t want to go out and manage tasks. And so if we can integrate the developers workflow with a task system, then we have this high level of visibility. Developers are not wasting time interacting with a task system. It’s all just happening, fluidly and transparently.
This integration between the task system and the source control, no matter what one you choose, is great for facilitating audits as well. So an auditor will commonly point to a change that was in the task system, and then look to see what changed. Or they will point to an object and say who touched that last. And so we stamp the task on the object itself. So we can back right into the task, which shows all the changes, so they can start from a task and see all the changes and see the objects that were changed, etc.
The important thing, though, is to see how much time your developers spend managing their tasks, managing their workflow. Any time developers spend on activities which do not directly and visibly deliver value in line with business requirements is waste. A key example is task switching. When a developer is interrupted from their work to address another activity, even if it’s a 10-minute update on some other system, waste is created. On average it takes a developer 20 minutes to get back into the deep mindset of what they were doing after an interruption. Even if the interruption starts with “when you have 5 minutes can you. . . .” The fact that you contacted them often prompts them to think, well I have been interrupted already so I might as well do it now.
With better integrated tools, developers spend less time dealing with a task system and more time coding, which is what you’re paying them for. That is what this whole integration concept is about. Yes, we want to use Git, but we have this range of tools that provide access to Git and integration with the rest of my business processes. And as I integrate, as I invest in incorporating those tools, my return on investment is my developers spend less time updating tasks they don’t need to because the task is being updated automatically by their actions. That’s a measurable ROI right there.
Integration is the overriding byword at ARCAD Software. We refer to this as “Bring Your Own Tool” or BYOT. It means that whatever your existing enterprise DevOps toolchain, we can integrate your IBM i workflow right with it. You gain complete visibility and line-level traceability right across the development lifecycle, from the time a change request comes in, right through to a code update being delivered to production. As well as providing a more comfortable process for developers, integrated tools mean greater automation, so they can deliver better quality code faster. And not to mention, far less painful audits along the way
To learn more, register for our Webinar series:
Step-by-step DevOps on IBM i: start simple, grow at your own pace!
Jeff Tickner is chief technology officer North America at ARCAD Software.
This content is sponsored by ARCAD Software.
RELATED STORIES
Hybrid Release Management Means Creating An Application Schema
Take A Progressive Approach To DevOps
The First Step In DevOps Is Not Tools, But Culture Change
VS Code Is The Full Stack IDE For IBM i
Realizing The Promise Of Cross Platform Development With VS Code
If You Aren’t Automating Testing, You Aren’t Doing DevSecOps
The Lucky Seven Tips Of IBM i DevSecOps
Git Is A Whole Lot More Than A Code Repository
Learning To Drive Fast On The DevOps Roadmap
Expanding Fields Is A Bigger Pain In The Neck Than You Think
Value Stream Management: Bringing Lean Manufacturing Techniques To IBM i Development
Unit Testing Automation Hits Shift Left Instead of Ctrl-Alt-Delete Cash
It’s Time For An Application Healthcheck
The New Economy Presents New Opportunities For IBM i
Creating Web Services APIs Can Be Easy On IBM i
Jenkins Gets Closer IBM i Hooks, Courtesy Of ARCAD
DevOps Transformation: Engage Your IBM i Team
The All-Knowing, Benevolent Dictator Of Code
Software Change Management Has To Change With The DevOps Times
Attention Synon Users: You Can Automate Your Move To RPG Free Form And DevOps
Git Started With GitHub And ARCAD On IBM i
One Repository To Rule The Source – And Object – Code
Data Needs To Be Anonymized For Dev And Test