ODM DevOps
This chapter defines DevOps as the automated build, test, and deployment of decision services. It discusses two different patterns:
•IT Centric
•Business Centric
The reader might want to combine parts of each pattern to come up with their own design.
This chapter then discusses ways to implement these patterns using IBM UrbanCode™ Deploy and ODM APIs. The following topics are covered:
The following terminology is used in this chapter:
RuleApp The rule application archive containing runnable rule artifacts
Commit To check in code or rules to the source code repository
Publish To push rule artifacts from Rule Designer to Decision Center
Update To pull rule artifacts from Decision Center to Rule Designer
Deploy The deployment of a decision service for execution
Source Code Repository
An archive storing source code and business rules
ODM DevOps API The application programming interface to build and deploy RuleApps
9.1 IT Centric DevOps
The IT Centric DevOps pattern builds and deploys decision services in a pure development environment. The source code repository is the “golden” source of all artifacts, including business rules. The business can view but not change rules. If the business requires a change, it submits a request via the agreed change process, where it is assigned to
a developer.
a developer.
The developer applies and commits the change to the source code repository. DevOps builds the RuleApp and applies a series of automated and manual tests to progress the RuleApp through staging environments to preproduction. Finally, the RuleApp is deployed to Production at an agreed-upon time and day.
9.1.1 Advantages
The advantage of this approach is that all builds are contained within the IT governance domain. There is no parallel activity between business and IT. DevOps is a purely technical process in the hands of IT.
Both technical and business changes can be made in each build, so there is no distinction between business releases and technical releases.
9.1.2 Disadvantages
The disadvantage is that Decision Center is not used for rule changes, so it is not possible to deliver true business agility. Rule changes must go through the full IT build and test cycle, which could take months. This resource cost is likely too high for simple rule changes.
9.1.3 IT Centric DevOps sequence
IT Centric DevOps is initiated at the start of the initial release, or after the business has requested a change to the production release. The following sequence indicates whether the step is manual [M] or automatically scripted [A]. Step 5 can be omitted for technical changes not requiring business rule changes.
The Business Policy Change scenario includes the following steps:
1. [M] Rule Developer makes a Business change.
2. [M] Rule Developer unit tests the change.
3. [M] Rule Developer commits the change to the source code repository.
4. [A] Build Server triggers a RuleApp build.
5. [A] The RuleApp is deployed to the Rule Execution Server on the Test platform.
6. [A] The release is regression tested.
7. [A] The change is published to Decision Center.
8. [M] The business reviews the changes.
9. [A] If the business approves, the release is deployed to System Integration Test (SIT), User Acceptance Test (UAT), and Pre-Production.
10. [M] Acceptance tests are performed in each environment.
11. [A] If acceptance tests pass, the release is deployed to Production at an agreed-upon time and day.
This sequence is shown diagrammatically in Figure 9-1.
Figure 9-1 IT Centric DevOps
9.2 Business Centric DevOps
In this pattern, Decision Center is the “golden” source of rules.
Business Centric DevOps requires rule artifacts to be changed and approved in Decision Center using decision governance. Scripts automate the build and deployment of RuleApps from Decision Center. Technical changes are applied by a separate IT build process using Rule Designer. Technical changes require synchronizing to Decision Center.
9.2.1 Advantages
The advantage of Business Centric DevOps is that you get true business agility using decision governance.
9.2.2 Disadvantages
The disadvantage is that whenever there is a technical change, such as a change to the business object model, a separate build and synchronization process is required. If technical changes are infrequent this is not a problem.
9.2.3 Regular cycle: Business change
In this sequence, we assume that the initial release of the decision service has already been built and published to Decision Center, as described in the IT Centric DevOps.
The DevOps process is initiated after the business has completed making changes in Decision Center and the release has been approved by the business owner. The sequence is shown diagrammatically in Figure 9-2 on page 131. Step 8 can be omitted for most business rule changes.
Automatically scripted steps are indicated by an [A], and manual steps are indicated by [M]:
1. [M] Business creates and approves a release in Decision Center.
2. [A] The release approval is detected1, triggering a build on the Build Server.
3. [A] The Build Server uses Decision Center APIs to build a RuleApp from the approved release.
4. [A] The Decision Center APIs automatically run and verify business tests. This step is only required if the decision governance framework is not enforcing validation activities.
5. [A] The RuleApp is deployed to Rule Execution Server on the Test platform.
6. [A] The release is regression tested
7. [A] The release is deployed to System Integration Test (SIT), User Acceptance Test (UAT), and Pre-Production.
8. [M] Acceptance tests are performed in each environment
9. [A] If acceptance tests pass, the release is deployed to Production at an agreed time and day.
Figure 9-2 Business Centric DevOps: Business change
9.2.4 Irregular cycle: Technical change
This sequence begins when the business requests a change that it cannot make itself. This change is a technical change, and is assigned to a developer where it is governed within the IT domain. Technical changes to the XOM are outside the scope of Decision Center, and are committed to the IT source code repository. All other technical changes, such as changes to the BOM, are applied by the Rule Developer in Rule Designer, but published to Decision Center as part of the technical release, as shown in Figure 9-3 on page 132.
In a situation where both technical and business changes are required for a single release, we suggest two separate DevOps cycles, one to build and test the technical changes and a second to build, test, and deploy the business changes.
Automatically scripted steps are indicated by an [A] and manual steps are indicated by [M]:
1. [M] Developer synchronizes (updates) changes from Decision Center to their development platform.
2. [M] Developer makes technical change.
3. [M] Developer unit tests change.
4. [M] Developer commits XOM changes to source code control.
5. [M] Developer publishes technical changes to Decision Center.
6. [A] RuleApp built using Decision Center API.
7. [A] Business scenarios in Decision Center are run and verified.
8. [A] The RuleApp is deployed to Rule Execution Server on the Test Platform.
9. [A] The release is regression tested.
10. [A] The release is deployed to System Integration Test (SIT), User Acceptance Test (UAT) and Pre-Production.
11. [M] Acceptance tests are performed in each environment.
12. [A] If acceptance tests pass the release then needs to be deployed to Production at an agreed-upon time and day.
Figure 9-3 shows an Irregular cycle.
Figure 9-3 Business Centric DevOps: IT change
9.3 DevOps orchestration with UrbanCode Deploy
This section describes how to use the UrbanCode Deploy plug-ins to streamline your DevOps.
9.3.1 What is UrbanCode Deploy?
In a multi-software environment where ODM plays a small part in a big software stack, using a common tool to orchestrate the build and deployment is essential. This is where IBM UrbanCode Deploy (UCD) comes in.
UCD is a tool for automating application deployments through your environments. It is designed to facilitate rapid feedback and continuous delivery in agile development while providing the audit trails, versioning, and approvals needed in production.
For more information about UCD, see the IBM UrbanCode Deploy overview.
9.3.2 The UrbanCode Deploy ODM plug-ins
The ODM Source Config plug-in for UCD can be used to build a RuleApp archive for a decision service rule project in Decision Center, and then to deploy the RuleApp archive to a target Rule Execution Server. If you want to build a RuleApp archive to be deployed at a later point in time, you can use the ODM Source Config plug-in to build the RuleApp archive and store it in the UCD internal repository called Code Station.
Then, use the Deploy Rule Archive step provided by the ODM plug-in for UCD to deploy your RuleApp archive to a target Rule Execution Server of your choosing. This second approach enables a RuleApp to be built once but deployed to many target Rule Execution Servers.
The ODM Source Config plug-in for UCD is documented in the ODM source config tutorial.
The ODM plug-in for UCD is documented in the ODM plug-ins tutorial.
9.4 Suggested APIs for DevOps
This section acts as a technical reference for implementing ODM DevOps using the patterns discussed previously. APIs suitable for an IT Centric DevOps are indicated with an [I], and APIs suitable for a Business Centric DevOps are indicated with a [B].
•Building and Deploying decision services in eclipse [I]
Rule Designer provides a tool that automates the build and deployment of decision service rule projects.
•Synchronizing from Rule Designer to Decision Center [I or B]
You can use the synchronize Ant task to automate the publishing and updating of projects from Rule Designer to Decision Center.
Test decision services against tests suites held in Decision Center.
•Deploying decision services from Decision Center [B]
Deploy decision services from Decision C enter using the Decision Center API.
•Deploying decision services with REST APIs [I or B]
In a cloud environment, the REST APIs are the preferred way to Deploy decision services.
•Detecting a release is approved in Decision Center [B]
To detect that a release has been approved, create a custom session controller to override the onCommitElement. Verify that the release has transistioned from Ready for Approval to Complete:
9.5 Conclusion
In this chapter, we described two approaches to using DevOps. IT Centric and Business Centric. The Business Centric DevOps approach provides the greatest agility for most organizations.
Finally, we gave an overview of UrbanCode Deploy and provided references to ODM APIs that will help build your DevOps solution.
1 Use the custom session controller to detect a state transition from Ready for Approval to Complete on the release. See 9.4, “Suggested APIs for DevOps” on page 133.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.