ARCAD Upgrades DevOps Software For IBM i
February 8, 2017 Dan Burger
For IBM i shops that have been using change management software for years, DevOps looks very familiar. Both improve quality and lower risk. And both make use of a framework and collaborative achievements. The major distinction for DevOps is that the collaboration involves a much wider universe of contributors. It takes into account other IT platforms and blows up the individual siloes by integrating tools and processes. And it further integrates IT and business with incremental improvements and enhancements continuously tested and put into production.
ARCAD Software, a company with a history in IBM i change management, includes DevOps in its product roadmap. In mid-2016, it introduced new software called DROPS, which is designed to support continuous integration and delivery of new applications–including mobile and open source code management–and new operations by providing release status information. ARCAD CEO Philippe Magne, describes DROPS as “the most critical phase of the development process.”
Since that introduction, product enhancements have been added and it’s time for an IT Jungle update.
DROPS software is not specifically tied to the IBM i platform. Platform specificity is not found in DevOps. DROPS, however, does support IBM i and that support is missing in stack-specific tools with DNA inherited from other platforms. That’s a problem when integration and collaboration are your goals.
DROPS is a single tool that allows companies to orchestrate release management across multiple platforms that include z, i, Linux, Windows, Unix. It promotes change agents across those systems from a single tool set that can be automated. It also automates and streamlines application testing of cross-platform processes, another bottleneck that DevOps targets for elimination.
Quality assurance is not what DROPS was designed to do. Its purpose is to automate deployment. ARCAD has other tools to ensure quality.
Because of the multi-platform aspect of nearly all IT development, the advantage of a single tool that can pick changes in different platforms and eventually push everything into production is obvious. It’s basically a synchronizing activity. The must handle the sign-off from the various groups involved. Some of those groups will be development oriented and some will be business oriented.
Managing the deployment processes with DROPS is accomplished through a visual interface on a Web-based console. Deployment stages are visible in real time and a deployment log is provided for validation. Processes are tracked on a configurable deployment map, which can contain several environments.
Deployments can be executed sequentially, in parallel, or in dependency order. An application can be fully deployed in a single action or by cumulative patches. In each case, there are compatibility checks with previously deployed releases.
After the deployment process, DROPS adds the capability to manage the installation of delivered software. Users have the choice of separating deployment and installation phases. Warehouses are used to contain releases and to defer installations if necessary. Installation execution is logged in a centralized journal, which provides the traceability that’s required by many regulatory compliance mandates. Rollback capabilities are also built in.
The features ARCAD has slipped into DROPS during the past six months include templates that can be shared by multiple deployment processes; a reporting module based on BIRT that allows he users to access deployment activity KPIs; additional scripts for the script library; and a module that allows an administrator to remotely install or upgrade all the DROPS agents from the DROPS server.
The new process templates were designed to speed the creation of new processes and reduce maintenance. The reporting module includes predefined reports that analyze deployment activity. More than 40 script library enhancements were added to the script library. Included are scripts to rollback database updates.
Floyd DelMuro, business development manager for ARCAD, has first-hand experience working with IBM i shops that are examining cross-platform integration processes. He describes DevOps as having three components: people, processes, and tools.
“People are the major component. They are the stakeholders. DevOps is a way to get all the stakeholders to the table. The process work as a framework. The tools reinforce the process–guidelines and best practices–through automation. It means there is less manual intervention and less risk. Common tooling and common processes that are repeatable are the goal,” DelMuro says.
His job puts him in contact with cross-platform development, early adopter teams in the IBM i community. He says there are more of those companies now than just a few years ago, and that those companies have made commitments to the platform and are getting antiquated tooling practices out of their way.
Although client names can’t be used for publication, DelMuro says ARCAD is in discussions with a company that is interested in integrating a large IBM i, a mainframe, plus Windows and Linux systems. There are 45 IBM i partitions and WebSphere running on multiple Linux servers. The company wants building, testing, and release management without having four separate siloes.
“This project looks like it will start with the release management component deployed and synchronized across multiple platforms using a single tool for management,” he says. “But today our discussion was focused on the use cases for running the COBOL on the mainframe.
“We’ve worked on projects before this one that have accomplished multi-platform release management involving i, mainframe, Linux, and Windows. Every case is different, but the similarity is that as teams get better at using the new tools, they are shortening their release times, becoming more reliable, and having fewer issues.”
A YouTube video pertaining to DevOps and continuous application deployment is available here.