Branching, merging and version management.

[joe_jboss]

We follow the normal software model where we branch our source code and all related artifacts for each release. We also do this when we have a special project. This means that awlays have two or more active development branches. We keep all of our process definition XML files in our repository and bundle them with our application in the ear/war file. We're trying to figure out how we are going to "diff" and "merge" the BPM files between the various branches.

We have 60+ BPM flows each of which consists of 3 components. We really need a way to merge the processdefinition.xml file. One problem there is that the designer often dies if you manually edit an xml file and any type of merge would be an xml file. The builder needs to be more robust about displaying what it can when it gets confused, even if it tosses the rest of the data. It would seem that we would really like to merge the layouts also but I'm not sure what that means. image.jpg files should probably be tossed and completely regenerated.

In an ideal world, we'd do this with a graphical tool. Maybe where the two merging diagrams both show up in the builder in some color coded fashion.

How do others handle version management of BPM files?

[kukeltje]

I think not many people have 60+ flows, 4 layers deep, each consisting of 3 components. For the limited number of processes, only 2 layers deep, we just use CVS and common sense/basic QA

[joe_jboss]

We use a large number of flows to better isolate the changes and reduce the risk of collision with the 10 or so process developers. We could model it with fewer flows but we'd have less process re-use and more modeling bottlenecks. The other problem is that the editor gets unwieldy with over a certain number of boxes. We have one flow with 20+ boxes and that seems to be about the max. (I meant to say that our flows have as few as 3 boxes) We use Perforce, basic QA and common sense for that part.


The hard part is branch management. A real app, once in production, typically runs with 3 branches, "production support", "next release" and "future work". The branches are often run by different managers and different schedules. We're trying to figure out the best way to manage the merge and sync process given the fact that each flow consists of 3 components, model, layout and image. Most of our merging and diff tools do a very poor job on XML files. Plain text (java) files are easier to merge because you can bring broken code into the Java source editor and use Eclipse's syntax tools to help put it back together. XML tools are significantly less helpful.

[joe_jboss]

As an aside. Rule engines often suffer from the same problems. They use XML rule definition files which make branch-to-branch merging difficult.