Branching and merging
Although the focus of this IBM Redbooks publication is to work with the decision governance framework, readers should be aware that it is possible to have decision governance by using branching and merging. This chapter provides some details about how this can be achieved.
|
Note: It is important to note that one of the major benefits of using the decision governance framework is that it enforces a workflow that is designed to minimize issues with development, testing, and deployment. By using branching and merging, this workflow is not enforced in any way.
|
This chapter covers the following topics:
11.1 Branching and merging to manage releases
This section introduces concepts that might be familiar to technical users but not to business users. Branching and merging are concepts that are borrowed from source code control in software development.
11.1.1 Branching and merging
The underlying principle for branching and merging is that you must have traceability of what specific changes were performed. We want to answer the following questions:
•Which rules were changed?
•Which decision table values were changed?
•What were the changes?
•Who performed them?
In traditional software development, the answers to these questions are found in the source code control system (SCCS) used by the development team. Decisions are no different in that you must be able to have the answers to all those questions. In IBM ODM, that functionality is provided by the repository and is where branching shows its value.
Branching
To understand branching, you must understand the concept in more depth.
First, you must consider the structure of the decision services in packages and rules, which are like folders and files on a computer. The packages (folders) provide a structure for the rules (files). Creating a branch is like taking a copy of the packages and rules and putting that copy in a different location so that it does not interfere with the original copy. In this case, the original copy is called the main branch or trunk.
If you were to make a copy with directories and files on your computer, you could then make changes to any file within the copy without interfering with the original version of the files.
As you make these changes to the copy (the branch), you start enhancing some of the original documents and improving them. These changes are not part of the main branch, but it usually makes sense to have the main branch benefit from these enhancements. This is where merging comes in.
Merging
The goal of merging is to have the changes from a branch merged into the main branch so that the main branch can benefit from these changes. Merging changes is a complex task:
•Rules that were not changed in the branch do not need to be merged.
•Rules that did not exist in the main branch must be created.
•Rules that are deleted in the branch might need to be deleted in the main branch (you must be careful about this task).
•Rules that were changed in both the main branch (trunk) and the branch can be in conflict, which must be resolved.
Although it is a tricky task to perform, it is important that a merge is performed appropriately so that the rules remain consistent and behave according to expectations. After a merge is complete, there is no need for the branch anymore, because the change history is shown in the history of the rules of the main branch.
11.1.2 Snapshots
Snapshots capture the state of a branch at a specific moment in time. Figure 11-1 shows the snapshot icon in the Business Console interface.
You can create snapshots of the different kinds of branches. You can consult and compare snapshots and, if you have the appropriate permissions, rename or delete existing snapshots. When you consult a snapshot, you cannot edit its contents.
You can restore a snapshot so that it becomes the current state of a branch. To restore a snapshot of a release, you must be an administrator.
Deployment snapshots are a special type of snapshot, which can be automatically taken at the moment of deployment, that captures the state of the rules at the moment of deployment. Deployment snapshots appear in the list of snapshots, and can be used to redeploy but these snapshots cannot be restored to make it the current state of a branch.
Figure 11-1 The snapshot button in Business Console
11.1.3 Naming conventions
To make it easier to track branches and snapshots over time, it is important that you establish a naming convention for them so that you can easily identify the appropriate one you might be looking for.
For example, snapshots can simply be named Snapshot followed by the current date and time: Snapshot 2017-05-05 15h50.
Similarly, a branch could follow a naming convention by week: Week of 2017-05-05.
You also want to consider the names for regular changes, emergency changes, long running changes, and so forth.
11.2 Deployment events
In this section, we provide details about two main scenarios that concern the deployment events and the resulting versions of runnable services so that we can describe the branching and merging strategies’ ability to support these scenarios.
11.2.1 Scenario A: Single executable service
From the execution perspective, if your organization needs to only have a single execution service, then Scenario A might describe your requirements.
From an execution perspective, there is only one version of the decision service evolving at a time. The following events exist for this approach:
•Version 1 Deployed: This is the first executable version of the decision service and which is available for the client application to call.
•Version 1 Emergency Fix Deployed: If an issue were discovered in the rules in version 1.0, an emergency fix might be required and would be deployed.
•Version 1 Update Deployed: As time goes by, a normal update to the rules is deployed for execution.
Figure 11-2 shows the events and the available services over time.
Figure 11-2 Scenario A: Single executable service
From Scenario A, branching and merging needs to support the following scenarios:
•Day-to-day development
•Emergency fix development on a specific deployed version
11.2.2 Scenario B: Parallel executable services
From the execution perspective, if your organization needs to have two (or more) execution services running in parallel, then Scenario B might describe your requirements.
From an execution perspective, there are multiple versions of the decision service evolving at a time. The events described for Scenario A apply, but we also need to be able to support additional events. The following additional events are specific to this approach:
•Version 2 Deployed: This is the first executable version of the parallel decision service and which is available for the client application to call.
•Version 2 Update Deployed: As time goes by, a normal update to the rules is deployed for execution on the parallel service.
Figure 11-3 shows the events and the available services over time.
Figure 11-3 Scenario B: Parallel executable services
From Scenario B, branching and merging needs to support the following scenarios:
•Day-to-day development on Version 1
•Emergency fix development on a specific deployed version
•Day-to-day development on Version 2
11.3 Branching strategies
The following section provides details about some possible branching strategies that you can consider for your organization, or start from and adapt to fit your specific requirements.
For each strategy, you want to consider how well it supports the requirements from the two scenarios described in the previous section.
For each strategy, we look at the following information:
•How day-to-day simple changes are performed and managed
•How fixes on the currently deployed production version can be handled
•How major changes are performed and managed
•How well it supports development and fixes on multiple parallel versions deployed for execution
Although testing is an important part of the work required, in order to keep the test lighter, it is assumed that branches are tested successfully before being merged, and that the resulting branch after the merge is also tested successfully before any deployment takes place.
|
Note: In the diagrams that follow, the orange line shows the deployed version of the release in an execution environment. The labels shown in these diagrams are for demonstration purposes only, and do not reflect actual version numbers seen for the deployed ruleapp or ruleset.
|
11.3.1 Main branch with snapshots only
The most basic way to use the branching capabilities is to not use branches at all, and to only use snapshots to take pictures of the state of the rules in the main branch at a point in time.
It is assumed that after the first synchronization, a snapshot is taken, and that at each deployment, a snapshot is taken.
Scenario A analysis
This method of working can easily be used for day-to-day development on Version 1 as shown in Figure 11-4:
•Snapshots are taken regularly, especially before a deployment.
•There is a single branch, so no merging is required.
•The current state of the branch is deployed.
Figure 11-4 Main branch with snapshots only
Figure 11-5 on page 149 shows that an emergency fix requires more work:
1. Take a snapshot of the current branch state (undeployed).
2. Restore the snapshot of the latest deployment (the deployment that requires the emergency fix).
3. Make the changes to the rules and test that the change is working.
4. Deploy the Emergency fix (and take a snapshot of that deployment).
5. Restore the snapshot of the “current state (undeployed)”.
6. If applicable, reapply the changes to the rules so that the fix implemented in the emergency fix is also applied to the current state.
Figure 11-5 Main branch with snapshots only: Emergency fix
With this approach, major changes are handled the same way as day-to-day changes. This makes it a challenge to handle changes that take a long time because it would prevent deployment of simple day-to-day changes.
Scenario B analysis
The fact that branches are not used makes it impossible to work this way with a Scenario B situation.
Pros
Simple to implement.
Cons
The cons:
•Emergency fixes need to be done twice, duplicating that portion of the work (merging is not available because the approach uses a single branch).
•Relies heavily on snapshots, which is a manual process and increases complexity.
•Makes the implementation of major changes that take a long time difficult.
•Does not support Scenario B.
Although it is simple to implement, we do not recommend that you use this approach in a production environment. It was included in this book for the purposes of demonstration.
11.3.2 Main branch with simple branches for changes
The next level of branching is to use one main branch and to create sub branches from this branch. This approach allows day-to-day changes to be made in a branch that is not deployed. The main branch always represents the state of the rules as deployed in production.
Scenario A analysis
This method of working can easily be used for day-to-day development on Version 1. The day-to-day changes are made on a branch that is independent.
When completed, the changes can be merged into the main branch and then deployed, as shown in Figure 11-6.
Figure 11-6 Main branch with simple branches for changes
Figure 11-7 shows how an emergency fix would be handled. The change can be performed directly on the main branch, which holds the current state of the rules in production. Alternatively, an emergency fix branch can be created from the main branch to allow the work to be performed there before being merged in the main branch and then deployed to production. The emergency fix also needs to be merged into the day-to-day branch.
Figure 11-7 Main branch with simple branches for changes and an emergency fix
Major changes are handled the same way as day-to-day changes. A branch is created for the major change. If the change is very lengthy, day-to-day branches must be merged into the major change branch to keep it as current as possible.
|
Leading practice: As all changes are merged back into the main branch, there is no real need to keep any branches other than the main branch. When the merge has been completed, you can delete the “working branch”.
|
Scenario B analysis
Because there is only one branch that represents the state of deployed rules, it is impossible to work with this approach with a Scenario B situation.
Pros
The pros:
•Simple to implement
•Emergency and day-to-day changes easily handled
•No longer relies on snapshots
•Long-running changes are possible
Cons
Does not support Scenario B.
11.3.3 One branch per decision service version
This strategy is an extension of the “Main branch with simple branches for changes” strategy because it works the same way, but with one branch per decision service version.
Scenario A analysis
This strategy works the same way as the strategy from 11.3.2, “Main branch with simple branches for changes” on page 149, as shown in Figure 11-8.
Figure 11-8 One branch per decision service version
What is not shown in Figure 11-8 is that there is a “main” branch from which the Release 1 branch was started.
Scenario B analysis
Because there is one branch per version of the decision service, this strategy also supports Scenario B in the same manner as Scenario A.
Pros
The pros:
•Medium complexity to implement
•Emergency and day-to-day changes easily handled
•Does not rely on snapshots
•Long running changes are possible
•Supports Scenario B
Cons
No major con identified.
This strategy is the suggested strategy for branching and merging in Decision Center.
11.3.4 Decision Governance Framework like branching
If you want to explore branching and merging a bit further, you can try to mimic what the decision governance framework does with branching and merging, as shown in Figure 11-9. First, you want one branch per release of the decision service, enabling you to support Scenario B. Each Release can have one or more change activities, and each Change Activity is represented as a sub-branch of the release.
When a Change Activity is completed, it is merged back into the release branch. When all of the Change Activities for a release have been merged into the release branch, the release can be deployed.
To keep Figure 11-9 simple, we did not show the “main” branch or the major release branches. Major release branches enable multiple versions of the decision service to be worked on and deployed in parallel, and support Scenario B. When a release is completed, the changes are merged back into the major version branch.
Figure 11-9 Decision governance framework Branching and Merging
This strategy is similar to the strategy described in 11.3.3, “One branch per decision service version” on page 151. The main difference seen here is that multiple change activities can be completed before the deployment of the release takes place.
Scenario A analysis
Scenario A is supported. The main difference is the use of multiple change activities before completing a release. Emergency fixes are supported in a similar way as the approach detailed in 11.3.2, “Main branch with simple branches for changes” on page 149.
Scenario B analysis
Because there is one branch per version of the decision service, this strategy also supports Scenario B in the same manner as Scenario A.
Pros
The pros:
•Medium complexity to implement
•Emergency and day-to-day changes are easily handled
•Does not rely on snapshots
•Long-running changes are possible
•Supports Scenario B
Cons
No major con identified.
11.3.5 Advanced branching strategies
It is possible to implement some even more advanced branching and merging strategies, but these are not discussed in this book. If you decide to implement a more complex strategy, it is important to test its functionality and the workflow that you need to have so that it is a viable long-term solution.
11.4 Example of branching and merging in IBM Operational Decision Manager
This section shows an example of the “One branch per decision service version” branching and merging strategy. All of the operations are shown in the Business Console component of IBM Operational Decision Manager. The example also assumes that the user is logged in to the application with the appropriate rights to perform the operations that are indicated.
The starting point is immediately after the first synchronization to Decision Center from Rule Designer. Figure 11-10 shows the user interface where you can see that the main branch was created. The Plus sign (+) at the top of the list of branches enables you to add new branches.
Figure 11-10 After the initial synchronization
To implement this strategy in IBM ODM, complete the following steps:
1. The first step is to create the branch for the main version of a release. In this example and as shown in Figure 11-11, we call it Release 1 and base it on the main branch.
Figure 11-11 Creating a major Branch
If you need to work on another major release at the same time, repeat these steps for the other major release. This process is not described in detail in this book. Figure 11-12 shows the result of the creation of this first major release.
Figure 11-12 Release 1 is created
2. Next, create a minor release sub-branch based on this major release branch so that changes can be managed in that sub-branch before being merged back. The result is shown in Figure 11-13.
Figure 11-13 Release 1.1 is created
At this point, we expect that multiple changes in the rules for the decision service might take place over time. We show one simple change as an example.
Figure 11-14 on page 156 shows the interface where a rule is selected for edition. First, notice the upper left corner of the user interface, which confirms that you are modifying the Loan Validation Service, and that you are currently working in the sub-branch called Release 1.1. On the left side of the screen you can see the list of projects for the decision service.
The borrower package is currently selected, showing the rules that it contains on the middle portion of the screen (Figure 11-14).
Figure 11-14 Selecting the rule to edit
3. You can edit the rules, in this case making sure that the ages accepted for the rules are correct. When you save your change, you are prompted for a comment to add to the new version that you just created, as shown in Figure 11-15.
Figure 11-15 Creating a new version of a rule
More changes can be performed in the rest of the rules. When all of the changes required for this minor release are completed, it is time to look at the sub-branch of Release 1.1 and to merge it back to the major branch, as shown in Figure 11-16.
Figure 11-16 Ready to merge changes from the sub-branch into the major branch
4. This opens a screen that allows you to choose which branch you want to merge your changes to. Select the Release 1 major branch and then click Merge, as shown in Figure 11-17. As a good practice, all changes in either branch should be stopped during this time, and the option to lock the branches to perform the merge should be selected.
Figure 11-17 Choosing the branch to merge with
5. The resulting screen shown in Figure 11-18 shows that two differences were identified. You are prompted to perform an operation, which is to update in Release 1 in both cases in this example.
Figure 11-18 Differences between branches
6. As you hover your mouse over one of the changes, it is highlighted and a small icon displays that enables you to compare the rule from both releases before performing the merge. The comparison screen is shown in Figure 11-19.
Figure 11-19 Comparing the changes in two versions of a rule
At this point, review all the changes to ensure that they are as required. You have the option to go back and fix some of the changes, change the way the merge will be performed, and then apply the merge using the icon at the upper right of the screen.
7. In some cases, it might happen that the same rule was modified in the two branches being merged, which results in a conflict that is displayed in the merge screen, as shown in Figure 11-20. Compare the two rules and then decide on the option to take, which in this case is do not modify. Alternatively, you can replace the version in either the major branch or the minor branch, depending on which one needs to take precedence. Determining which version is implemented is a business decision.
Figure 11-20 Conflict detected during merge
8. When you are satisfied with the choices selected for the merge, apply the merge and complete details, as shown in Figure 11-21.
Figure 11-21 Applying the merge
|
Note: In this case, we suggest that you select the Create snapshots of the branches before merging option so that automatic snapshots of each branch are taken.
|
9. After the operation is completed, you receive confirmation that the operation was successful, as shown in Figure 11-22 .
Figure 11-22 Merge completed successfully
At this point, a new sub-branch for the minor release "Release 1.2" can be created.
11.4.1 Leading practices
Here are some leading practices to consider:
•Create a separate branch for each major version (release) and one sub-branch per minor version (change activity).
•Try not to have parallel sub-branches unless they deal with separate sets of rule changes (modifying the same rule in multiple parallel branches increases the complexity of merging).
•Prepare your naming convention before implementation and “try it out” to make sure that it works for your organization.
•Think about the workflow and how you might manually do what is enforced by default when using the decision governance framework.
Develop a merging strategy:
•If your are using multiple sub-branches in parallel, regularly merge changes from the release branch into each sub-branch to determine potential conflicts early.
•Only when everything works in the sub-branch should you consider merging back to the release branch.
•Make sure that someone is playing the role of release manager, so someone manages the releases and the merging operations.
Leaving the main branch behind
The concept of releases that was introduced in 5.2, “Project hierarchies” on page 64 requires us to question the relevance of the main branch for decision management. Releases represent a unit that can be deployed as a decision service. It is possible to have multiple concurrent releases that focus on some specific decision changes that must be kept together:
•Consider each release its own major branch, which we will call the release branch (created from the main branch). With this approach, each release is independent from other releases, and multiple releases can be managed in parallel. If required, changes from one release can also be merged into another release.
•If the Release branch becomes the major branch, change activities then must be managed as part of sub-branches that are created from the release branch.
•If your organization has only a single release at a time, using the main branch might still make sense.
11.5 When to use branching and merging
The decision governance framework was created to provide a structured way to manage your decision services. Specifically, it manages your changes by using Releases, Change Activities, and Validation Activities. This framework makes users follow a simple workflow to reduce issues with the deployment of your decision services.
This simple workflow does not exist when using branching and merging. Permissions regarding who can work on rules as part of a change activity and so on are also not enforced.
Here are some factors that might affect your choice to use branching and merging as opposed to the decision governance framework:
•Number of rule authors
•Frequency of expected changes
•IT-centric or Business-centric processes
•Need for a simple workflow to be enforced
•Control of changes with permissions
Figure 11-23 shows a quick comparison of decision governance framework with the different branching strategies discussed in this chapter.
Figure 11-23 Comparison of decision governance framework to branching strategies
11.6 Going from branching and merging to Decision Governance Framework
After using branching and merging for a while, you might find yourself in a position where you want to take advantage of the decision governance framework:
1. Ensure that all the changes in your branches are merged into the branch that you want to use as a starting point.
2. In Rule Designer, create a new workspace.
3. Select File → New → Project.
4. Select Rule Project From Decision Center.
5. Enter the connection information and connect.
6. Select the decision service project and the branch that you want to connect to and synchronize.
7. Right-click the decision service and select Decision Center → Disconnect.
8. Select Delete current connection entries.
9. Make sure that all dependent projects (such as the XOM) and all components are in a valid state with no errors.
10. Right-click the decision service and select Decision Center → Connect.
11. Enter the connection information and connect.
12. Click Next.
13. On the next screen, select Use Decision Governance Framework.
14. You are prompted to confirm that you want to create the Initial Release required for the Decision Governance Framework. Click Yes.
15. Click Finish.
This creates the Initial Release in the decision governance framework, and you are now able to create the first “working” release using the framework.
11.7 Conclusion
This chapter describes how to use Branching and Merging should your organization decide not to use the decision governance framework. Here are some key takeaways from what was discussed:
•Create one branch per major release of your decision service.
•Create one sub-branch from the major release branch per minor release of your decision service.
•Branching and merging does not enforce a workflow as the decision governance framework does.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.