Sunday 28 September 2008

SharePoint dev strategies - it's not all about Features!

Something I've been meaning to discuss for a long time is the decision to develop SharePoint artifacts using Features or some other approach. I actually discussed this back in May 2007 in my post SharePoint deployment options : Features or Content Deployment?, but feel it's a topic worth revisiting/expanding on as I often see teams developing with Features without fully working out what exactly they are getting out of this approach. As you can guess by the article title, I'm not sold on the idea of using Features all the time (readers who have followed this blog from the start might find this surprising given I wrote many articles on how to work with Features) and want to put forward some points to consider when working out whether you need them or not.

Let's first consider some (selected) characteristics of Features:

  • Provide a means of deploying SharePoint artifacts such as list templates/site columns/content types to multiple environments (e.g dev, test, production)
  • Currently the only way to deploy such artifacts across multiple site collections
  • Require some extra overhead to create, even with the community tools available (in comparison with creating artifacts directly in the SharePoint UI)
  • Little/no support for certain key updates (e.g. updating a content type which has already been deployed and is in use) - updates must be done through the user interface or the API, since modifying the original Feature files to make changes is unsupported.

Given these points, one scenario I really can't see the benefit of Features for is when the solution consists of just one site collection - which is often the case for WCM sites. Why go through the extra hassle of packaging up artifacts into Features and be faced with difficulties managing updates when the artifacts will only ever exist in one site collection anyway? Sure, they may need to be deployed between environments but we have other ways of doing that.

N.B. The same applies to site definitions - why go to the trouble of creating a custom site definition when only one site will ever be created from it?

The alternative

If you aren't forced into using Features to deal with multiple site collections, not using them could be the 'most valid' choice. In my recent WCM projects, I haven't used Features for anything which doesn't require a Feature (e.g. a VS workflow, a CustomAction etc.) for a long time now, including the project I discussed recently in SharePoint WCM in the finance sector and Developer lessons learnt - SharePoint WCM in the finance sector. Certainly given the extremely tight timescale on that project, I actually feel we could have failed to deliver on time if we had used Features.

Instead, my approach is to create a blank site in the dev environment, and do all the list/site column/content type/master page development there using the SharePoint UI and SPD. My next step (perhaps not surprising to regular readers) is to use my Content Deployment Wizard tool to move all the SharePoint artifacts to the other environments when ready. Equally, you could choose to write your own code which does the same thing using the now well-documented Content Deployment API. You'll need to deal with any filesystem and .Net assets separately (generally before you import the SharePoint content on the destination), but in my view we've at least drastically simplified the SharePoint side of things. This seems to work well for many reasons:

  • More efficient since no development time lost to building Features
  • The update problem described earlier is taken care of for you (by the underlying Content Deployment API) - as an example, add a field to a content type in dev, deploy the content which uses it and the field will be added on the import site
  • Concept of a 'package' is maintained, so .cmp files produced by the Wizard can be handed to a hosting company for them to import using the Wizard at their end. I hear of quite a few people doing this.
  • We can store the .cmp files in source control and use them as part of a 'Software Development Lifecycle' approach. My approach (and I'd guess that of others using the tool in this way) is to store the .cmp file alongside the filesytem files such as .ascx files for the current 'release', and import them as part of the deployment process of moving the release to the next environment.

As an aside, when I decided to write a tool which would simplify dealing with dev/QA/UAT/production environments on SharePoint projects, I was initially torn between 'solving the content type update problem' and something based around the Content Deployment API. One reason why I decided on the latter was because the CD API already seemed to have solved the other issue!

Now I'm certainly not saying it works perfectly every time (it doesn't, though is much improved following SP1 and infrastructure update), but in my experience I seem to spend less time over the course of a project resolving deployment issues than I would do building/troubleshooting Features. Additionally, using Content Deployment allows deployment of, well, content - if your solution relies on pre-created publishing pages or you have a scenario such as your client creating some content in UAT which needs to be moved to production before go-live, Features won't help you here. The Content Deployment mechanism however, is designed for just that.

Where do Solutions (.wsp) fit in all this?

