The ODM and DevOps Series

Article 4 – Deployment, promotion and traceability

This article in the fourth of the ODM and DevOps series, and will discuss how to deploy generated Rule Apps, promote them from one environment to another, and ensure the traceability of the deployment. It assumes that the reader has generated a RuleApp either from Source Code Control, as described in Article 2, or from Decision Center, as described in Article 3, and present various deployment and promotion options.

Deployment patterns

Five possible deployment patterns can be implemented with ODM.

Online Deployment: is a pattern in which a business user triggers deployment in Decision Center, which then directly communicate to an instance of Rule Execution Server to deploy the Ruleapp.

Custom Online Deployment: is a pattern in which a business user triggers deployment from Decision Center, however the deployment process is defined and owned by IT.

Offline Deployment: is a pattern in which a developer pulls a Rule App from Decision Center, then somehow transports it and uploads it to a RES instance.

Continuous Integration, Scripted Deployment: is a pattern in which a CI pipeline continuously builds Rule App, that then get deployed to a RES through a script.

Continuous Deployment: is a pattern in which a dedicated deployment tool takes care of the deployment management.

These patterns are described in greater details in the following sections.

Online Deployment

This is the simplest and most intuitive pattern. In Decision Center, a developer can create Target Servers, which define how Decision Center can connect to various Rule Execution Server instances. These definitions contain the URL and credentials that are needed for this access, and these can be hidden so that the rule author using a server refers to it by its name without being able to see the actual credentials.

Then the rule author simply chooses a Deployment Configuration, clicks the Deploy button, and Decision Center will take care of the communication with the selected target server to deploy the generated RuleApp. The process is completely automatic and produces a Deployment Report that shows its outcome, including the version number that has been allocated to the RuleApp based on previous deployments that already occurred on that server.

This a simple way for developers to empower the business analysts writing the rules. It is however recommended to only proceed this way for various test environments, and use one of the following patterns for deployments to higher environments (Eg: production).

Custom Online Deployment

This pattern is similar to the previous one, and from the standpoint of the Business Analyst authoring the rules, no difference can be perceived. It is however different from an IT standpoint.

