This is the third and final article in the series in which I describe Macro 4's transition to a modern Open DevOps environment for the mainframe. In the second post, I explained how we initially adopted Eclipse and a variety of related tools and the challenges we had to tackle along the way. In this article I'll explain how we have since switched to the VS Code IDE along with the likes of GitLab and Docker and to explain some of the advantages these solutions are delivering. I will also summarize our learnings from our journey so far.
Nearly every mainframe application nowadays has a web interface. Our web interfaces today are typically developed in the VS Code IDE, which is popular among modern developers today.
VS Code provides certain advantages because it's integrated with GitLab. One of these is the ability to do peer review asynchronously which can reduce bottlenecks and provides more flexibility for how teams are able to collaborate.
Another plus from using VS Code with GitLab CI/CD is the helpful graphical representation of the Build pipeline. This also has additional helpful functionality like the ability to add checklists so team members can physically confirm that they have completed a task, such as a code and design review, checked that there's error handling and added regression tests.
With GitLab there is more control and a high level of granularity to show that everything that needs to be done has been completed. For compliance purposes and to show that you have followed best practice, for example, it's not enough to say that you have done the peer review. You need to be able to demonstrate, for instance, that for a certain piece you did a peer review at 12:45 on 10th July. It's configured in the YMAL file.
Another benefit of using GitLab is that it allows you to integrate vulnerability scanning into the GitLab CI/CD pipeline. We use Mend for this. Because we're using open-source, Mend checks external components for any vulnerabilities. Every vendor is expected to use something like Mend to correct and mitigate their vulnerabilities when releasing code. What is helpful is that on the Commit, it can detect, for example, that the level of JQuery you are using has a vulnerability and automatically upgrade you to the level that doesn't. A developer might be coding with the version from three months ago, but this brings them up to date. It's part of the whole continuous delivery mechanism that you're able to do things more quickly and more easily.
Behind the scenes, GitLab uses Docker images at each stage of the build process to ensure there is no risk of leakage or exposure to sensitive information or resources throughout the process.
Automated testing with Galasa
On the testing side, Macro 4 successfully ran a proof-of-concept last year of Galasa, an open-source framework for end-to-end testing of applications running across multiple platforms (including z/OS). Galasa has since been fully accepted as an open mainframe project. I won't go into great detail here, but you can read more about our experience with Galasa here. One of our next steps is to build on our successful proof of concept and properly move to testing with it and have every developer drive the Galasa ecosystem for a number of our products' regression testing.
Conclusion: key learnings from our journey
For any organization who are in the middle of a similar journey of adopting open-source into their mainframe development environment here are some of the key learnings we have taken away that might be helpful:
- Embracing open-source is not as daunting as it might seem
- Use open-source tools wisely to implement projects in as generic a way as possible - you can't afford to have to rework things for each new release
- Look for ways the tools can save time and improve productivity as well as to make it easier to follow best practice and achieve compliance
- All developers will thank you because you've given them more time to code - where they're happiest - and less time doing the 'admin' type work
- Graduates developers will be familiar with this development stack because it will be similar to what they've used as part of their degree. That frees up time for them to learn your organization's code. They're productive faster!
- Developers transitioning from areas other than the mainframe can concentrate on learning the mainframe side of things because they will be familiar with the development stack - it's so intuitive - you should give it a go!
As a final positive takeaway, I wanted to highlight that IBM has recently announced that it is open-sourcing its Granite code models. These large language models (LLMs) are trained with code written in 116 programming languages, including Assembler. Enterprises whose developers are already using VS Code can install them as an extension and start experimenting with using Generative AI for code development, completion and refactoring. This is an exciting example of how technology is rapidly evolving and why it is hugely beneficial to integrate open-source solutions into your environment.
This blog was originally published on the IBM Community.