Is there any way to remove elements from the target server with MSM? These would be things like templates, content types, etc… If not, what is the recommended approach besides teaching the operations team how to use workbench?
Thanks
Bryan,
MSM was not designed to remove design objects.
If you describe what you are trying to do, we might be able to recommend an alternative approach.
It would also be helpful to know what version of Percussion CM you are using.
RLJII
Unfortunately that is what I though. We are an agile shop and part of that means weekly QA builds; part of this is incorporating feedback from stakeholders which causes us to add and remove fields. (Unfortunately most times this is to shared field sets which a totally different type of torture) We have about 4-5 developers working in the environment which is not helping much. Anyway, our builds are taking multiple hours due to random errors. Some of these errors are due to both a shared field set changing and a content item being removed from the source server. This seems to make the destination server unhappy. (Along with the developers…)
The MSM instructions do not even talk about the best practices for removing content types from a target server. Furthermore, there seem to be issues with removing local fields from content types. To pile on some more, MSM is not very forthcoming about what actually went wrong in applying and archive.
What we are looking for is some type of instructions/best practices for moving changes between environments which do not only include adding new content types/templates, but what should be done when we actually need to remove content types or god forbid change shared field sets. At some point the developers will need to hand off the process of moving between environments to the operations team. (Our developers should not have access to QA and will not have access to our client acceptance and production environments.)
So any information would be greatly appreciated, thanks.
Oh and for the record we are using 6.7.
Yep, many, many things can go wrong in an MSM deployment. It took us about 6 months to finally figure out our own internal best practices with regard to order of elements in the archive ( 6.5 documentation had inconsistent ordering in various docs).
One thing that really helped stabilize our MSM archive deployments, and relieved a lot of MSM headaches, was when we figured out how to refresh our development environment from our production environment. That helps align the primary keys between development, QA, and production.
As for removing elements from production, you’ll have to repeat the developer’s efforts in production, using Workbench. Frankly, I’m kinda glad, because I’d rather not have MSM decide what to delete given that the ID mappings might be wrong, and you end up deleting the wrong thing.