Content Type Syndication Hub is a great feature of #SharePoint2010 and upper.
In the following post I described it in detail:
http://wyldesharepoint.blogspot.com/2012/03/content-type-syndication-hub-explained.html
However in some scenarios this feature is not the best approach.
In many organisations there is usually a set of #SharePoint farms that may include all or some of the following:
Ideally the process of creating some custom #SharePoint work may look like:
Some companies enjoy creating site templates, because it's a very convenient way of duplicating user experience if many similar sites are required.
Following the best practice process described above those companies would need to do the following:
1. Create a site and create a site template in DEV
2. Copy the template to TST, install and test
3. Copy the template to UAT, install and test
4. Copy the template to PROD and install
If we are using the Content Type Syndication Hub on every environment, we would have the following situation:
etc.
So in every environment the name of the published content type CT1 is the same (Name), but the internal identifier is different:
DEV: IdDev
TST: IdTst
UAT: IdUat
PROD: IdProd
From experience it has been found that restoring the site collection or a site from one environment that using Content Type Hub into another environment, breaks the subscription mechanism.
That means we will not be able to use the site restored from DEV on TST, UAT and PROD, because Content Type Syndication will not work for the restored site:
One of the possible solutions is to create a custom feature in Visual Studio that will contain:
In this case we get control over the custom content types and it's more transparent than using Content Type Syndication Hub feature.
Also it doesn't require having a separate site collection to serve just a Content Type Hub role.
The following walkthrough is a good starting point to help creating Visual Studio 2010 solution that contains custom content type and fields:
http://msdn.microsoft.com/en-us/library/ee231593(v=vs.100).aspx
In the following post I described it in detail:
http://wyldesharepoint.blogspot.com/2012/03/content-type-syndication-hub-explained.html
However in some scenarios this feature is not the best approach.
In many organisations there is usually a set of #SharePoint farms that may include all or some of the following:
- Development (DEV) environment
- Test (TST) environment
- UAT environment
- Production (PROD) environment
Ideally the process of creating some custom #SharePoint work may look like:
- Create #SharePoint artifacts in DEV and package them
- Copy the packaged artifacts from DEV to TST, install there and test
- Rework the artifacts if there are issues in DEV then copy and test in TST until it all works well
- Copy the packaged artifacts to UAT, install there and allow end users to test
- Rework if required until UAT is completed without issues
- Copy the packaged artifacts to PROD, install and test
Some companies enjoy creating site templates, because it's a very convenient way of duplicating user experience if many similar sites are required.
Following the best practice process described above those companies would need to do the following:
1. Create a site and create a site template in DEV
2. Copy the template to TST, install and test
3. Copy the template to UAT, install and test
4. Copy the template to PROD and install
If we are using the Content Type Syndication Hub on every environment, we would have the following situation:
etc.
So in every environment the name of the published content type CT1 is the same (Name), but the internal identifier is different:
DEV: IdDev
TST: IdTst
UAT: IdUat
PROD: IdProd
From experience it has been found that restoring the site collection or a site from one environment that using Content Type Hub into another environment, breaks the subscription mechanism.
That means we will not be able to use the site restored from DEV on TST, UAT and PROD, because Content Type Syndication will not work for the restored site:
One of the possible solutions is to create a custom feature in Visual Studio that will contain:
- Custom fields
- Custom content types
Also it doesn't require having a separate site collection to serve just a Content Type Hub role.
The following walkthrough is a good starting point to help creating Visual Studio 2010 solution that contains custom content type and fields:
http://msdn.microsoft.com/en-us/library/ee231593(v=vs.100).aspx
Comments
Post a Comment