Build and deployment process

To implement changes and fixes you must deploy your changes from your source code repository into your IBM® Sterling Order Management environments. To deploy your changes, use the standardized build and deployment process and strategies for deploying custom IBM Sterling Order Management assets. Incorrectly building or deploying your custom assets can result in data loss.

IBM Sterling Order Management build and deployment process

To implement new release changes or maintenance fixes within your IBM Sterling Order Management environments, use the following build and deployment process to implement changes. The deployment of any change must go through each environment, beginning with the development environment, the quality assurance environment, and then preproduction environment. After testing is complete within these environments, the change can be deployed into the production environment.

The following process uses the IBM UrbanCode® Deploy Selfserv tool for deploying changes for IBM Sterling Order Management.

Build

After a developer completes developing and testing source code changes for your IBM Sterling Order Management environments, the developer pushes the changes to the appropriate branch in your source code repository.
With all code changes completed and tested within the developer toolkit environment, your Release Manager requests that the developer builds the changes into a deployable package.
The developer creates the deployable package within your build server environment. The deployable package must follow the naming conventions, directory structure, and other technical specifications, that are expected by IBM Sterling Order Management.
After the deployable package is created in your build server environment, the developer, or System Integrator, transfers, or copies, the package to your drop server.
When you transfer a deployable package to your drop server, it is possible for the package to become corrupted. The IBM UrbanCode Deploy Selfserv tool routinely checks the drop server for new or changed versions of a package to import into CodeStation. If the IBM UrbanCode Deploy Selfserv tool locates and begins importing your new or changed package before the package is fully transferred to the drop server, the package can become corrupted.

To prevent the IBM UrbanCode Deploy Selfserv tool from identifying the package that is being transferred as a new or changed package, transfer the package in a temporary (.tmp) file format. After the file is transferred to the drop server, convert the file to the expected file format. For example, the deployable package for IBM Sterling Order Management must be a .jar file.

Tip: IBM Sterling Order Management on cloud allows SI users to build a common OMS custom runtime image that can be used across all IBM Sterling Order Management on cloud lower environments, provided the following conditions are met:

All the configurations (including IBMid) are same for both the environments. For example, if IBMid is disabled in all the lower environments, you can build a Sterling Order Management custom runtime image on DEV environment and deploy this package on QA and Master-Config.
There are no environment-specific microservice integrations such as Order Hub and IV (Inventory Visibility).
There are no environment-specific properties in the customer_overrides.properties file. For example, if you build a Sterling Order Management custom runtime image on an environment where Cognos is enabled by adding a property in the customer_overrides.properties file, you cannot deploy that image to an environment where customer_overrides.properties file does not contain such properties.

However, for preproduction and production environments, a dedicated custom runtime image must be built and deployed in each environment.

Deployment

When you, or your System Integrator deploy a package with the IBM UrbanCode Deploy Selfserv tool, the deployment process involves the following high-level steps:

You, or your System Integrator access the IBM UrbanCode Deploy Selfserv tool. Within the tool, you, or your System Integrator select the target application, component, and environment, and select to run following processes:
- For an IBM Sterling Order Management, select to run a process to build a new Sterling Order Management custom runtime that is based on a deployable package.
Notes: When deploying changes, your changes must be deployed into your development environment first. After testing is complete, you can deploy the package into quality assurance, preproduction, and then production environment. All testing must be successfully completed within one environment before the changes are deployed into the next environment.
(IBM Sterling Order Management) You, or your Systems Integrator selects to run another process for the target application to deploy the built customized runtime component version.
The deployable package or component version that you, or your System Integrator selected to deploy into an application or use to update an application is retrieved from CodeStation.
The deployment process then connects to the target environment and deploys the deployable package or component version within the target environment according to the settings that are selected within the tool.
- For an IBM Sterling Order Management, the process uses the selected runtime component version to replace the currently deployed runtime component version.
After the deployment is complete, you, your System Integrator, or another member of your development, implementation, or operations team must complete any required testing of the deployment. Depending on the target environment that a package is being deployed within, different levels of testing is required.
- For the development environment, you, your System Integrator, or a developer must complete unit and integration testing to verify that the deployment is successful. If changes are required, the developer must update the source code and rebuild the deployable package.
- For a quality assurance environment, your Quality Assurance Manager must assign testers to complete any required functional and system testing of the deployed changes. The testers must complete all quality assurance and performance testing to validate the deployment. If changes are required, the appropriate developer must update the source code and rebuild the deployable package and repeat the previous deployment steps.
  Note: During the testing process, IBM can monitor network traffic and monitor the CPU, memory, and disk usage if requested. You must open a service request to have IBM complete any of these monitoring operations during the testing process. If you need assistance from IBM for a successful deployment, this effort is billable through a separate statement of work.
- For a preproduction environment, your Quality Assurance Manager must assign testers to access your environment and validate that your environment and site is functioning correctly with the deployed changes.
- For a production environment, your Quality Assurance Manager must assign testers to access your environment tools and site to validate whether your web-based tools and site are functioning correctly with the deployed changes.
Note:
A new user with the loginid - "sysconnveruser" and a user group "SYSCONNVER" is provided by default with IBM Sterling Order Management. This user group and the associated user only have permission to resource ID - "YFSSYS00004O92", which authorizes the user only to access the MQ connection Validation servlet. This user is required by the Deployment Validation tooling used by OM Devops to verify that the application server can connect to the MQ server configured for that particular deployment. This user should not be deleted. However, it is recommended that the default password for the user must be changed and the same should be updated in the Verification User Password Environment property in the IBM UrbanCode Deploy Selfserv tool.

Deploying to a live production environment

For deploying changes into your production environment, you can continue to use the self-serve process when your production-ready deployable package or component version is available. Every deployable package or component version for your production environment must first be deployed and successfully tested within your development environment, quality assurance environment, and preproduction environment before the package is deployed into your production environment.

Important: IBM reserves the right to reject any code promotion that adversely affects the production environment. You are responsible for completing any retests of previously rejected releases.

During the deployment process for your production environment, a rolling restart of the application servers is done on the production instance. For deployments into other environments, the servers are stopped and then restarted after the deployment is complete.

Note: As part of deploying your changes, IBM verifies only that the IBM Sterling Order Management application services start successfully and that your server and store are available. You, or your Systems Integrator or SaaS Extensions Support Provider, are responsible for completing any other tests, such as verifying URLs work or browsing or searching your store catalog to ensure that all of your changes and customizations are displayed and are functioning correctly.