Summary

For all but the smallest projects, groups building Process Commander applications need to manage parallel development efforts by multiple development teams. As teams achieve development milestones and are ready to add their improvements to the main application RuleSets, there is a chance that some of their changes to existing rules may conflict with the changes other teams are making. Even if there is a clear plan for what will be completed in what order, unexpected events often require mid-project adjustments that can disrupt plans.

This article looks at methods for minimizing the difficulties of merging parallel development efforts in a shared rule base in

• linear releases -- where the release sequence is known before development begins
• non-linear releases -- where multiple teams are working, and it is not known ahead of time which team will merge its rules first

and reviews methods for addressing common issues that arise during branched development.

Note: Some projects managing parallel development efforts have tried a risky option which is not recommended: establishing a separate rule base for each development team. While working in separate rule bases eliminates collisions in the short term, it also prevents recognizing and resolving difficulties near the point in the development time line when they occur. The longer an unresolved issue exists, the greater will be the cost of the repair effort when it finally must be resolved. Merging development efforts only at major milestones can lead to unbudgeted costs, wasted work, missed deadlines, buggy software, unhappy stakeholders, and even a failed project.

This article describes approaches suitable for V5.X and V6.1. For V6.2SP2, you can use branch RuleSets to support parallel development. See Using branch RuleSets and merging for parallel development.

Suggested Approach

• Linear releases
• Non-linear releases
• Enterprise Class Structure considerations
• Addressing common issues in branched development

Note: To enhance clarity, the examples below presume an application that has a single RuleSet layer. Applications with multiple RuleSet layers are typical. For these, the choice of a parallel development strategy (linear vs. non-linear) should be decided on a RuleSet-by-RuleSet basis..

Linear releases

Linear release projects involve a series of planned major releases over a period of time, with a variable number of service-pack releases in between to address issues that cannot wait for the next big release.

Consider a project where:

• The next application release (the top row in the chart below) is under development at the start of May and will go live in June.
• There will be one or more service packs, covering urgent bug fixes and some new functionality, released between August and November.
• Development of the November release (the bottom row in the chart below) begins in mid-May.

A Gantt chart for this example might look like this:

All development teams work in the same rule base, keeping their efforts separate by identifying and using separate RuleSet versions for each team:

• The June release effort uses RuleSet Versions 02-02-xx
• The teams creating service packs building on the June release use RuleSet Versions 02-03-01 to 02-06-99
• The November release effort uses RuleSet Versions 02-07-xx

The team working on the June release uses access groups that provide access to RuleSet versions up to 02-02-99. They do not see any of the changes the team working on the November release may create in the 02-07-xx RuleSets.

The teams working on the service packs use access groups that provide access to RuleSet versions up to 02-06-99. They also do not see the changes created for the November release in the 02-07-xx RuleSets.

As each service pack is released, the team working on the November release has to update their RuleSet Prerequisites and their runtime RuleSet list (and, if an existing application in production has been updated, their Application rule and Access Groups) to leverage the latest updates. See Addressing common issues in parallel development.

Non-linear releases

Non-linear releases have two or more independent development streams working in parallel. Whichever team completes its work first will have its rules incorporated into the application in production first.

Here is a typical non-linear example:

• An existing application in production has RuleSet MainRS 01-01-03.
• Teams are working on enhancements for MainRS. Each enhancement is largely independent of the others, although there may be a few rules that two or more teams are working with.
• As each enhancement is completed and approved, it is merged into MainRS.

The recommended approach for this situation is:

1. Create temporary RuleSets for each enhancement
2. Develop each enhancement
3. Merge each enhancement as it is ready

1. Create temporary RuleSets for each enhancement

Presume that in our example there are two enhancements, Oak and Maple, that separate teams are working on.

1. Create a RuleSet version of MainRS to house any rules that are common between Oak and Maple. The example uses MainRS 01-01-10, leaving room for possible patch or hot-fix RuleSets that would need to move into production before either enhancement is ready.
2. Create separate and independent RuleSets for each team, setting the prerequisite for each RuleSet Version to the version of MainRS you just created:
   • Oak has the Oak:01-01-01 RuleSet with prerequisite MainRS:01-01-10
   • Maple has the Maple:01-01-01 RuleSet with prerequisite MainRS:01-01-10
3. Create a Rule-Application instance for each team. Build it on the Rule-Application instance for the current application, and add each team's RuleSet and MainRS:01-01-10.
4. Create access groups for the Oak and Maple teams that reference their respective Rule-Application instances.
5. Associate the developer IDs for the two teams with the appropriate access groups.

2. Develop each enhancement

The Oak and Maple teams now proceed to work. The leadership of the teams needs to identify any rules that are common to both teams, and make sure that they are placed in MainRS:01-01-10.

3. Merge each enhancement as it is ready

In our example, presume that development of the Oak team's enhancement is completed first, so it is merged into the application RuleSet (in the development system, of course, not a production system) first, using the following procedure:

i. Reconcile rule overrides

This step is optional, but recommended.

OakRS and MapleRS may both have overridden the same rules that are already in MainRS. The two teams should reconcile these overrides before merging either effort into MainRS.

Each team should run the Rules Overrides report to identify MainRS rules that they have overridden:

for V6.1: select > Process & Rules > Work Management > Monitor Activity.

for V5.5: select Application > Browse Reports.

