High security IBM i application deployment: how to manage “isolated” environments?

1. The unique challenges of application deployment on IBM i

Deploying applications on the IBM i platform requires special attention due to its unique architecture and operating environment. And, since many IBM i applications are critical to business operations, production updates often need tailored and optimized processes specific to IBM i.

Those new to the IBM i platform may be surprised to learn that:

• IBM i applications are usually huge and are invariably deployed by “delta” (given the volume, it is not feasible to replace the full set of objects).

• IBM i applications typically overlay massive databases that impact the upgrade process and may require specific management such as a “while active” promotion to prevent excessive downtime for end-users.

• IBM i applications are often business-critical demanding a high level of security that restricts access and availability for update.

• The IBM i operating system is object-oriented meaning each individual object type possesses specific properties defining (amongst other things) the way it should be deployed and which specific actions must be invoked (IBM i deployment requires much more than just placing a file in a directory!))

• Thanks to this object orientation, security is hard-wired into the operating system (a program is not a file; it is a program object. A simple file cannot be transformed into an executable object)

• Invariably, IBM i applications have strong dependencies on middleware/frontend applications meaning that deployment must be tightly synchronized to avoid inconsistencies in production.

In addition, the deployment of IBM i artifacts can be complex and require special instructions that may apply to all deployments or be unique to specific deployments. A common deployment use case is to initialize new columns that were added to a table; obviously this is a one-time action when the table change is deployed and that is also contained and managed in the specific package.

All said and done, the overriding goal we have on IBM i when it comes to deployment automation is how to reconcile two seemingly opposite objectives: on the one-hand, how to ensure a highly secure and stable production environment, while at the same time, delivering continuously to the business, with all the benefits that a true DevOps approach brings!

2. Taking advantage of technology from the open systems world

On distributed systems, artifact repositories like JFrog Artifactory or Azure Artifacts are widely used to address the “environment disconnect”. However, like many industry-standard DevOps tools, these artifact repositories cannot be used directly from IBM i in their raw form. They demand that the packaging of the actual content to be deployed be in an IBM i consumable format and contain the proprietary metadata needed.

In the IBM i world, a common package is a SAVF containing objects to deploy. For secured lifecycle management, there must also be identifiers and a manifest to permit content validation before deployment.

The accessibility of standard artifact management tools from IBM i became a driving requirement behind DROPS, ARCAD’s multi-platform Release Management solution.

The key was the openness of the DROPS solution that allowed us to integrate with pipeline process and CI/CD tools. This openness, through extensions, plugins, CLI and API, allowed us to also benefit from artifact management tools. Further, the DROPS solution is also openly scriptable which allows easy adaptation to specific customer DevOps workflows.

Example: DROPS configuration in isolated IBM i environments (with ARCAD/Azure DevOps)

3. Working with high security “isolated” environments

The challenge when we have a complete disconnect between the development and production environments is a regular one-step deployment is not possible. Tools do NOT have access to the packaging and ALM metadata at the same time on both sides. The architecture in such a case is to use the artifact repository as a secure ”vault”, accessible from both development and production environments:

• First, as developers produce code, a dedicated DROPS server in the development domain will create the package, including components to deploy, and the required metadata, including any IBM i commands unique to a specific deployment (such as adding new columns)

• This package can be independently validated for content and deployment commands; and ARCAD offers an automated code review tool to streamline this action

• Then, DROPS will deliver the package into the secured artifact repository

• Over in the production environment, a second DROPS server will import the package to deploy from the secured vault

• Release managers then use this second DROPS server to deploy the package to production activating any automation and workflow validation processes in place.

4. Leveraging generic artifact management systems on IBM i

Secure and reliable deployment to isolated targets depends on a tight integration between the (generic) artifact repository and the IBM i DevOps technology used.

Most legacy change management tools were designed when this level of security and almost physical separation of environments was not a requirement. Modern release management tools integrate this with something like a 2 (or more) cushion “billiard shot”.

Given the high frequency of deliveries in a modern DevOps setup, deployment processes must become far more efficient.

To overcome this challenge, DROPS has the unique advantage of full access to the IBM i application “metadata” (or dependency knowledge) that is maintained in real-time by the ARCAD for DevOps tools.

Thanks to this metadata, with DROPS, we can use a standard artifact repository (JFrog, Azure Artifacts, Nexus, DROPS artifact repository, etc.) in a customer’s IBM i workflow and directly verify that the artifact received is the correct release, the correct version and the correct manifest when importing it back into the DevOps workflow. We can validate the imported package against the expected package and thereby guarantee the integrity of the deployment.

With DROPS, the packaging of the IBM i release is managed automatically, and inter-dependent IBM i and front-end artifacts are deployed synchronously to ensure the integrity of the full-stack application. During the actual deploy of the IBM i artifacts on the target system ARCAD manages locks and checks for any issues on the target box, like level checks or ILE signature errors. This is just in case the target box doesn’t match the source box exactly. If a problem is identified the deployment is stopped, and since we are synchronously deploying the front-end artifacts, that deployment is stopped also. This avoids that bad Monday morning when the UI is trying to feed 10 characters into a 5-character column that didn’t get updated Sunday because of a problem!

DROPS also allows customization of the release identifier so external identifiers, like a work item, can be used. This makes it very easy to track IBM i deployments from standard project management systems such as Jira and ServiceNow.

This is all possible because ARCAD has over 30 years of experience in deploying IBM i artifacts and additionally synchronous deployment of cross-platform artifacts for 10 years and has gone through many evolutions to provide this functionality.

Conclusion

Now we see that ARCAD DROPS provides both the packaging and deployment for IBM i artifacts with a continuous process across isolated environments. This allows any means of transfer of the package to the target domain for staging of deployment. This could be physical transfer if the domain is truly separated, or more common in our customers, a stateful replication of the artifact between networks domains, whatever is used on the open systems side to provide the needed security.

As always when we discuss workflow and tools with the IBM i team, we recommend a unified toolstack and workflow shared with the open systems team, leveraging internal expertise for both implementation and ongoing maintenance of the DevOps workflow.

The openness of DROPS tools breaks traditional barriers between IBM i and open systems to truly achieve “the best of both worlds”.

Coming soon: equivalent DROPS deployment capability will soon be available for IBM z!