So to summarize the above, my rule of thumb for projects which aren't built around multiple site collections is don't use Features for things which don't absolutely require them. So where does that leave Solution packages (.wsp files) - should they be abandoned too? Well no, definitely not in my view. Solutions solve a slightly different problem set:-

  • Deploying files to SharePoint web servers such that each server in a farm is a mirror of another. Ensuring all web front-ends have the same files used by SharePoint is, of course, a key requirement for SharePoint farms - this applies to Feature files when using them, but also to assemblies, 12 hive files etc.
  • Web.config modifications e.g. the ‘SafeControls’ entry required for custom web parts/controls
  • Code Access Security config modifications e.g. those required for controls not running from the GAC
  • Some other tasks, such as deployment of web part definition files (.webpart)

Really, there's nothing stopping you from doing all this manually if you wanted to (especially if you're always deploying to a single server, so there are less things to keep in sync). But the point here is that Solutions genuinely do make your life easier for comparatively little effort, so the 'cost/benefit' ratio is perhaps different to Features for me - the key is using one of the automated build approaches such as WSP Builder. So, my recommendation would generally be to always use Solutions for assemblies, 12 hive files etc., particularly in multiple server farm environments.


My rules of thumb then, are:

  • Consider not using Features (and site definitions) if your site isn't based around multiple site collections - using the Wizard or some other solution based on Content Deployment can be the alternative
  • Use Solutions if you have multiple servers/environments, unless you're happy to have more work to do to keep them in sync
  • If you are using Features, plan an approach for dealing with updates such as content type updates

My message here possibly goes against some of the guidance you might see other folks recommend, but I'm just going on the experience I've had delivering projects using different approaches. As always, the key is to consider deployment approach before you actually come to do it!

P.S. Also remember, deploying using backup and restore is a bad idea ;-)


Tyler Holmes said...

Nice post Chris,

It's even slightly provocative given the documentation and tools that encourage you to do feature/solution development. That being said I definitely agree that features/solutions can be difficult and time consuming to develop and maintain.

I wonder if you'd care to weigh in when it comes to getting ASP.NET code into SharePoint. Things like SmartParts also speed development time but are harder to keep in sync across farms (especially if there's web.config keys). When it comes to ASP.NET code do you have a solution/technique that lends itself to content deployment?

Chris O'Brien said...


Yes, I'd agree what I'm saying here is contrary to a lot of 'accepted wisdom'.

In terms of moving from ASP.Net to SharePoint, I haven't really implemented any projects of this type. I do find myself using SharePoint content for lots of 'configuration'-type items though - my 'Config Store' solution falls into this category. The advantage here is that config can easily be transported between environments via Content Deployment, but I'd be surprised if even SharePoint vNext fully deals with deployment of all possible .Net config/artifacts.


Jeremy Thake said...

Great post Chris, I've been looking at this from the other side of the coin trying to push standards across the board rather than having differen approaches for different levels of complexity. I agree that building Features and Solutions isn't the easiest, but in time I think tools will get more sophisticated and take the pain out of it. STSDEV and WSPBuilder have come along way. Anyways check out my posts for more information.

Rich Finn said...

Very well said, Chris. My last few projects have been completed primarily in this fashion, and I owe it in great part to the ease of use and success of your deployment wizard. Thank you so much for taking the time and effort to develop such a great tool.

The one thought I've been struggling with now is that this places much more value on the developer content database, as a great deal more 'source' resides inside it. I'm curious what discoveries/strategies/recommendations you've thought about or used to ensure the safety of this data for both single and multi SPDev teams.

Chris O'Brien said...


All fair points (also read your post), but my thoughts would be:

- agree that tooling is getting better (and will continue to do so), but surely the idea of not having to spend any time whatsoever on Features is fairly compelling?
- to me the Features framework still seems incomplete. I can't update some artifacts by XML once they're deployed, there are still lots of things (e.g. set a property on a web) I can only do in a Feature receiver etc.
- Features to me is all about initial provisioning of artifacts. There is little concept in the platform of how these artifacts might change over their lifecycle. Content Deployment on the other hand, has lots of code to deploy the current state of artifacts on the source over to the target each time - meaning schema changes are 'automatically' applied to the target when you import.

As it goes, I'm currently implementing Features on my current project (since we'll have 100 site collections) but feel it's the right choice for this scenario. We're also trialling a 3rd party tool to help solve the issue of updating artifacts deployed by Features which are in use.

I'll still consider Features on a case-by-case basis in the future, particularly when they'll always be a gap in the effort required to create Features compared to not having to worry about it at all.



Chris O'Brien said...


Good to hear I'm not alone ;-)

Interesting comment - I do agree that the data does become more important for scenarios such as disaster recovery, but it should be critical anyway no?

