Types of Deployment in SharePoint 2007

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.