Designer Changes Best Practices

Purpose

This document is going outline the Microsoft Best Practices regarding designer changes.

 

Introduction

So we all know that objects in a production environment should follow some pretty fundamental principles. Some of these would be objects should be source controlled, objects should go through test before deployment to production, objects should be performant to the best of their ability and so on.

 

With code this is pretty well documented. Use Source Safe, VSTS or some other Source Control system, create drop zones and move from environment to environment. Even the more complex GAC procedures and the like are very well documented and have several approaches to accomplish the environment issues.

 

Unfortunately, this is not the case for designer changes.

 

What are designer changes?

Designer changes consist of items such as but not limited to:

• Master Pages
  
• Layouts
  
• Cascading Style Sheets
  
• Themes
  

 

Feature Overview

To understand the solution is to understand MOSS features. The following is quote from Microsoft Office SharePoint Server 2007:

 

"New to the Microsoft Office SharePoint Server 2007 architecture, Features offer flexibility

in terms of developing and deploying extended functionality—such as page templates,

lists, content types, Web Parts, workflow, and events—to new and existing Office Share-

Point Server 2007 sites. By default, SharePoint Server 2007 includes prepackaged Features

as part of its base installation, such as a My Site Feature. The Feature framework has

been extended to allow developers to create custom Features.

If you worked with site definitions in SharePoint Portal Server 2003, you'll appreciate the

flexibility of Features! With SharePoint Portal Server 2003, if you wanted to add a list or

document library to an existing site definition, you had to work with one large

ONET.XML file to modify the XML code and then track each of those changes throughout

the ONET.XML file. Likewise, if you wanted to add items to the SharePoint toolbars

or menus, you had to work with complex Collaborative Application Markup Language

(CAML). Features overcome the complexity of injecting such changes by chunking code

into smaller, more manageable files, which can be more easily tracked, versioned, and

deployed.

Both developers and administrators will benefit from using Features throughout a Share-

Point Server 2007 deployment. Through Feature schemas, developers can scope and add

simple changes, such as provisioning new pages to a SharePoint site, or registering and

deploying complex solutions developed in Microsoft Visual Studio 2005, such as event

handlers or workflows. Developers can also work with the SharePoint object model,

which includes Feature classes to effect changes throughout the life cycle of Features.

Examples of these changes include whether certain actions or events occur when a Feature

is installed, activated, deactivated, or uninstalled. In addition, administrators can

install and deploy Features with ease, using command-line tools, and will have at their

fingertips the ability to switch Features on or off via the activate and deactivate options on

administrative user-interface pages"

 

The benefits of using features in this context are as follows:

• Ability to leverage a rich source control management solution: Because everything is now on the file system, this is no different than your non-SharePoint ASP.NET 2.0 Web projects, or class libraries, etc... they are just files on the file system so you can easily add them to your source control management system of choice! This is HUGE!
  
• Ability to package up the feature (and all it's files) in a SharePoint solution: See where I'm going? If you package up your feature and it's files into a SharePoint solution file (*.WSP) which you can then use to...
  
• Deploy to all SharePoint web front end (WFE) servers in your farm at one time: Solution deployment can be scheduled to run at a future time... and the best part: SharePoint's solution framework will automatically deploy the feature to ~all~ your WFE's in the farm at that time. But that's not the only advantage of solutions...
  
• Ability to retract deployed solutions: Ever had that "oh crap, we gotta get that off the servers NOW!" moment? The solution framework has the ability to yank a deployed solution back at a scheduled time as well (or immediately if you have the "oh crap" moment).
  
• No need for developers to have access to your production environment: Since the files are in a feature that's packaged in a single solution (*.WSP) file, your production administrators can easily add the files to your production environment without developers having to open SharePoint Designer to make changes!
  
• All files remain ghosted (uncustomized) on the file system: Remember, they are provisioned as Type=GhostableInLibrary which means the content doesn't really reside within the content database, they are on the file system. This is HUGE! This way...
  
• Easier to make changes to existing files going forward: Everyone has changes to files once deployed into production. Using this mechanism, you can just upgrade the solution with an updated feature (don't change the solution or feature ID's) and every site that's activated the feature will automatically get the changes applied to their site! This is HUGE!
  

Deployment of Features

Now we move on to the technical implementation.

 

[Will follow up with actual technical details but essentially we will use stsadm with an upgrade flag to remove, and re-add these files]

 

Summary

The proper way to move these designer changes should be done utilizing feature deployment methodology in MOSS.