Realizing The Promise Of Cross Platform Development With VS Code

January 25, 2023

Jeff Tickner

An integrated development environment is like a tractor or a truck, or indeed any other kind of tool. There are farmers who want a tractor from John Deere or Ford or Massey-Ferguson, contractors who want a Ford or Dodge or GMC truck, and carpenters and electricians who use Dewalt or Milwaukee Electric or Makita cordless tools.

No matter the choice of tools, ultimately these blue collar workers are going to farm and build things, and the choice of tool should not interfere with that effort. White collar – or far more likely no collar T shirt – programmers are no different in having strong preferences when it comes to their IDEs. But the choice of IDE should not hinder developers as they create applications for the IBM i platform, and moreover, the choice of the VS Code IDE commonly used by developers working on Linux, MacOS, and Windows platforms should not stop them from developing code for the IBM i platform.

There is a lot of buzz around Visual Studio Code, which is the formal name of the open source spinoff of the Visual Studio IDE that Microsoft released to the world back in early 2015. VS Code is based on the Electron framework, which was made initially to create Node.js applications and has the same editor that Microsoft created at the core of its Azure DevOps tool for creating applications for the Azure cloud. VS Code can be the source code editor for C, C++, C#, Java, JavaScript, Go, Node.js, Python, Rust, Fortran, and other languages.

Importantly, VS Code integrates tightly with the Git code repository. And this is one of the secrets of VS Code’s success. Using the ARCAD integration with Git, any number of disparate IDEs can be used for IBM i software development, even within the same team. With ARCAD, a given developer can choose either Merlin, VS Code, Rational Developer for i (RDi), or even green screen PDM to make his code change via Git. Today, a new generation of programmers who use VS Code can create and deploy code for the IBM i platform without knowing anything at all about the IBM i platform itself.

Part of the magic behind the VS Code integration with the IBM i platform comes from an open source project called Code for i comprising plug-ins to VS Code that give developers access to IBM i language parsers and compilers – RPG, COBOL, CL – and allows code created within VS Code to be compiled on Power Systems iron. Now that your RPG or COBOL is in Git, how to you build? It’s easy – using the ARCAD Builder engine.

Additionally, VS Code is also a key element in the IBM strategy for IBM i development. Indeed, the IBM Merlin DevOps & Modernization platform for IBM i together with its integrated VS Code-compatible IDE has been designed for a modern hybrid cloud world with a browser-based UI. IBM uses ARCAD’s build engine for Merlin. Merlin is a strategic platform securing the generational transition for IBM i development and is key to safeguarding the future of today’s mission critical IBM i applications.

More and more features are being added to these VS Code-based solutions, including code coverage which tells you what portions of your code are actually running and which portions are not really executing as the application churns through its work. There is even support for a native IBM i debugger available in Merlin now.

With ARCAD’s integration of IBM i with Git as well as Jenkins continuous integration/continuous deliver automation, and Jira bug tracking tools, we have been bringing the IBM i developers into the same kind of environment and DevOps process that the open systems people have been using for a long time.

But here is the interesting thing.

When we started down the road with Git, so many years ago, we assumed that we would get traction with small, private companies that had the most flexibility and could adopt new things easily. But the exact opposite happened. The largest companies – banks and insurance companies – that had already adopted the DevOps approach and open source software had been waiting to adopt it for their IBM i platforms because they had already been using it for Linux, Windows, and Unix platforms.

Here is how VS Code integration with Git and IBM i integration with Git are a powerful combination for IBM midrange shops.

I’m implementing ARCAD for DevOps with an insurance company right now – obviously I can’t say who they are, but they are an Azure shop. They have their IBM i developers using RDi and they are excited that they can also choose VS Code as an IDE. As they roll VS Code out, aside from the parity on the IBM i platform, another benefit that they have is that the open systems developers on Azure can interact with the DB2 for i database, but they don’t know anything about it.

Previously, their process was to use stored procedures and user defined SQL functions to access data on DB2 for i. But because they have been siloed, the .NET developer would go into Visual Studio and create a description of the SQL function and then they would have to hand it off to the native IBM i developer, who would write it and put it in test. And then the .NET developer would check to see if it actually works the way they described the function. It’s a lot of back and forth and is very inefficient.

Now with the ARCAD integration with Git, the .NET developer can go into Visual Studio, and without doing anything special they can write a stored procedure directly and push it into the IBM i Git repository and it will be built on the IBM i platform. And they can test it and it doesn’t have to involve another developer. They can be autonomous. And they don’t have to have any access to the IBM i – they don’t even know what an IBM i platform is. They know how to write SQL and that is all they need to know.

As you might imagine, the native IBM i developers were at first a little reluctant to let this happen – being IBM i experts and wanting to ensure the quality of their applications, they liked having control, even though it wasn’t an efficient use of their time. But with ARCAD and Git we can ensure they have the control they need, by setting up a process in Azure that ensures that the developer can’t merge this into the main branch until a code review has taken place, leaving the IBM i developer to validate the code the .NET developer has produced. This is the process that the open systems developers have been using for a long time and with ARCAD we can transparently bring the IBM i developers into this agile way of working.

VS Code is becoming a standard because it is readily available and extensible. People add more functionality all the time. When the kids in college are learning how to develop, they normally use VS Code now. And when they take their first job, they can now be an IBM i developer without even realizing it.

The important thing to realize is that VS Code without ARCAD is not, of itself, sufficient for managing IBM i source. You also need the ARCAD layer (also shipped within Merlin) which automates dependency builds, static code checking, unit testing, regression testing, deployment, and so on. ARCAD has 30 years of experience managing code on directly on the IBM i platform, and while it is possible to do it without our Git implementation, it is just not going to be much fun and it is just not going to scale and it will have a lot of manual setup and intervention.

To learn more about the ARCAD solutions for DevOps on IBM i, join our Webinar series:

[IBM i Webinar] Demystifying DevOps on IBM i

Jeff Tickner is chief technology officer for North America at ARCAD Software.

This content is sponsored by ARCAD Software.

Realizing The Promise Of Cross Platform Development With VS Code – IT Jungle

Realizing The Promise Of Cross Platform Development With VS Code

RELATED STORIES