Deploying your features, sites to should not be done using a file copy as this may be an issue when you have multiple servers in your farm.  The correct way to deploy them is to create a solution package.  A solution package is a single file with an .wsp extension that contains all your resources you wish to deploy to the 12 hive.  Once you have created your solution package, simply deploy it to the farm and it will be copied into the 12 hive of all the servers in the farm.

Reasons to deploy using a solution package

Now it is important to highlight issues to the reasons why you should rather use solution packages instead of manually copying them over.

1. SharePoint tracks usage of the components and will give errors should you try to uninstall the solution package if being used.
2. Deploying to multiple servers in a farm could be prone to human error and one may forget to deploy to a server.
3. Should a server be down while deploying, you may forget to to deploy to the server when it comes up again.  However with as solution package it will automatically be deployed to the server when it comes up.
4. When installing new servers into your farm, you may forget to install your components especially if you have a lot of components that were added over time.  Provisioned solution packages will automatically be deployed to new server that are added to the farm.
5. Deploying custom DLL's to the Global Assembly Cache to a remote machine may be tricky.
6. Deploying custom DLL's to every bin folder of each web application that uses your components may be tricky especially on a server where new web applications and site collections are being used.
7. Modifying the web.config on all servers may be pose problems, using a solution package you can very easily modify the web.config especially your safe controls section.

WSS is a exceptionally strong provisioning engine which will manage the deployment of your components and resources to multiple servers in a web farm automatically.

The bottom line here is if you do not use a solution package, you are giving yourself more problems than you need.  These will definitely come back and bite you at a later date, causing you and many other people unnecessary stress.  It is easy to resolve this by creating a solution package.

How does deployment work with a solution package

The diagram below indicates what needs to be done to create a solution package.

Step 1 - Create custom features

The first thing that a developer has to do is to make the necessary features, templates, assemblies, web parts, pages and other resources that need to be placed into the 12 hive.  The developer will copy and test these features to his/her development machine to make sure it works.

For more information, see

• Creating a simple SharePoint Feature.xml file
• SharePoint - How to provisioning a site column with CAML
• Describing the ElementManifests section in a SharePoint feature.xml file
• SharePoint - Provisioning a content type with CAML
• SharePoint - The TEMPLATE folder in the 12 Hive
• The content of a SharePoint ElementManifest file
• SharePoint - Register an assembly as a safe control in the Web.config file

Step 2 - Create a solution manifest with CAML

The next step is create a CAML solution manifest that is called manifest.xml.  This solution manifest will contain all the information about the resources that need to be deployed.  When executing stsadm -o deploysolution, this manifest will be read and executed on all servers on the farm.

For more information, see

• SharePoint -  Creating a solution manifest
• SharePoint - Adding a feature to a solution manifest
• SharePoint - Adding a webpart to solution manifest
• SharePoint - Deploying assemblies with a solution manifest

Step 3 - Build a cab file (.wsp)

1. The programmer then needs to generate a data description file (ddf) with a text editor that contains a list of files to add to the .wsp (cabinet) file.  This ddf file will contain all the resources file names and the manifest.xml file that need to be deployed to the 12 hive.
2. Using makecab.exe <ddf filename>, the cabinet file with extension .wsp will be created.

For more information, see

• SharePoint - Creating a solution package with makecab.exe

Step 4 - Deploy the solution package.

1. The developer gives the single .wsp file to the administrator.
2. The administrator then uses stsadm -o addsolution -filename pathname\<package.wsp>.  This adds an asynchronous job to load the solution package file into the configuration database. 
   You can force the job to run immediately by executing stsadm -o execadmsvcjobs.  At this point the solution package is copied into the the configuration database.
3. Finally, the administrator deploys the package to the the farm, this will read the manifest.xml file in the solution package and proceed to extract the contents into the 12 hive.
   This is done by executing stsadm -o deploysolution -name <package.wsp>.  This will execute a job on every server in the farm and whereby the server opens the solution package, reads the solution's manifest.xml file and deploys what is defined in the manifest file.

Note the following

• The package is deployed to all servers in the farm, regardless of geography.  The state of what has been deployed to what server is managed in the config database.
• Should a server be offline when you deploy the solution, when it comes online there will be a job waiting for it to deploy the package. The job will be executed on startup thus ensuring the package is deployed.
• Should you add a new server to the farm, even months later. A job will be created to deploy all packages to the new server.  Thus when the new server comes online after being added to an existing farm, it will have all the packages deployed.

See Also

• SharePoint - Get to know the directory structure in the 12 Hive
• SharePoint - The TEMPLATE folder in the 12 Hive
• Overview of features, templates, site definitions, solutions in SharePoint
• SharePoint - Applications, Site Collections and Sites