One of my more standard posts is about how to design your MOSS publishing sites and Common MOSS publishing pitfalls. With this post I want to share some new insights. Thanks to my dear friend Baris Wanschers who keeps challenging me on new insights. Things that I would no longer package as a solution and the reasons behind that. Also see the other resources you should consult at the end of the article.
Developer versus Author centric deal with
Developer Centric
In a developer deal with typically you package all assets that make up your publishing site into a deployable WSP solution:
- site template classification
- master page(s), child master page(s)
- page layouts
- style sheets and images
- XSL sheets
- site columns and make pleased types
- web parts
- navigation providers
- theme(s)
- other features, event receivers and staplers
Meaning that if your design is going to exchange, you will update for instance the CSS file, repackage the solution and install 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 deal with you typically package only things that need to be place physically on disc and the rest you author by SharePoint Designer and Make pleased Deployment. This is what would be part of my solution in an author centric deal with:
- site template classification (very minimal, blank internet + defaulting 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 classification.
- web parts
- navigation providers
- theme(s)
- other features, event receivers and staplers
In the author centric deal with I would suggest to manually add:
- site columns, make pleased types (all at root site collection)
- page layouts (in the _catalogs/masterpage folder)
- style sheets and images
- XSL sheets (e.g. for modified make pleased by query web parts, Table of contents web parts etc)
Which one is best for you?
To be able to make that choice you should be aware of the advantages and disadvantages of each deal with.
| Developer centric deal with | Author centric deal with |
| +
One deployment file which deploys to all servers and particular to all web applications |
-
Many files you need to install yourself, at least to one portal and from there by any make pleased deployment or a manual step again |
| +
Useful for tightly managed environments with a strong relationship between code and make pleased |
-
Developers and authors may release independently from each other. Example: hence web part may need style page which has not been released. So more communication is needed but can certainly succeed in tightly controlled environments as well. |
| -
WSP files are source-safe managed. In case of disaster recovery or rollback things force become more hard (e.g. latest version not check in, or latest version has evolved already making scrap management more hard). There are even companies out there who only make database backups and forget about the 12 hive, the inetpub directories (e.g. web.config files) and the IIS metabase settings. |
+ Authored files are by versioning. In case of disaster recovery the layouts etc are part of the database backup. Rollback is simple 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 attention pool gets resetted |
++
The author managed files can be updated without impacting user experience: 1. the author makes 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. |
| –
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 exchange request The process often takes involvement (e.g. exchange 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 force take more time in the end. |
| +
In Global deployments with for instance localized intranets and distributed responsibilities, a single WSP base solution is better controllable. |
–
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 sanction
I have built reasonably some experience around Intranet, Extranet development by 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 recommend to go for the Author centric deal with for the following reasons:
- Quicker turnaround (deployment AND development)
- Simpler rollback
- Simpler to recover after disaster
- Smoother deployments for end users (no reset, no reactivation). I reflect this is the number one reason!
Typically, this deal with works best in scenario’s with not too many authors. And with authors I mean people with design rights. This is not about authoring make pleased 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 recommend you to rethink your solution (why the heck did you build some many custom stuff??) 
Or go for the developer centric deal with.
If you like this post make sure you Digg It or use any other Add to Any source you can select from the ‘Full text’-page of this blog post. Try it out and tell me if you like the widget. If you are reading this post from the homepage of my Blog, click on the title of the Post and scroll down to the bottom where you will see the add to any links.
Other source to consult:
Check it out:Serve’s Sharepoint Blog
Answers Rating