Run the Rule Overrides report in the Rule Reports section. Members of the teams should manually compare the two reports to identify any identical rule names. If there are identical rule names:

 

1. Reconcile the two versions to produce a single version of the rule that satisfies the needs of both development streams..
2. Place the single rule in MainRS:01-01-10.
3. Delete (not Withdraw) the rule from OakRS and MapleRS.

ii. Merge OakRS into MainRS

Note: this procedure presumes that merging into the main RuleSet takes place before functional and integration testing by the QA team. In some development environments, the new and revised rules that are thought to be ready to merge are first moved into a certification environment to undergo functional testing. After any changes required by the test results are made, the new and revised rules are approved to merge into the main RuleSet, following the procedure below. Merging always takes place in the development environment, to preserve rule history.

Follow these steps:

1. Create a new RuleSet Version in MainRS that is higher than the version currently in production. Leave a 'gap' in the numbering to allow for patches in MainRS that may take place before testing and any last-minute changes to OakRS are complete.
2. Perform a backup of your rule base.
3. Assure that all the rules in OakRS are checked in, and that no versions of OakRS are locked.
4. For V6: Select > System > Tools > Refactor RuleSets > Copy/Move/Merge RuleSet to display the RuleSet Maintenance wizard. Select Merge and RuleSet Versions as the operation.
   
   For V5.5: Select Tools > Rule Management > Copy/Move RuleSet. If you select Copy, the source RuleSets you choose will not be affected. If you select Move, after the highest version of each rule is copied out of the source RuleSet into the target Ruleset, the source RuleSets are deleted.
    
5. From the list of available source RuleSets, select MainRS:01-01-01 and then the highest-numbered RuleSet in OakRS. Set the Target RuleSet as MainRS:01-02-01. Continue with the wizard to add a 'skimmed' version of each Oak rule into MainRS:01-02-01.
6. Log on as a developer for the main application. Perform these steps:
   1. Save a copy of the existing application's Rule-Application instance to create an 01-02-01 instance that includes MainRS:01-02-01.
   2. Update the existing application's access groups to reference the new Rule-Application instance.
   3. Delete any Oak access groups.
   4. Update Oak team operator IDs to use the new existing application access group.
   5. Update the highest RuleSet version of MapleRS to include the highest version of MainRS:01-02 as a prerequisite.
   6. Update the Maple Rule-Application instance so that it is "built upon" the 01-02-01 instance of the existing application.

iii. Merge MapleRS into MainRS

When the Maple enhancement is ready, follow the steps above to merge it, in its turn, into MainRS.

After this merge, further development before the next major release uses MainRS:01-03-xx (resulting from the MapleRS merge), until the next enhancement is merged.

Enterprise Class Structure considerations

• For either style of parallel development, a best practice is to configure the security of your development environment to enforce isolation of each development stream from the others. Configure each class of the the enterprise class structure so that saved rules that apply to this class must be in the correct RuleSet: on the Advanced tab of the class rule, specify in the RuleSets list the RuleSets to associate with this class.

• Employ application-specific developer roles to restrict access to well-defined parts of the enterprise class structure. The chart below provides an example of role-based class security:

  Role	Access
  	Framework Layers	Implementation Layers	Enterprise / Divisional Reuse Layers
  Project architect / Center of Excellence	Yes	Yes	Yes
  Team leads	Yes	Yes	No
  Team members	No	Yes	No

Addressing common issues

Most parallel-development efforts encounter one or more of these common issues:

• Lost bug fixes. In the linear-release example above, a developer on the November team updates rule X that was in the June release. Later in the summer, a developer working on a patch release fixes a bug by updating rule X. When the November release is installed, its rule X overwrites the patch-release version of rule X, and the bug fix may be lost.
  
  To reduce the chance of losing bug fixes, developers working on service packs need check whether rules they need to work on have already been modified by the team working on the November release. As each service pack becomes available, the service pack team should coordinate with the team working on the November release to resolve inconsistencies and preserve bug fixes. Reports such as the standard "Rules per RuleSet, Version, Rule Type" can help identify duplicate rules that have been created by each team.
   
• Conflicting data instances. Data instances are not contained in RuleSets, and cannot be versioned or filtered with RuleSet lists. Teams must communicate regularly to avoid creating conflicting data instances, in particular with the release of Service Packages for new versions of services.
  
  Limiting create/update access for data instances (organizations, work groups, workbaskets, access groups, and so on) to a single developer on each team will simplify coordination between teams.
   
• Problems with updates to shared RuleSets. In the linear-release example above, the June and November releases share common application RuleSets on the enterprise and divisional reuse layers. Changes to these RuleSets need to be closely coordinated.
  
  If a developer tries to check in a rule that already exists in a higher-numbered RuleSet Version, a warning appears in the rule form. Developers seeing the warning must communicate the changes they have made to the owner of the higher-numbered RuleSet Version.
   
• Latency. When the application servers for two development teams share the same database server, the rule cache between the two application servers can be out of sync for as much as a minute between system pulse executions. All development teams leveraging multiple development application servers need to take this standard PRPC synchronizing mechanism into account.
   
• Scalability and performance. Multiple development teams working concurrently can put a high load on application and database servers.
  
  For development efforts of more than 20 developers per team, a best practice is to establish a multi-node development environment, with two or more PRPC JVM nodes connecting to a common rule base.

As a general best practice, the development database should be backed up daily. That will ensure the development environment can be reverted to the previous day's status, if necessary.