1

We have begun to take an alternate approach to solution packaging and deployment, and I wanted to get the community's perspective on it.

We deploy all of our master pages, css, js, and other custom code directly to the file system. We then use an httphandler to re-assign the masterpages on the fly (based on a configuration file).

From our perspective, this gives us several advantages over the native SharePoint deployment model including:

  • simplicity. All deployments are xcopy. No features, solutions, or MSIs necessary

  • isolation from an overly complex packaging & deployment infrastructure that is always radically changed (and therefore broken) across SharePoint upgrades

  • the ability to version our masterpages, css, js, etc. with our other code (and thus revert to any revision at will via automated scripts)

  • the ability to use code-behind with our SharePoint aspx pages

The productivity boosts we've gained by switching to this approach are enormous and we have yet to encounter any issues with it.

So those are the "pros". I'd like to hear about any potential pitfalls there might be to this method. All input appreciated. Thanks!

Improve this question
1
  • Consider that while Microsoft does not advocate placing code on the file system, they are the only major CMS that does so. The other major CMS systems that we work with (WordPress & Drupal) version their code on the file system and keep the content in the database. This makes sense, because code should be deployed to a file system... not a database. We believe this to be a fundamental flaw in the SharePoint product and it causes numerous deployment, versioning and upgrade headaches. The approach I describe here is essentially a workaround to this basic flaw.
    – Anonymous
    Commented Oct 15, 2010 at 15:48

3 Answers 3

Reset to default
1

Which version of SharePoint are you using? Packaging is easier in 2010 than it was in 2007, or at least you don't need to get add ons like WSPBuilder. I am pretty militant about packaging and deployment after years of being in environments where change control was not good, and it was damn near impossible to recreate the setup procedures.

While the whole Packaging and Deployment concept may seem confusing, there is a lot of value there. It gives you the ability to manage the configurations in your farm. They can be removed or replied easily. In addition they can be applied to new environments.

Also, it is important to understand that in many cases farm topology will change over time. Using the normal solution deployment process makes it very easy to add in another Web Front End when it is time to scale out. Having to manually reapply those changes to a new web server or to a server that had to be rebuilt because of a hardware failure is huge.

In summary, I do not ever advocate saving anything directly to the SharePoint root.

Improve this answer
2
  • We deal primarily with SharePoint 2010. While packaging is "improved" it still involves far too much friction in our opinion. We are probably even more militant than you, which is why we insist on being able to version all of our code together and automate it's deployment and rollback easily (while installing a wsp is easy, reliably automating it's build is much less so).
    – Anonymous
    Commented Oct 15, 2010 at 15:39
  • To clarify, we didn't give up on the SharePoint model packaging and deployment lightly, and we didn't give up on it because we don't understand it (we are the "go-to" Microsoft Gold Partners for SharePoint dev in our area. Microsoft calls on us regularly). We switched because we feel this is better. Your point that farm topology changes is valid, but we account for this very easily in our scripts. Just query the farm for the list of WFEs and xcopy.
    – Anonymous
    Commented Oct 15, 2010 at 15:40
1

At its most basic form Feature and Solution deployment is simply a wrapper for XCOPY that is Farm aware.

The cost of this to layout your files and provide sufficient meta data (Feature.xml and Element.xml files) to tell SharePoint where the files need to be deployed.

You must also have this complexity in the need to lay your files out in the correct way.

Overtime Feature and Solution deployment has gained additional functionality. This functionality has grown out of necessity.

The current set of "stuff" Features can deploy is listed here.

Feature Schemas

XCOPY covers only a small subset of these.

As SharePoint grows new features over time they will definately be added to the Feature Schema and you will be playing catch up.

Improve this answer
1
  • Hi Steve - Great Points. I forgot to mention that we only use this approach for "code"... i.e. master pages, css, js, etc. Items we consider "schema", i.e. list definitions, content types, etc. we still package as features. It would be better though if we didn't have to. A schema migration tool similar to Rails database migrations would be optimal. It would be great to be able to say something like: "stsadm -o shemaMigrate -url mySharePointApp -version 1.2.1" and have sharepoint migrate the "schema" elements of a site to the requested version
    – Anonymous
    Commented Oct 17, 2010 at 13:52
0

I forgot to mention that we only use this approach for "code"... i.e. master pages, css, js, etc. Items we consider "schema", i.e. list definitions, content types, etc. we still package as features. It would be better though if we didn't have to. A schema migration tool similar to Rails database migrations would be optimal. It would be great to be able to say something like: "stsadm -o shemaMigrate -url mySharePointApp -version 1.2.1" and have sharepoint migrate the "schema" elements of a site to the requested version – Akil Franklin

If you already have to deploy a "schema" WSP file then why not add an independent "code" WSP.

Visual Studio's SharePoint 2010 integration supports mapping folders like _layouts into the IDE you just keep adding files and studio generates all the Element and Feature manifests for you.

It also fully supports code behind for any ASPX pages you generate.

If you are cautious about the items you add to your "code" solution (no webparts,no content types, etc) it should always be safe to retract-SPsolution and Install-SPSolution either a newer or older version.

Improve this answer
3
  • We keep this code outside of a WSP project so that we can have a better IDE experience, (especially for developers that can't dedicate their entire workstation to SharePoint 2010 development). This model allows us to develop our pages and controls in a separate ASP.NET web project that does not require SharePoint to run, test, and debug.
    – Anonymous
    Commented Oct 19, 2010 at 8:32
  • I agree that it's relatively safe to retract and install WSPs, but the automation of that process would definitely be much more fragile than a simple robocopy (and it doesn't always go smoothly). That being said, let's assume that we invested the time to make it bullet-proof. Features would then need to be re-activated on the appropriate sites, would they not? The approach I'm describing removes the manual activation step. We could try to automate the activation of the features on the appropriate sites, but at this point, our build scripts are adding complexity at a pretty alarming rate.
    – Anonymous
    Commented Oct 19, 2010 at 8:42
  • If you only added _layouts files these are deployed at the solution level and not the feature level. You should be able to use WSPBuilder or some other toolkit to build a minimal WSP without requiring SharePoint to be installed.
    – Steve P
    Commented Oct 19, 2010 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.