In SharePoint, we need to concentrate on lot of things while moving site from one environment to another environment and make it up
Based on my experience, I am sharing some of the details with you guys
If you are using VSIDE to develop your site for example creating custom web parts, master pages, css files, features etc...and then developed using VSIDE Then WSP package is best solution but this will solve only half portion of your requirement that means you are deploying static content means the data which will not change frequently
But, you need to think about how the dynamic data will be deployed from one environment to another environment dynamic content means the content which is authored by client like new article page, new documents uploaded into document library etc...
here you need to use either content deployment or Export /Import but in my SharePoint journey I have used both, choosing the right option is depends on how our environment is setup?
If your environment is farm environment and having multiple nodes with reliability and security then we can use content deployment option because content deployment will transfer the data on wire so, make sure that there should not be any connection failure while doing content deployment
Before doing content deployment you need to consider lot of things
1. The source farm and destination farm should be identical, assume that you have installed latest service pack or language packs on source farm and the same is not available on destination farm then this will give problem and the content deployment will fail.
2. The destination site collection should be blank site collection if not then the job will fail because when The first time the content deployment job runs, the correct template and all associated configuration settings will be applied to the destination server if site collection already contains data then the job will fail.
3. The disk space in source and destination farm should be enough otherwise disk allocation problem will occur because when job starts it will create a cab file in source temporary folder and export into destination farm temporary folder.
4. if you have any custom features to install in destination server just install before running your job but don't activate the features because if you activate that will create data in content database so, this may lead to content deployment fail.
5. Don't run the content job's parallel this may lead to content job fail.
Normally SharePoint enterprise application will have two farm topology authoring and production farm. Authoring farm works on AD and production is internet facing site and works on FBA, the content authors will upload the data into authoring site and the same will be available in production site through content deployment. There is no specific requirement to have only two farm topology, based on requirements you can build multi-farm,I worked for one client who is having five farm topology
I suggest to use content deployment because you can do differential content deployment that means whatever changes made recently will be only moved to one environment to another environment so, this will not override existing content
Based on my experience, I am sharing some of the details with you guys
If you are using VSIDE to develop your site for example creating custom web parts, master pages, css files, features etc...and then developed using VSIDE Then WSP package is best solution but this will solve only half portion of your requirement that means you are deploying static content means the data which will not change frequently
But, you need to think about how the dynamic data will be deployed from one environment to another environment dynamic content means the content which is authored by client like new article page, new documents uploaded into document library etc...
here you need to use either content deployment or Export /Import but in my SharePoint journey I have used both, choosing the right option is depends on how our environment is setup?
If your environment is farm environment and having multiple nodes with reliability and security then we can use content deployment option because content deployment will transfer the data on wire so, make sure that there should not be any connection failure while doing content deployment
Before doing content deployment you need to consider lot of things
1. The source farm and destination farm should be identical, assume that you have installed latest service pack or language packs on source farm and the same is not available on destination farm then this will give problem and the content deployment will fail.
2. The destination site collection should be blank site collection if not then the job will fail because when The first time the content deployment job runs, the correct template and all associated configuration settings will be applied to the destination server if site collection already contains data then the job will fail.
3. The disk space in source and destination farm should be enough otherwise disk allocation problem will occur because when job starts it will create a cab file in source temporary folder and export into destination farm temporary folder.
4. if you have any custom features to install in destination server just install before running your job but don't activate the features because if you activate that will create data in content database so, this may lead to content deployment fail.
5. Don't run the content job's parallel this may lead to content job fail.
Normally SharePoint enterprise application will have two farm topology authoring and production farm. Authoring farm works on AD and production is internet facing site and works on FBA, the content authors will upload the data into authoring site and the same will be available in production site through content deployment. There is no specific requirement to have only two farm topology, based on requirements you can build multi-farm,I worked for one client who is having five farm topology
I suggest to use content deployment because you can do differential content deployment that means whatever changes made recently will be only moved to one environment to another environment so, this will not override existing content
