It's all about the answers!

Ask a question

Best Practice for copying Process configuration changes from a UAT PA instance to a Prod Instance


John S F Lander (901941) | asked Oct 30 '12, 10:15 a.m.
We have many Prod PAs that are actively making some complex changes to their Process Configuration that requires testing before becoming Live.
To do this we create a test PA on a Dev instance, make the changes and test them then copy and paste the Process Configuration Source to the Prod PA
This has worked fine, but is this the correct way to do this as I believe this could cause some problems

Thanks 

Comments
Morten Madsen commented Oct 31 '12, 2:49 p.m.

Hi, I'm currently developing a small tool for managing such process upgrades for a client, and I'd like to share it with you (presuming the client allows me to do it). It makes you able to answer these questions:

1. What changes does all PA have to their template compare to our standard template?
2. What template is currently deployed in a PA?
3. How many changes has been done in the PA since we last upgraded?

This tool will generate a CSV (comma seperated values file (excel)) and some log files displaying the diff results. And it's not just a plain text or XML diff, but it's based on the different "id" field on the individual XML-tags.

If anybody's interested in trying it out or contributing (I will probably release as open source) please let me know (morten at lagrange dot dk).

3 answers



permanent link
Jared Russell (1.3k12019) | answered Oct 31 '12, 2:19 p.m.
edited Oct 31 '12, 2:19 p.m.
 In addition to John Owen's answer, one other thing to consider with this approach is that not all configuration is stored in the process configuration.

Specifically, Javascript attribute customisations and work item templates are stored as process attachments and so would not be copied across automatically.

permanent link
John Owen (462422) | answered Oct 31 '12, 2:09 p.m.
Hi John - your approach looks OK to me.  We have a number of teams using a similar approach.  You need to ensure that the production environment isn't tampered with between copy-pastes of the process from the test environment.  Also, if between two versions of the template you remove a state and any actions associated with a work item you need to decide how to deal with that.  This will be particularly poignant if the affected work items need to be updated once the change of process has taken place.  In this case if they now have an invalid state you won't be able to save them.

permanent link
Joel Lonneker (391016) | answered Apr 25 '14, 4:53 p.m.
 We have managed to unify all project areas under one master type (provider) project area.  That being said, our process could be applied in different scenarios as well.  Through some trial and error I've ended up with this process:

The setup:
1. Master template (scrum variant) exists in an isolated CCM dedicated to master process templates.
1a. Master labelled with an incremtable number (Ex. Master - YYYYMMDD)
2. 3 additional CCM servers set as friends between each other and the master template CCM server. (Friends/Consumers)
3. Users access the 3 consumer CCMs that contain their project areas.  Each project area configured to consume the shared master template which resides on the isolated master CCM.
4. Life is good and administrivia overhead is limited

The implementation of changes and promotion:
(note: steps 2 and 3 assume isolated testing CLM servers)
1. Export most current production master project to template
2. Export template to local file system
3. Import template to testing CLM instance
4. Create Testing/UAT project from newly imported PROD template
5. Implement desired changes
6. UAT
7. Export Testing/UAT project area to template
8. Export template to local file system
9. Import template to PROD CLM instance
10. Build new master project with incremented name
11. Alter each desired project area to consume newest master template
11a. if issues found in PROD, easily alter the project area to consume the previous shared master project

With this process we are able to:
A. Ensure all our users have the most current version of our universal process template
B. Problematic projects can be rolled back to previous versions of the shared master upon demand if issues found during implementation.
C. Old shared masters are archived (n - 2 in our case) but their source XML and history are still available for review.

We have tried copy pasting between various testing project areas and production but found it cumbersome when managing 20+ project areas at once.  When pasting changes directly to a singular shared master project, ALL consuming projects get the changes immediately.  A very uncontrolled deployment and we found many headaches, especially when required to do attribute syncs or CSV imports to field attributes and their underlying data.
Hope this helps,

Cheers,
Joel Lonneker

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.