For pieces of data which are key to the running of the site, in my mind the associated .cmp packages should be in source control anyway, since at the time of initially developing the functionality this .cmp would have been deployed alongside the code changes as part of that 'release'. It's certainly true to say, however, that this data will change over time and you may want to restore to the latest version of a certain SharePoint list (but leave everything else intact). The best place to be in for this (IMHO) is to have a good 3rd-party backup tool or DPM 2007 - I'm not an expert on either specifically though.

Something else which might help is that I hope to have scripting (and therefore scheduling) capability integrated into the Wizard soon. This would then provide a free solution to backing up specific lists, so long as the Wizard can be used to import them again. Clearly not a replacement for a fully-featured enterprise backup tool though.



Anonymous said...

Really interesting reading Chris, made all the more so by the fact it's galvanised from so much 'front line' experience. For me, your experience is actually the key factor here –very few SharePoint deployments have access to a Chris O’Brien i.e. someone with enough experience to determine the optimum deployment model for each artefact in the context of the target site(s) and, more essentially, the knowledge and ability to put a complex mix of content and structural deployment into practice and ensure 100% integrity.

Looking ahead from there, once a solution has been delivered how do you hand over to your clients? Does your approach create a higher dependency on you or your company? Does it require more documentation?

The other thing that you touch on in your reply to Tyler’s comments is future iterations of SharePoint. If nothing else, sticking to recommended best practice should ensure the best chances of supported migration of what you are producing now.

Just like you I have often wondered if the time I have taken to develop a feature/solution can really be justified particularly when it has been a site definition for a one-off site. I absolutely believe that Visual Studio will catch up eventually and 90% of this debate will become obsolete but as for how far down the line that will be – it may well be worth skilling up to your level of knowledge with the CD API...

Chris O'Brien said...


Interesting comments :-)

Yep, I probably would say that understanding how different artifacts work together and are best deployed is very useful in the current SharePoint landscape - it just feels unfortunate sometimes that SharePoint projects seem to require this.

In terms of whether using one approach implies more documentation or more dependency on specific deployment knowledge, that's an interesting question. From a personal perspective I'd obviously hope I'm part of the solution and not the problem (;-)), but interestingly a similar situation has come up on my current project where we're using Kivati to help with deployment. It's early days but whilst being very powerful, it does seem to tie you in to a certain vendor-specific knowledge and approach.

I guess like any other area of SharePoint, "the more you know, the more you know", and that can only be a good thing.

On a final note, I do agree Visual Studio will have a greater role in SharePoint packaging/deployment than it does today. I've seen some things, and it's being taken seriously at Microsoft. It still strikes me though, that MS have already implemented much of the code to simplify this situation in the Content Deployment API ("I want that environment to look like that environment"), and the beauty of it is that knowledge of the actual Content Deployment API itself is not required - it does the hard work if you use the Wizard or standard CD.



Jeremy Thake said...

I think we all are on the same page here, my article on change sets and deploying v2.0 on top of what is in production as v1.0 is not easily catered for AT ALL.

Most people seem to be creating new sites and migrating the old "content"/artifacts into it. But there's a grey line on what's content and what is inside the scope of the development of v2.0.

I'm going to have a further look at your Content Deployment Wizard as I am presenting for our company Readify in Perth in a few weeks on best approaches to this stuff.

Keep up the good work mate! Saving us all hours of pain!

Kieran said...

Hi Chris

If using the deployment wizard approach described how do you go about duplicating an existing publishing web if for example you need another one creating that is almost identical but under the same parent site? Does the deployment wizard help with this, given that the save site as template option is unsupported?

Would appreciate your thoughts.


Chris O'Brien said...


This should be entirely possible, though I have a niggling doubt since I don't think I've ever tried to duplicate a web within the same parent site collection. I think it should be OK though, so long as you tell the Content Deployment Wizard not to 'retain object IDs and locations'.

Happy to help if you run into any issues!



Kieran said...

So if I use the wizard to create a .cmp of an existing web called 'hr', then I want to duplicate this but with a different name in the same parent site. You think the wizard will handle the import? Or will it just overwrite the existing 'hr' web?

:) Cheers

Chris O'Brien said...


Sorry, I should have been clearer/supplied full details in my previous comment. It won't overwrite if you:

- Leave the 'retain object IDs and locations' checkbox unchecked
- Create the new site that you want to 'duplicate into' using the blank site template. Specify this URL in the 'Import web URL' textbox on the import

If you need any more help, just ask..