SharePoint 2007 Deployment: Overview

I’m starting a new series of posts on SharePoint Deployment, since I believe it’s one of the hardest tasks on a SharePoint project. This first post will be updated every time I add a new article to this series.

SharePoint 2007 Deployment Series

Part 0: Overview (this post)
Part 1: Features and Solutions
Part 2: Creating and Using Features
Part 3: Creating and Using Solutions
Part 4: Site Column Features
Part 5: Site Content Type Features
Part 6: List Template Features
Part 7: List Instance Features
Part 8: Custom Action Features
Part 9: Module Features
Part 10: Event Registration Features
Part 11: Content Type Binding Features
Part 12: Feature Stapling (Feature Site Template Association)
Part 13: Using Resources in Features 

Who Needs Deployment?

Regarding the development environment, there are two types of SharePoint projects:

• Single environment projects, where everything is configured and developed directly in the production environment;
• Multiple environment projects, where all the development and configuration is done in a development environment, then possibly deployed to a testing environment, and finally deployed to the production environment.

Additionally, you can have two types of farms, in a SharePoint installment:

• Single server farm, when there is only one SharePoint Server in the farm (although there can be additional SQL Servers);
• Multiple server farm, when there are several SharePoint Servers, possibly with different server roles, in the farm.

For Single Server – Single Environment projects, which are the least common type, the developers don’t really need to be concerned about deployment since everything is done on the same server. But for the other types of projects (Single Server – Multiple Environment, Multiple Server – Single Environment and Multiple Server – Multiple Environment) developers will need to deploy their work to the servers.

What Does Deployment Mean, in a SharePoint Sense?

In SharePoint, deployment means the necessary actions to install your software solution in a SharePoint environment, whether that solution consists of web parts, custom web controls, event handlers, custom web pages, or just master pages.

So, imagine you have created site columns and content types directly on the SharePoint UI, customized some master pages using SharePoint Designer and installed a few custom web parts on your Development Environment, and now you need to deploy this to the Testing Environment (and later on, to the Production Environment). You can choose from a few different deployment methods:

• Stone Age Deployment. You do it all over again in the Testing Environment, and later you will repeat the procedure in the Production Environment. It’s not hard to figure out this is a bad practice: probably you won’t be able to repeat the tasks in the exact same order as you did before, and that might result in errors or in a Testing Environment that is not a replica of the Development Environment. Also, that means the developers must have administration access in all the environments, which is not always the case.
• Backup/Restore Deployment. You perform a farm backup on the Development Environment and restore it in the Testing Environment. Although commonly used, it’s not the best practice either: you must make sure all the assemblies, web.config modifications, and file system changes are present in the destination environment before you restore the backup. Also, you might have some problems if the environments are not in the same windows domain.
• Content Deployment. You use SharePoint’s content deployment paths and jobs. That can be a good solution, but it has some limitations: unless you are deploying a whole site collection, you’ll need to make sure all the assemblies, web.config modifications, and file system changes are present in the destination environment before you restore the backup. Content deployment is targeted at "contents" and not at "structure", although some of the SharePoint structures are migrated with the contents. Also, both environments must be connected for automatic content deployment to work. You have the option to export a site collection to a .CAB file and import it in the destination environment using STSADM commands, but the same limitations apply.
• Solution Deployment. You build SharePoint Features for all the objects you developed and pack them in one or more SharePoint Solutions. This is the recommended approach for structure deployment, since it allows for multiple server farm deployment, allows the deployment of assemblies, web.config modifications, files in file system folders as well as all SharePoint objects.

This series of posts will focus on the last deployment method.