Managing Configuration Changes from Sandbox to Production

[Dimitris Tranoudis]

Hi Clarity Community,

I’d like to hear how others approach the management of configuration changes between Sandbox and Production in Clarity.

Given the mix of classic and modern elements, and the varying levels of flexible configurability, how do you:

• Organize and track configuration changes?

• Promote updates consistently and efficiently?

• Document and, if needed, roll back changes?

Any tools, practices, or lessons learned would be greatly appreciated.

Thanks in advance for your support!

[Ming Cheung]

Hi Dimitris,

Migration of configuration changes between Sandbox and Production has always been a bit challenging, especially with the Modern UX.  OOTB, we provide the Content Migration Packages which can handle some of the migration changes (Objects, lookups, etc), primarily for the Classic UI:

https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/clarity-project-and-portfolio-management-ppm-on-premise/16-3-2/reference/clarity-ppm-studio-development/clarity-ppm-studio-content-packages.html

For other items, you will need to rely on our older WSDL API - the XML Object Gateway (XOG).  WIth XOG, you can handle everything in the Classic UI that the Content Migration Packages do not cover, such as users, security groups and everything else.

https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/clarity-project-and-portfolio-management-ppm-on-premise/16-3-2/reference/xml-open-gateway-xog-development.html

For the MUX configuration changes, you will need to either do them manually or look to our network of partners.  If you Google "Clarity Content Migrator" you will find some hits from our export advantage partners.  These utilities can handle Blueprints, views, Field Level security, etc.

Regardless of how you do it, I highly recommend tracking a change log with the order in which to promote the changes to your environment as a best practice.  One of the weaknesses of the content migration packages is that it blindly applies lookups, then objects, ect.  In some scenarios, you need the object before the lookup, such as ones with object lookups or query based ones.  For the content packages, you simply need to reapply the failed objects in the UI if you run into any such issues.

If you would like to see a unified solution for the management of content, I suggest joining our monthly innovation calls and supporting one of the ideas in the community.

[Marcel Wagner]

Hi Dimitris, 

currently we use "3C" by Tricise. The software is quite sophisticated, and it helps me especially transferring Blueprints and Views (but also processes, groups, objects, lookups, ...). Quite a time saver, if you must transfer a lot.

Downside is, that they need some time after a Clarity release, to update their software, so it also transfers new stuff.

Positive or Negative (depending on how your personal view is on that ;) ): It also forces you to strictly work in a release process - for example: Quick fixes in the Blueprint only on Prod will otherwise be overwritten, if you transfer the blueprint from your test/dev system.

[Dimitris Tranoudis]

Thank you both Ming and Marcel. I have contacted 3C and looked into the hints provided by Ming both for Classic UI and Modern UX. They are very helpful. I appreciate sharing this information.

[Navdeep Joshi]

Organize and track configuration changes? - you can create a change list object within Clarity PPM to track any changes, and include the basic info like: status, environment info where it is developed, what is developed (subject), and then a detailed description, if it touches any objects/lookups/any areas in Clarity PPM (you can have object based look for this), who is the developer, date of development, approver, date approved, date of moving to prod, attachment (document pertaining to what changes are done) etc

Promote updates consistently and efficiently? - you can have a process built around the above, send an email when development is done in the lower envs, and when the approver approves it, change the status, fill in the proposed date of deployment

Document and, if needed, roll back changes? - the above 2 should help you in this