Tuesday, 22 May 2007

SharePoint deployment options : Features or Content Deployment?

[Update 23/05/07 - clarified emphasis here is on WCM sites and added more detail on conclusion]

Today I want to document some of my thoughts on deployment in MOSS - this article is intended to provide a starting point for analysis of the different ways to deploy SharePoint artifacts between environments, particularly with regards to WCM sites rather than team/collaboration scenarios. At a high level, the options are:

  • create artifacts as features/solutions
  • use SharePoint's Content Deployment framework
  • recreate artifacts manually in each environment

Interestingly, the message from Microsoft and other respected sources was initially that features/solutions was the way to go. This seems to have changed recently with Microsoft's white paper on team-based development in SharePoint. I recommend a thorough reading of this paper, but the summary is:

  • an authoring environment is provided where developers will create artifacts such as lists, site columns, content types, master pages etc. directly (N.B. this is probably the same environment where your client does content authoring using approved master pages/page layouts)
  • artifacts are created directly using the SharePoint UI and SPD rather than using features
  • assemblies should be deployed to this environment (and the final production environment) using SharePoint solutions, to leverage the solution framework's ability to deploy to multiple WFE's in one step
  • Content Deployment is used to get everything (except assemblies and config settings - see above) to the production environment
  • alternatively, the authoring environment can be the production environment if required - use versioning/content approval to control what the end-user site consists of (I recommend having separate environments - I think this is preferable to developing master pages/page layouts in production)

Having gone through the process of creating an entire site with features, I can understand why the guidance would be to avoid using this technique in favour of something simpler. Essentially, I don't think the complexity/overhead of feature development can scale for all MOSS projects, it just takes too much effort. Additionally as I have pointed out earlier, there are issues with updating files which were initially provisioned using one of the original features. However, I also see some limitations with the approach suggested in the whitepaper:

  • the integration environment doesn't make too much sense when you consider that some of the code being developed may require the SharePoint artifacts (site columns, lists etc.) to be present. If they are not created until the authoring environment, this type of code will fail/cannot be tested here.
  • the deployment process effectively means that full integration happens fairly late in the process. The authoring environment is the first environment where all code and artifacts will be present, and this is just one step away from production. In comparison to an architecture which consists of dev/QA/staging (UAT)/production environments, and thus has more than one opportunity to test integration and deployment, this may pose extra risk.
  • one less environment for testing. As in the previous point, some organisations use an internal QA environment for their testing, and then a separate one for client UAT.

An additional environment could resolve some of these issues, but that does mean more content deployment jobs to deal with, and that's not always straightforward.

Despite this, my thinking is that the optimum deployment strategy for a WCM site makes use of both content deployment and solutions/features. The former is used to deploy most SharePoint artifacts (including master pages, layouts etc.), but the latter is used for assets which are mainly based on the filesystem:-

  • assemblies
  • web part definitions (though these go in the database)
  • config settings
  • site definitions (including feature stapling)
  • DelegateControls

(I cover those last 2 items in a forthcoming article btw).

I think this works the best because the feature framework works particularly well for provisioning, but not so well for ongoing site management. This is why there is something of a distinction between WCM sites and team sites. In a team site, the site is provisioned initially with a set of functionality and default content, and then ongoing management is really restricted to development of new bits of functionality (hence features suit this requirement well) and content/documents are added by users. A WCM site often requires very careful lifecycle management of functionality (and content), and I don't think the feature framework caters well for this.

Comments especially welcome on this topic!

4 comments:

tsooj said...

This really is an interesting post. Tnx very much! What i don't understand is the last part about wcm vs teamsites, ongoing management vs provisioning.

If i understand you correctly; it is best practice to avoid features with wcm with Production , staging etc.
To use content deployment instead. For team sites the other way around ,am i right? But if a developer creates a solution for a wcm site. You use the solution package to deploy the solution on other environments but you still use content deployment for content.

It confuses me, so if i can't make myself clear i appologise

regars ,Joost

Chris O'Brien said...

Joost,

The question of which deployment strategy to use is an interesting one! In my opinion, there are many factors which should be involved in the decision - it may not be as simple as whether the site is a WCM or team site.

However what I was referring to in the last paragraph is that these types of sites have very different characteristics. For a team site (collaboration), the site is generally created and then end users use it. Updates may not happen regularly once the site is in use. However for a WCM site (e.g. a .com site), updates are likely to happen fairly regularly (in the sites I work on) - page layouts, master pages, content types, site columns would all need to be updated regularly. The Feature framework doesn't really deal with this well. However, Content Deployment does take care of this kind of thing. But remember, Content Deployment is intended to take all content across to the target environment - it's not possible without using the API to be more granular.

These are the type of factors to consider in your decision of which way to go. It might be that a mixed approach is best as I suggest.

HTH,

Chris.

Marcel said...

Hi Chris,

this is an old post but I read it just a week ago and still wandering around with the things you said here. These are my thoughts about building a sharepont wcm site, could you check if our approach is a good practice?

I'm building a site with my team and we all have MCMS background. As we started building we came up with the idea to create and deploy the site using features (site columns, content types, master page and page layouts) and eventually a solution package. This way (is our opinion at this moment) all our "structure" is on the file system and we can use subversion to keep track of changes or rebuild/reinstall the site from scratch if we want to.

After the site is created and ready for production we could make our changes (for maintenance) by updating the features/solution packages and deploy it to production.

With this approach we want to use the sharepoint content deploment itself just for the content the customer has created.

So this is how we think about, can you confirm this approach or is it bad practice. I just can't decide...

Thanks in advance,

Marcel

Chris O'Brien said...

Hi Marcel,

Apologies for the delay in replying, I've been on holiday.

What you describe is effectively how I've developed WCM sites. However, with the current tools it can certainly be more effort to develop using Features, so this should be considered. The advantages are that the site can be rebuilt from scratch and you can develop more incrementally.

You might be aware that content deployment analyzes all the dependencies of the site for you, and therefore takes across all site columns, content types etc., so this can be useful. However, the out-of-the-box tools aren't granular, so a custom tool may be required if you were to use this extensively. I recently posted on
deployment using STSADM export or the content migration API, and intend to write a more detailed article on the different methods and their characteristics in the next few days.

HTH,

Chris.