Sharepoint deployment waz not that eazy. There’s no defined method to do that. But we can use some mechanisms wchich are built into MOSS. One such component is stsadm. For the deploymet purposes we can use either export/import or backup/restore mechanisms. My recommendation is export/import since the latter is appropriate for a catatrophic scenario. Our friendly stsadm tool will help to perform export/import.
First you export your custom sharepoint site from your development server into a file with a .dat extention. This file can be imported from the target server (at client end may be) so that we can deploy the customized version at client’s end this way. Within the import command we can specify the site collection as below.
stsadm -o import -url http://<servername>/site -filename <filename>
Although we can deploy a site collection like this, change requirements might raise some issues. for example if the client need to change the UI and all the styles, we have to export and import for each client requirement. and the data which was originally existed might be replaced due to the new import operation. This is not what developers would like to confront.
Therefore the solution to tackle this scenario is the Web Solution Packages (WSP). Package all UI components and style sheets into a one bundle as a feature and deploy it. This involves creating a manifest file, feature manifest file, feature file and a data definition file (.ddf). As for my opinion, this is the best way for deploying standalone components to a front-end wwweb server. After the deployment, you can enable the feature from Site collection features under Site Actions. For the purpose of deploying .wsp files (cab file with a .wsp extention) we can following commands.
stsadm -o addsolution -name <filename>
stsadm -o deploysolution -name <filename> -local
This way, sharepoint developers can easily handle change requirements.