By Jeff Tickner & Olenka Van Schendel<\/h3>\n<\/div><\/div><\/div>Back in the day, application deployment typically originated from a central server connected to all target systems. However, in today\u2019s highly security-conscious world, there’s a growing demand for deployment to production environments that are entirely segregated from development, operating independently on an isolated network. <\/b> This has become a fundamental security \u201cbest practice\u201d aimed at safeguarding critical systems and maintaining the integrity of business operations.<\/p>\n
Yet wherever you are on the DevOps journey, deploying applications to \u201cisolated\u201d environments poses unique challenges<\/b>, especially for IBM i platforms. In the long and distant past, this was accomplished using physical media like tapes and DVDs in a kind of \u201cslow motion\u201d. However, in a contemporary fast-paced digital landscape, new options have emerged, bridging the gap between traditional and modern deployment methods.<\/p>\n<\/div>Summary<\/h2>\n\n- The unique challenges of application deployment on IBM i<\/a><\/li>\n
- Taking advantage of technology from the open systems world<\/a><\/li>\n
- Working with high security \u201cisolated\u201d environments.<\/a><\/li>\n
- Leveraging generic artifact management systems on IBM i<\/a><\/li>\n
- Conclusion<\/a><\/li>\n<\/ol>\n<\/div><\/div>\n
1. The unique challenges of application deployment on IBM i<\/h2>\n
Deploying applications on the IBM i platform requires special attention due to its unique architecture and operating environment.<\/b> And, since many IBM i applications are critical to business operations, production updates often need tailored and optimized processes specific to IBM i.<\/p>\n
Those new to the IBM i platform may be surprised to learn that:<\/b><\/p>\n\n- IBM i applications are usually huge <\/b>and are invariably deployed by \u201cdelta\u201d<\/b> (given the volume, it is not feasible to replace the full set of objects).<\/li>\n<\/ul>\n
\n- IBM i applications typically overlay massive databases<\/b> that impact the upgrade process and may require specific management such as a \u201cwhile active\u201d promotion to prevent excessive downtime for end-users.<\/li>\n<\/ul>\n
\n- IBM i applications are often business-critical<\/b> demanding a high level of security that restricts access and availability for update.<\/li>\n<\/ul>\n
\n- The IBM i operating system is object-oriented<\/b> 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!))<\/li>\n<\/ul>\n
\n- Thanks to this object orientation, security is hard-wired<\/b> 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)<\/li>\n<\/ul>\n
\n- Invariably, IBM i applications have strong dependencies<\/b> on middleware\/frontend applications meaning that deployment must be tightly synchronized to avoid inconsistencies in production.<\/li>\n<\/ul>\n
In addition, the deployment of IBM i artifacts can be complex and require special instructions<\/b> 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.<\/p>\n
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!<\/p>\n<\/div>
<\/div>\n2. Taking advantage of technology from the open systems world<\/h2>\n
On distributed systems, artifact repositories like JFrog Artifactory or Azure Artifacts are widely used<\/b> to address the \u201cenvironment disconnect\u201d. 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.<\/p>\n
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.<\/p>\n
The accessibility of standard artifact management tools from IBM i became a driving requirement behind DROPS, ARCAD\u2019s multi-platform Release Management solution.<\/a><\/p>\nThe key was the openness of the DROPS solution<\/b> 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<\/b> which allows easy adaptation to specific customer DevOps workflows.<\/p>\n<\/div><\/div><\/div>![\"Diagram](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2024\/06\/diagram-drops-i-environment.png\" "\\"diagram-drops-i-environment\\"")
<\/span><\/div>Example: DROPS configuration in isolated IBM i environments (with ARCAD\/Azure DevOps)<\/em><\/p>\n<\/div>
Back in the day, application deployment typically originated from a central server connected to all target systems. However, in today\u2019s highly security-conscious world, there’s a growing demand for deployment to production environments that are entirely segregated from development, operating independently on an isolated network. <\/b> This has become a fundamental security \u201cbest practice\u201d aimed at safeguarding critical systems and maintaining the integrity of business operations.<\/p>\n
Yet wherever you are on the DevOps journey, deploying applications to \u201cisolated\u201d environments poses unique challenges<\/b>, especially for IBM i platforms. In the long and distant past, this was accomplished using physical media like tapes and DVDs in a kind of \u201cslow motion\u201d. However, in a contemporary fast-paced digital landscape, new options have emerged, bridging the gap between traditional and modern deployment methods.<\/p>\n<\/div> Deploying applications on the IBM i platform requires special attention due to its unique architecture and operating environment.<\/b> And, since many IBM i applications are critical to business operations, production updates often need tailored and optimized processes specific to IBM i.<\/p>\n Those new to the IBM i platform may be surprised to learn that:<\/b><\/p>\n In addition, the deployment of IBM i artifacts can be complex and require special instructions<\/b> 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.<\/p>\n 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!<\/p>\n<\/div> On distributed systems, artifact repositories like JFrog Artifactory or Azure Artifacts are widely used<\/b> to address the \u201cenvironment disconnect\u201d. 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.<\/p>\n 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.<\/p>\n The accessibility of standard artifact management tools from IBM i became a driving requirement behind DROPS, ARCAD\u2019s multi-platform Release Management solution.<\/a><\/p>\n The key was the openness of the DROPS solution<\/b> 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<\/b> which allows easy adaptation to specific customer DevOps workflows.<\/p>\n<\/div><\/div><\/div> Example: DROPS configuration in isolated IBM i environments (with ARCAD\/Azure DevOps)<\/em><\/p>\n<\/div>Summary<\/h2>\n
\n
1. The unique challenges of application deployment on IBM i<\/h2>\n
\n
\n
\n
\n
\n
\n
2. Taking advantage of technology from the open systems world<\/h2>\n
<\/span><\/div>