Rocket Gits Hip to Emerging IBM i Tech
January 31, 2018 Alex Woodie
When it comes to managing traditional IBM i development environments, Rocket Software has its bases covered. But as younger technologies and younger developers find their way onto the platform, Rocket found that it had some work to do to ensure that DevOps – or application lifecycle management (ALM), if you like — runs as smoothly as its enterprise customers expect. That’s the case with the vendor’s announcement today around Git.
Rocket Software today announced that it’s now supporting Git with the Aldon Lifecycle Manager (Enterprise Edition), the company’s ALM product for open systems environments like Windows, Linux, and Unix. The new version of LM(e), as the product is called, enables organizations to incorporate their developers’ use of the Git version control system into their overarching ALM strategy (or DevOps if you like).
This news is relevant to IBM i shops because LM(e) is also used to manage the ALM (DevOps) activities that occur around emerging open source technologies, such as Node.js, Ruby, and Angular, on the IBM i platform. So while IBM i shops that use traditional development languages like RPG and COBOL that utilize the traditional QSYS storage systems will want to use Aldon Lifecycle Manger (IBM i Edition) – also called LM(i) – they will want to use LM(e) if they’re working with newer languages that heavily utilize the Integrated File System (IFS), which of course is the IBM i platforms’ Windows-like hierarchical storage system.
It’s all about staying on top of changing industry trends, says Mitch Hoffman, a senior account executive with Rocket. “When a developer has a choice, they prefer the branching of Git,” Hoffman says. “When I go into my customer base, that’s what customer are using. That’s what the millennials and the kids out of school have learned. They’re not learning Subversion. They’re learning Git . . . It won the war over Subversion.”
Git is a distributed version control system first released 13 years ago by Linus Torvalds, the creator of Linux. Torvalds famously became frustrated with other version control systems that couldn’t scale to meet the needs of his globally distributed team of Linux developers, so he created Git to function as one.
With all the Linux contributors using Git, it’s no surprise that the version control system would go on to become enormously popular in the open source community (although perhaps Torvalds’ creative ingenuity also had something to do with it). As the open source movement gained steam over the past decade, Git – along with GitHub, a hosted cloud-based implementation of the version control systems – would become defacto standards in the emerging development stack.
IBM brought Git to IBM i with the release of IBM i 7.3 early in 2016, and by all accounts the software has been a big hit, particularly among the younger folks who are using newer languages like Ruby, PHP, Angular, and Node.js to develop Web applications for IBM i.
“The developers are the ones who want to use Git,” says Dan Magid, Rocket’s vice president of modernization, DevOps, and HA solutions. “They’re using Git to do their development. They’re using it for its distributed repository capabilities. But once it’s done in development and you’re now ready to move through QA [quality assurance] and client-acceptance testing, and moving it through that process, that’s where they’re relying on us.”
There’s often an inclination to shortcut established procedures, particularly among younger folks who are new to an organization. This is as true in baseball and oil painting as it is in enterprise software development. While there may have been a day when it was fine to compile source code straight into production, those days are long gone in today’s highly regulated IT environments.
“We want to say, look, use whatever version control tool you want to use, because developers like to have that kind of choice. They want to use what they’re used to, what they like, so use whatever you want,” Magid says. “But when it comes to getting this stuff into production through some sort of auditable and complaint process, that’s what we’re good at. That’s really our core value proposition, how you control that whole move-to-production process.”
With the new release of LM(e), customers can connect source code contained in the Git repository into the ALM (DevOps) processes managed by Rocket’s software. When the first bit of code is ready to be promoted into production, an API call to LM(e) triggers the beginning of the process. Magid describes what happens then:
“We go to the Git repository,” he says. “We get all the necessary source code. We push it out to the build servers. We run the build, and then we pull the build results back into our repository and deploy it to everywhere where it needs to run. And from that time forward, we manage it as it moves through the lifecycle.”
IBM i shops will still need LM(i) to push any code that was developed in a Git repository out to other IBM i servers, Magid says. “At end of day, once get out of Git, you still need to be able to do compiles,” he says. The Rocket software still needs to know what the library lists are. It needs to know about dependencies, how to assign the security, and how to deploy and install the software, he says.
But all this stuff – including the integration between LM(i) and LM(e) – will be handled under the covers, Magid says.
“Our objective is that an operations person doesn’t care what the underlying architecture is where things are going,” he says. “They just know that project 1-2-3 is ready to go, and here’s what it does, and I need to go ahead and move that. Then we worry what are all the target platforms.”
Eventually, Rocket plans to allow IBM i shops to use LM(i) to manage native RPG and COBOL code stored in the Git repository right alongside the source code for languages like node.JS, Python, and PHP that are stored hierarchically in the IFS.
“The next release of our Git integration is going to be for native IBM i code,” Magid says. “So we will handle the whole process of getting stuff from hierarchical into source members and libraries as part of our process….That’s our direction. Right now it’s just for hierarchical stuff. But it will soon be for both.”
In addition to the Git integration, the new release of LM(e) features a new user interface developed in Angular and node.JS. This new interface is also part of Rocket’s plan to integrate LM(e) and LM(i), Magid says.