Other than on the local workspaces, where are the process files and the build file stored on the IS\MWS?
How can we do version control of a process model? By versioning the model in the properties section of the model or can we version the whole process Project itself?

Specs:
We have a WM 8.x BPMS suite and Serena Version Manager as a VCS repository.

Cheers,
Akshith

Other than local workspace, the process model is written as blob object in prt table. All the build information are also written to prt tables.

-Senthil

Thanks Senthil!

Do you know if we can version the whole process project? I am looking at pointers on how to implement version control for process models.

Cheers,
Akshith

Hi Akshith,
Unlike CAF/Tasks, all the details about business process model is just in one single file - .process file. It is better to version the whole process project. However, if you see the exported project, it just has the .process file. The value of generated package name will be the same as process project name the very first time unless it is changed.

If others has any other better suggestion on how to version process models, pls share with us.

Thanks
Senthil

I have been digging around on this a little bit and came up with this model,

• We will use CVS as a repository for design time artifacts, like process models, Blaze rules etc.
• The actual code base(Packages et al) behind the process model will stay in Serena.

The primary reason for us to have CVS is so that multiple developers can work on the process models with out interfering each others work and a single repository to access the models instead on local machines.Once the development is done, these will be uploaded to the MWS which in turn goes in to the tables in DB. The models will be promoted from one env to other using the repository based deployments by Deployer.

I am not sure if this is a feasible solution but i will have to test this out to find it. Does anyone see any flaws or shortcomings with this model?

Cheers,
Akshith

My only input is to try to avoid having multiple people working on the same model at the same time. There will be no reasonable way to merge the changes (if they are to be merged) except manually.

Basing the deployments on the repository is a good approach.

You might consider the use of CrossVista TEAM for version & release management, if the team is big enough to justify the cost. (I’m not affiliated with CrossVista).

I agree with the opinion that merging changes with in same model by different users will be a Mission Impossible thing. I will have to see if i can manipulate the xml definitions with in the model and able to merge changes based on those definitions.

I have been recommended the Crossvista TEAM product before too by another Collegue (They have successfully implemented it in Canada for a client) and heard lot of good things about it. With the time frame and the budget currently allocated to this project, i think it will be next to impossible for me to convince the top dogs to get CV TEAM.

Maybe we could consider the product on day2, after seeing all the issues with the BPM deployments using Deployer :).

Thanks for your inputs Rob, Senthil. I will test the model that i have discussed earlier with some additional functionality for merge and let you all know the findings. Appreciate the help!

Cheers,
Akshith