by Michel Mouchon
The DevOps movement has created a refreshing “wind of change” in the way application development is managed, reaching the furthest corners of the industry and not least our beloved IBM i.
DevOps came into existence as an offshoot of Agile development methodologies with the ambition of extending the same principles right across the entire application lifecycle, from the initial requirement through to operational availability of the functionality or feature for users.
In essence, the primary purpose of DevOps is to “serve the business” by delivering higher quality software as rapidly as possible – removing all potential obstacles at any stage in the cycle and automating anything that can be automated. With their open source advantage, both Git and Jenkins have emerged as the star players (though others exist and are steadily gaining some ground).
To be accepted on IBM i, the outright dominance of Git demands an explanation. In this article we will demystify Git and examine its relevance on the IBM i platform in particular. Tightly linked to Git are a number of collaborative tools with GitHub the leader in this space. But what exactly does GitHub bring to the table over and above raw Git? And how well adapted is an industry standard tool like GitHub to a traditional development environment on IBM i?
Summary
1. Getting to grips with Git
Git is a distributed source code manager which tracks application changes via an optimistic validation mechanism for changes (the “commits”). Developers’ work is secured along with complete traceability of all source code changes. This mechanism frees the unlimited creativity of the developer, as he can revert to previous versions very easily, compare the different levels of commit and view the history of all changes made, however minor. The fact that Git is wholly decentralized only enhances the autonomy and freedom for developers.
2. GitHub: power to the developer
GitHub is THE collaboration tool of choice for many corporate organisations offering a web-based repository hosting platform over Git. It can be used in its cloud-based or on-premise form. First and foremost, it organizes and manages teamwork, but also provides a graphical Web interface to Git as well as delivering additional features including a comprehensive code validation workflow.
3. What about IBM i?
Why would you store your RPG or COBOL sources in Git/GitHub? What are the advantages over and above the change management tools traditionally found in IBM i environments? Is this even conceivable for the many “heritage” IBM i applications that are still running the world’s most critical business operations today?
YES! Without a shadow of a doubt.
In my job modernizing IBM i development processes and environments I’ve come across many IT professionals who are still sceptical even today. IBM i developers are bizarrely in most respects both seen as the inventors of DevOps (with their structured change management and deployment processes, designed for minimal risk, some would say that RPG developers invented DevOps), and yet they can still be the most reticent to change. To some, the Git culture can seem a generation (or two) away. To these sceptics I would say: “Aren’t IBM i applications precisely designed to serve the business? Don’t their users have increasingly pressing requirements? Why on earth would you leave them aside?”. Git is all the more relevant to IBM i applications knowing that these precious and trusted applications usually encapsulate the most critical parts of the information system and often represent the unique competitive advantage on which IBM i companies have built their successful business models around.
4. Git myths to dispel – the technical ones
In your mission to bring Git benefits to IBM i, you will no doubt come across some technical questions that you will need to counter. Some classic examples:
Q1. “But can IBM i applications – with their “proprietary” file system – actually fit into a standard tool like Git?”
Yes, they can! IBM has greatly contributed by modernizing the IBM i platform over the years. And the remaining integration work to make Git enterprise-ready on IBM i has been developed by ARCAD Software. With ARCAD’s Git integration you can manage 100% of your IBM i application components as “sources” in Git (and yes, even the so-called “sourceless” objects).
Q2. “IBM i applications are just too large to be managed in Git”
Quite the opposite! Because Git works by “delta” changes, it is particularly well suited to high volume applications such as those on IBM i.
Q3. “OK so maybe there are no technical obstacles to Git on IBM i – but what is in it for my team?”
The return on investment (ROI) of a DevOps approach is well documented and universally understood. But over and above the ROI, both Git and Jenkins bring measurable benefits to the development team itself.
1. More developer “value-add” time available
When used together, the DevOps automation tools Jenkins and ARCAD Builder attain 100% automation of the build (recompilation) process. This frees developers from tedious repetitive and often manual tasks such as integrity checks and script maintenance. Developers can focus their time on their real job of creative and value-add tasks to innovate and support the business!
2. Understanding other people’s code
Which developer on the planet hasn’t racked his brain to understand why this chunk of code has been written this way? And looked around to find someone to explain why? (Only to discover that the author left a while ago and never thought that comprehensive documentation would be necessary!)
This kind of situation is common and a huge potential “time waster” and bottleneck in the acceleration of your development processes. It is also one area where the collaborative tools like GitHub deliver the biggest benefit.
GitHub and others let you look back in time, down to the very finest detail, to understand the reasons behind that code and why it was written that way. By understanding the logic better, your code changes are certainly faster and far less likely to introduce hidden defects.
Also, with GitHub, code review mechanisms are built-in to the standard workflow. Peer review becomes an integral part of development. All exchanges between developers and the explanations they share are safely stored for future reference. This conversational history is rich code “intelligence” for any future developer…
To prove the point, let’s just consider how open source developers work. Without even knowing each other, and often geographically distributed to the far-flung corners of the globe, they develop and collaborate on highly complex projects in a totally decentralized way. Git makes all this possible. It’s no accident that there are literally millions of open source application repositories on GitHub!
3. “Pull Request”: a validation workflow for code merge
The other big GitHub contribution to DevOps is the validation workflow for the merging of code branches: the so-called “pull request”. DevOps is all about automating the non-creative parts of software development. That means everything except the art of coding itself!
The greater the automation, the lower the risk of error, and the more secure your system. A fully auditable process cures the compliance headaches of pre-DevOps days.
5. How can ARCAD’s team help you?
With all these advantages – I hope I have been able to dispel some of the myths about Git, and helped you take one step further towards embracing Git on IBM i. ARCAD’s customers see our work together as an essential element in their DevOps success on IBM i. The deep Git integrations and specific IBM i Git methodology that come by default with ARCAD for DevOps render these industry-standard tools workable on IBM i – with a custom Git development environment friendly enough to onboard the most reticent of IBM i die-hards… ARCAD’s hybrid model even allows your 5250 developers to work alongside your RDi developers, all sharing the same powerful versioning features of Git!
A clear advantage behind ARCAD when implementing Git and Jenkins on IBM i is undoubtedly ARCAD’s unique metadata repository architecture. Every developer, operator, tester and IT manager derives value from this repository as it is updated in real-time as developers code. The dependency knowledge contained within the ARCAD repository delivers massive automation potential to minimize risk and cost right across the software development lifecycle:
- Early detection of defects with dependency-based Test Automation eliminating all repeat effort in the QA process
- Rapid debug / re-work / re-test / re-deploy effort driven by detailed cross-reference knowledge
- Automated Peer Review / code quality checking to detect quality violations and security vulnerabilities at the very point they are introduced
- Stable, Seamless and Proven Integrations with industry standard, cross-technology enterprise tools including Git, Jenkins, Azure DevOps, Jira and ServiceNow.
Empower your IBM i teams – and see for yourself the unbridled potential of Git on IBM i, check out our “Git Ahead” Webinar below…
Michel Mouchon
CTO and VP of Strategy
Michel Mouchon has been working on the IBM i for over 30 years as a Developer, Manager and Technology Strategist. Michel drives the vision of ARCAD’s solutions across 350 leading IBM i development teams. ARCAD created DevOps tooling over 10 years ago to satisfy the demands of the largest clients of IBM Rational Team Concert (the first SCM tool to be able to branch and merge code on IBM i through a Git-like interface). Over 10 years and many global implementations, Michel and his team have perfected the technology and now can boast over 30 world-class Git implementations with ARCAD on IBM i. ARCAD continues to perfect the most advanced and powerful software development tools for the IBM i delivering scalable Git, Jira and Jenkins solutions for global IBM i clients of all team sizes.
REQUEST A DEMO
Let’s talk about your project!
Speak with an expert