Best Practices for updating Content Types in SharePoint

Question

Recently, we came across a severe problem in production farm with the Content Types. I would like to explain the background of this problem first.

We have nice working feature for Content Types installation in production and test farms. We developed and deployed (using wsps) this SharePoint feature in Visual studio. We are using the publishing pages using page layouts and Content Types to help content editors to quickly publish the web pages. Unfortunately, some Content Types and site columns have been manually updated/added by some people in the production, so whenever I (developer) make some changes to the existing Content Types (using Visual Studio and feature activation/deactivation) , SharePoint removes one or two columns (during feature activation/deactivation) from Content Types; or the columns which have not been added in a best practice way. I think the best practice is to update Content Types using Visual Studio.

Now, I wish to ensure that site columns shouldn't get removed from Content Types upon feature activation/deactivation.

Note: Our feature for Content Type activation/deactivation doesn't hold any activation dependencies in the feature.xml

Answer 1

You should not use activate/deactive when updating Content Types (as you've noticed). For SP2010 you can use feature receiver upgrade stuff but for SP2007 one best practice is to add a new feature with a feature receiver that makes the upgrade using code.

Answer 2

There are two problems here. First, if you deploy content types with code you can't explicitly set the GUIDs, so you get different GUIDs on different farms (e.g. test, authoring, production). Now when you move content between farms GUIDs get out of sync., duplicate site columns appear, etc. - welcome to hell.

Second, if you deploy your content types with CAML everything is fine - you set the GUIDs and it is now consistent across farms... until someone changes something through the UI. Now the link to the XML in the 14 hive is gone and the CAML is instead in the tables in the content database. Next time you deploy it has no effect. So you start putting code in feature receivers, and we are back to the first problem.

There is no easy solution to this. The best way is probably to prohibit changes to the schema through the UI, or programmatically "re-ghost" them in the feature receiver, at the risk of deleting changes.