Guest Author: Serve Hermans

One of my more popular posts is about how to design your corporate intranet using MOSS publishing sites and Common MOSS publishing pitfalls. I built a global corporate intranet with over 30.000 unique visitors each day that has been running for over a year now.

Of course, we have had many new releases since then. With this post I want to share some new insights. Thanks to my dear friend Baris Wanschers who keeps challenging me on things that I would no longer package as a solution and the reasons behind that.

Developer versus Author centric approach

Developer Centric

In a developer approach typically you package all assets that make your publishing site into a deployable WSP solution:

• site template definition
• master page(s), child master page(s)
• page layouts
• style sheets and images
• XSL sheets
• site columns and content types
• web parts
• navigation providers
• theme(s)
• other features, event receivers and staplers

Meaning that if your design is going to change, you will update for instance the CSS file, repackage the solution and deploy it again. This scenario is often recommended for solutions where the whole design is very tightly bound to the code.

Author centric

In an author centric approach you typically package only things that need to be put physically on disc and the rest you author using SharePoint Designer and Content Deployment. This is what would be part of my solution in an author centric approach:

• site template definition (very minimal, blank internet + default onet.xml)
• master page(s), child master page(s). Because in a tightly controlled publishing environment you want to be able to prevent Designer changes on master pages or be able to revert back to site definition.
• web parts
• navigation providers
• theme(s)
• other features, event receivers and staplers

In the author centric approach I would suggest to manually add:

• site columns, content types (all at root site collection)
• page layouts (in the _catalogs/masterpage folder)
• style sheets and images
• XSL sheets (e.g. for modified content by query web parts, Table of contents web parts etc)

Which one is best for you?

To be able to make that decision you should be aware of the advantages and disadvantages of each approach.

Developer centric approach	Author centric approach
+ One deployment file which deploys to all servers and particular to all web applications	- Many files you need to deploy yourself, at least to one portal and from  there using either content deployment or a manual step again
+ Useful for tightly managed environments with a strong relationship between code and content	- Developers and authors may release independently from each other. Example: web part may need style sheet which has not been released. So more communication is needed but can definitely succeed in tightly controlled environments as well.
- WSP files are source-safe managed. In case of disaster recovery or rollback things might become more difficult (e.g. latest version not checked in, or latest version has evolved already making patch management more difficult). There are even companies out there who only create database backups and forget about the 12 hive, the inetpub directories (e.g. web.config files) and the IIS metabase settings.	+ Authored files are using versioning. In case of disaster recovery the layouts etc are part of the database backup. Rollback is easy through version history without intervention IT personnel.
– All files are provisioned through features (e.g. master page, page layouts), meaning that when you have to update your solution two things happen: 1. the application pool are reset 2. the features need to be retracted and activated again to be able to provision master page and page layouts again. Your site is temporarily down. And the process is manual.	++ The author managed files can be updated without impacting  user experience: 1. the author creates a new draft version and can see the effects on the life site (as any other designer of the root site) and when satisfied publish the major version. 2. no application pool resets or site unavailable messages.
– The process of deploying a WSP file that contains all also means unnecessary deployment of GAC dlls and other files that have not changed. Also it often involves: 1. initiating a change request 2. preparing installation instructions 3. deployment 4. testing The process  often takes involvement (e.g. change boards) of more roles hence taking more time.	+- Deployment of author centric files is quick. BUT in case your solution is deployed to many web applications (e.g. different portals sharing the same base solution) then you will have to take care of all manual updates which might take more time in the end.
+ In Global deployments with for instance localized intranets and distributed responsibilities, a single WSP base solution is more manageable.	– In Global deployments  you may start asking yourself if all files have been deployed correctly and if you did not miss one. There is no mechanism to check that easily without building something yourself.

My recommendation

I have built quite some experience around Intranet and Extranet development using MOSS Publishing sites in large, globally managed environments. I have always felt that a mix between both would work best. That is why I would advise to go for the Author centric approach for the following reasons:

• Quicker turnaround (deployment AND development)
• Easier rollback
• Easier to recover after disaster
• Smoother deployments for end users (no reset, no reactivation). I think this is the number one reason!

Typically, this approach works best in scenario’s without many authors. And by authors I mean people with design rights. This is not about authoring content but about authoring page layouts and master pages.

If your solution really consists of many custom web parts which tightly integrate with your page layouts, then I would advise you to rethink your solution (why the heck did you build so much custom stuff??) ;-) Or go for the developer centric approach.

Guest Author: Serve Hermans

Sharepoint 2007 Configuration, Sharepoint 2007 Customization, Sharepoint 2007 installation, SharePoint architecture

Serve Hermans working since 2002 with SharePoint (2003 and 2007) at Schering-Plough. Twitter: servehermans