In this pattern, a developer will configure the deployment process the way they need it, following the corporate guidelines and procedures already used for deployment of other types of artifacts. Then the developer can use the Business Console customization feature (described here https://www.ibm.com/support/knowledgecenter/SSQP76_8.10.x/com.ibm.odm.dcenter.custom/topics/con_customizing_bc_ui.html ) to add a “My Deploy” button in the UI. The code triggered by that button is the one needed for the standard corporate deployment process. When Decision Center invokes it, it will pass, as a parameter, the currently selected Deployment Operation. This way, the code can retrieve the RuleApp that the rule writer wants to deploy, as well as the target server. Those are the basic ingredients that this code needs to identify the intent of the deployment request, and thus how to perform it.

The advantage of such a pattern is that the IT is still in control of the deployment process, and can define it as they see fit, adhering to corporate specification. However, the Business Analyst is still empowered since he can decide when to kick off the deployment. In other words, this very powerful pattern leads to a deployment process that is IT-owned, but triggered by the Business.

Offline Deployment

In this pattern, deployment is achieved in a two-step, manual process. It does not require direct connectivity from Decision Center to the target Rule Execution Server instance.

When the rule writer is done authoring, he signals it to the developer in charge of administering the runtime environment. This can be achieved with the usual means of communication (email, phone call, etc.), or this can even be automated by building a notification connector that subscribe to specific events, for example tagging of a release with a snapshot name in Decision Center, and sends a message to the developer in charge.

This developer then needs to download the RuleApp from Decision Center, either by using the UI (Deployments Tab ->select a Deployment Configuration -> hit the Deploy button -> select “download RuleApp Archive”), or through the API, as described in the third article of this series.

The developer then transports the RuleApp archive to the runtime environment, and uploads it to the target server. Again, he can do so either using the UI (Explorer Tab  Deploy RuleApp Archive button), or with the following REST API

POST /ruleapps

This process is simple, and the fact that APIs exist for the two steps helps a developer to write automation, however, it requires the developer to manually manage the RuleApp archives, their versioning, their proper storage, and thus he has to keep track of the various actions taken to ensure traceability.

Note: using RuleApp with the embedded XOM feature helps greatly simplify the process, since the archive that is manipulated then becomes self-contained and thus easier to manage than in the case where the XOM needs to be handled separately.

Continuous Integration, Scripted Deployment

This pattern is well suited to the case where rules are stored directly in a Source Code Control System, as described in article 2 of this series.

When rules are stored in Decision Center (as described in article 3 of the series), it is still possible to build a script that extract out the source of the rules from Decision Center at regular intervals of time, using the exporting REST api:

GET /v1/decisionservices/{decisionServiceId}/export

Once the decision service has been exported and unzipped to the disk of the build machine, or once it’s been extracted from source code control, then a developer can write a build plan, for example in a build orchestrator tool such as Jenkins, Travis CI, Bamboo or equivalent, which leverages the build command, as described in “Using the Build Command” of the article 2 of this series.

This process allows compiling rules as part of a Continuous Integration pipeline.

The last step of the build plan can then be to upload the RuleApp to a Rule Execution Server instance, the same way as described in the “Offline deployment” pattern above.

This approach helps to realize the benefits of a Continuous Integration pipeline. In the previous pattern, the compilation of the rules is performed by the machine hosting Decision Center, thus diverting hardware resources away from serving the UI interactions. However, using this pattern, compilation of the rules is performed on the build machines, thus freeing Decision Center resources, and allowing for better scalability, since the Build Orchestrator can spread the compilation effort on several build agents.

Continuous Deployment

In the previous pattern, the Continuous Integration part is well handled, however deployment is left to the developer. This pattern is an improvement on this part.

Corporation policies often require the use of Deployment tools such as UCD (Urban Code Depoy), XL Deploy, Chef and the like. These tools are able to define configurations to co-deploy related artifacts. They also maintain an inventory of the artifacts deployed to various environments, and are able to maintain consistency, for example by adopting an all-or-nothing, transactional approach to deployment of sets of artifacts, or by rolling back to earlier versions to keep artifacts aligned. They often also manage promotion automatically under specific condition.

Using Urban Code Deploy, the easiest way to automate deployment is to leverage the “ODM Automation plugin”. Follow the instructions of this page to install it into UCD, and then ODM RuleApps can be manipulated as any other artifacts as part of your deployment configurations.

Promotion

Promotion here refers to the process of moving a RuleApp from a lower to a higher environment after it has successfully passed some gate condition, such as functional testing or performance benchmarking. Two approaches are possible.

The first approach requires the use of Deployment tools, such as mentioned in the “Continuous Deployment” pattern above. With such a tool, promoting is usually handled in a very easy way, the tool simply reapplies a previous deployment configuration to a higher environment, starting obviously from the same artifact version and binary (no recompilation happens, the tool feeds from the binary artifact repository).

The second approach, which is especially useful when no Deployment tool is used, consist in downloading a RuleApp from the Rule Execution Server in the lower environment, and uploading that same RuleApp to the RES of the higher environment. It is important in such a case to make sure to use the embedded XOM feature, which makes the management of the RuleApp easier, since it then becomes self-contained. The REST API for downloading a RuleApp from the RES has an optional parameter to specify that the XOM should be embedded in the RuleApp.

The sample code published in this repository https://github.com/pberlandier/ruleapp-promoter shows how to do this, even though it doesn’t leverage the embedded XOM feature.

Traceability

When various RuleApps have been deployed to several environments, it can become complex to keep track of what versions are in use where. Proper deployment tooling and governance practices are key. ODM can provide some help with RuleApp properties. A RuleApp carries along a list of properties which a developer can use to attach values to help with the governance. These properties can be set in Decision Center, and since they’re stored in the RuleApp, they can also be retrieved in Rule Execution Server, or viewed in the UI (in the Explorer Tab, upon clicking on a RuleApp). The RuleApp management API also can read and write those properties.

It should be noted that when a RuleApp is generated by Decision Center, it automatically defines some of these properties to show which source files and snapshot were used to generate that RuleApp, as well as the name of the person who generated it, the date, etc.

Conclusion

Putting in place a software factory is not an easy task, and as companies evolve in their journey, from simple Continuous Integration, to Continuous Deployment, then to DevOps, they need to be able to include all participants in software solutions. ODM offers API and support tools that allow to include decision artifacts in such a pipeline, as what shown in this series of articles.