|
I wonder sharepoint experts ideas about deployment of sharepoint projects/portals via site collection backup & restore, instead of visual studio solutions? Especially for the projects that will be deployed and used only in a single environment. (Projects that will not be deployed to multiple areas). What are the pros and cons? And i wonder how many of you/your company choose site collection backup/restore as the deployment method? |
||||
|
|
|
The problem you may find is if there are any resources outside of the site/site collection that are needed such as files in the Hive, etc... Backup/Restore only gets site content, it will not get anything that is external to the site. There are many things you can do with WSP files that you cannot do with simple backup/restore. References, dependencies, Activation/deactivation tasks, etc... Also note that when restoring sites/subsites you can also be affected by what features are currently activated in the site collection vs. what features are activated on the site you are restoring. For example many of the publishing features rely on other features to be activated and restoring a site will not do this for you. It can cause you to get stuck in situations where you cannot use certain features on your site because you restored it to a site collection that either does not support the features or where they are not activated. In these cases you will usually get vague references that the feature could not function due to be dependent on a site collection level or hidden feature. Overall, I tend to stick to using backup/restore for it's original intent of recovering or moving a site, not for deployment of features or customizations. Hope this helps... |
|||
|
|
|
We use both site collection backup/restores as well as database restores. I prefer copying the database from the source SQL server and restoring it to the target SQL server. Then we attach it to the SharePoint 2010 web application via central admin > application management > manage content databases. |
|||||
|
