It took a moment for me to make sense of it, but Bil Simser is the guest here for discussing Furuknap and MarcAnderson blog articles that are duking it out over (mmm.. I mean discussing nicely) ootb vs custom SharePoint dev.  Or more to the point is modified ootb really ootb or not.

Both of these articles have now broken from the premise of a pure ootb state.  Which means that we must be putting in the same box both what Bil terms as “propeller head” Visual Studio projects and “modified ootb” projects that are created using the SharePoint UI or maybe the SharePoint Designer.

So, why do people even bother trying to put these things in the same conversation in the first place?

Why, it’s an industry best practice:  The code you deploy in Staging – should be exactly the same as Production.  (Deployment Chapter 4 Verses 9-10)

Whether you use ootb, configured ootb, customized ootb or developed solutions with SharePoint: In an enterprise environment, it has to be tested somewhere, developed  somewhere else and used by the general organization still somewhere else.  Rarely, though worth mentioning, it is possible that enterprises have used ootb, configured and customized solutions for developer and end user audiences in a singular environment, but I digress..  Today I want to bring to light the pitfalls of the day and my current favorite idea in regards to deploying SharePoint projects across multiple environments.

Armed with nothing the SharePoint UI and Visual Studio the Web UI generated/tested content has to be replicated in Visual Studio where a repeatable solution / feature structure can be created.  Now, I must add that, yes, I have tried exporting entire sites for direct import and have even tried Visual Studio’s nifty import with frustration.  For instance, you cannot export a publishing site or a site where the publishing feature has been accidentally been toggled on and off, even just once. Further, I’ve only found the Visual Studio .wsp imports to be useful when I’m trying to zero in on a particular artifact, because there is simply so many artifacts that don’t have useful CAML equivalents yet and thus you end up with unwieldy elements called property bags.

The developer’s path is to create using Visual Studio:

  1. 1st create your Customer list
  2. Now create your Orders List, and use a nifty lookup column to relate your orders back to the Customer, even enforce deletion – cool
  3. Deploy
  4. Now realize (hopefully not as late as V2) that you need one more column in your Customer list
  5. Redeploy
  6. Ouch, now your Orders List doesn’t work because your lookup is looking at the wrong GUID for the Customers list, and ouch, even SharePoint Manager 2010 can’t delete Customers to be recreated, and ouch .. and ouch..


Constructive supposition of the day
Perhaps, if we place an assumption like, “everyone gets conversation tool like Metalogix”, maybe, then we wouldn’t have creative solutions that are most easily implemented with the SharePoint UI instead falling under Bil’s third “propeller hat” umbrella.

Enter a 3rd party tool:  The user experience folks, the developers and the end users could all do “out of the box”, “configuration”, “customization”, and “Development” work using the staging environment to their hearts delight.  Then migrate artifact changes in a repeatable fashion using a 3rd party tool, satisfying the best practice, and leverage Visual Studio solutions and features for the projects that it does best:  .net pages, timer jobs, event handlers etc.

It’s really just a thought…  maybe next time.