One of the interesting question has been raised in most of discussion fourms is Deployment Options Comparison and which is the best way to deploy and pros/cons. Here's the small comparison between all the deployment options. Also, i would like to recommend MOSS 2007 Deployment Wizard tool. The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:
- site collections
- webs
- lists
- folders
- list items (including files)
Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview. You can download the tool from www.codeplex.com/SPDeploymentWizard
Comparison between all the deployment options
| |
STSADM |
Content Deployment |
Content Migration API |
Features Deployment |
| Description |
Uses STSADM commands to generate a file (export) which can then be transferred to the target for import. One of the simplest ways of moving content from one place to another, although unlikely to be suitable as a continuous deployment mechanism.
Examples:
stsadm.exe -o export -url http://localhost -filename C:\Export.cab -includeusersecurity -versions 4 -overwrite
stsadm.exe -o import -url http://localhost/sites/newsite -filename C:\Export.cab -includeusersecurity
|
Configured via 'Content Deployment paths and jobs' in Central Admin ('/_admin/deployment.aspx'). A path defines the source/target and authentication details, specific jobs define exactly which content should be deployed and how often. Quick deploy functionality allows users with permissions to specify important content which should be deployed more regularly than existing job schedules configured by administrators (quick deploy items are deployed every 15 mins).
|
Involves writing code which uses the content migration API (known as PRIME) to export then import content - the API is easy to use.
|
Involves defining XML configuration files which SharePoint uses to add artifacts in the correct way on the target. This can be significantly more complex than simply developing in SharePoint Designer but can allow for better management throughout a solution's lifecycle.
|
| Good for |
1. Moving an entire site/web as a one off
2. Quick deployment tests
3. Reparenting webs (can be into a different site collection) |
1. Moving entire site collections/webs on a scheduled basis e.g. in an authoring/production or authoring/staging/production topology
2. Deploying only incremental changes, e-mail notifications of success/failures
3. Allowing site owners to have some control over content deployment via Quick Deploy
4. Automatically deploying dependencies of content selected for deployment, even if in different site (e.g. page layouts/content types/site columns/referenced images etc.)
5. Automatically transferring the deployment package to the target environment (via HTTP )
Not transactional |
1. Complete flexibility over deployment options
Granular control over what gets deployed (down to item level)
2. Ability to preserve object GUIDs (so that list GUIDs do not need to fixed-up)
3. Ability to select options for security, versioning and user roles |
1. Iterative development/deployment
Deployment of assemblies and filesystem files (none of the other methods deal with this)
2. Ability to deploy assemblies/filesystem files to all servers in a farm with Solution packages
3.Possibilities for continuous integration |
| Considerations |
1. Content on target will be overwritten if already exists
2. Granularity down to web only
3. Object GUIDs are not preserved (so some things will need to be 'fixed up' e.g. anything that references a list by GUID - ListViewWebPart, using lists with InfoPath forms)
4. Not a backup/restore tool - although it's the option which is most like backup/restore, things like alerts, audit trail, recycle bin items, security state, workflow tasks/state are not exported
5. Not transactional
|
1. Content on target will be overwritten if already exists
2. Granularity down to web only
3. No differentiation between site content (e.g. pages/images) and site 'infrastructure' (e.g. master pages, page layouts)
4. Object GUIDs are preserved
Blank site template should be used for source and destination (see http://support.microsoft.com/kb/923592)
5. Also not a backup/restore tool (see above) |
1. Blank site template should be used for source and destination (see http://support.microsoft.com/kb/923592)
2. Not transactional
Also not a backup/restore tool (see above)
3. Need development skills to write code
|
1. Developer is responsible for evaluating and deploying dependencies (e.g. underlying content types).
2. Updates to content types, list definitions, site columns etc. deployed via a Feature must be done with the API - modifying original Feature files and then reprovisioning is not supported
3. Can be very time-consuming due to lack of assistance from current tools
|