3. Content Deployment – The Idea Content Deployment allows to push out content from one server farm to another . Content Deployment allows the deployment of content from exactly one site collection on the source farm to exactly one site collection on the target farm MOSS 2007 contains Content Deployment as a new feature which has been added to fulfill the requirements of companies which plan to use SharePoint as a Web server to host public facing Web sites The main purpose is to allow authors and reviewers to modify and evaluate on a different farm before the content is finally pushed to the public facing server farm http://manish-sharepoint.blogspot.com/
4. Content Deployment – The Idea To have a single authoring environment and then push the content to multiple different farms of different departments - potentially on different continents. The entire source site collection can be copied (full), or a subset of sites can be copied (incremental). In either case, content deployment is incremental by default, deploying only changed pages and related assets (such as images) Content deployment only copies content — Web pages and resources used by the copied pages. It does not deploy programs, assemblies, features, configuration information such as web.config files. When a Web page is deployed, any items in the content database that the page depends on — such as images, style sheets, or layout pages — will also be deployed. http://manish-sharepoint.blogspot.com/
7. Content Deployment Path A path is basically a connection between a source farm and a destination farm or The link between the source and target site collection is called a content deployment path The path contains information about which source web application and site collection you are deploying, authentication information for the destination farm, and the web application and site collection on the destination farm. Multiple content deployment paths are possible in the farm as long as we don't have multiple paths that reference the same source and target site collection A content deployment path is always defined on the source farm. A path by itself doesn’t actually deploy any content. http://manish-sharepoint.blogspot.com/
8. Content Deployment Job A job is associated with a path, and it determines exactly which sites in the source site collection will be deployed and on what schedule One or more content deployment jobs for a single content deployment path. Each job can be of a different type Full Incremental Quick deployment The content deployment job is always defined on the source farm Each job can be configured with a different schedule. http://manish-sharepoint.blogspot.com/
9. Steps for Content Deployment Create Production Site Collection and take Blank Template Allow Incoming Content Deployment Jobs on the Production Site Create Content Deployment Path from Staging to Production Click New Path Click Connect and Click OK Create Content Deployment Job Run Content Deployment Job Run Quick Deploy Job http://manish-sharepoint.blogspot.com/
10. Quick Deployment Job Content Deployment has a special job called “Quick Deploy” that is automatically created for every path in any site collection with the Publishing Resources feature enabled. This job, once enabled in a path, runs every 15 minutes, by default) and checks a special list for content that should be deployed. If the site owner has rights, he or she can deploy pages quickly to production by using the “Quick Deploy” link on the Page Editing toolbar. This adds that page to the special list, which the Quick Deploy job will check the next time it wakes up http://manish-sharepoint.blogspot.com/
11. Content Deployment Job Process Every time a content deployment job runs, the following five steps are always executed: Check the change log to determine changes. After a job successfully completes a schedule, in the last step it updates the log on the source server to track the status of the content on the destination servers. This status is initially checked by each job to determine which content needs to be updated on the destination servers. Create a new package on the source server. This package is created based on information in the change log and temporarily deployed on the source server file system. http://manish-sharepoint.blogspot.com/
12. Content Deployment Job Process Send the package to the destination server. The deployment job uses HTTP or HTTPS protocols (depending on the setting in the Content Deployment feature). Apply changes to the destination server. After a package arrives at the destination server, the content deployment job temporarily extracts the files to a local folder and starts to apply the changes. It’s important to understand that this is not a transactional operation — if something happens while changes are being applied (such as a local failure, an exception, or a power outage), all changes that were applied successfully will not be rolled back. The next time the same job runs, it will try to re-apply the same changes. Update the change log on the source server. The last step a job performs is to update the content status of the destination site collection on the source server. http://manish-sharepoint.blogspot.com/
13. Important Considerations The servers configured as export and import server need to host an instance of the Central Administration website Ensure that sufficient disk space is available Use an empty site collection as the destination of your content deployment job Install all required features for your site on the destination server Do not activate custom features for your site collection on the destination server manually http://manish-sharepoint.blogspot.com/
14. Important Considerations The incremental deployment will not deactivate features in the destination server site collection Ensure that all feature definitions of features activated on the site collection exist on the source server Ensure that content deployment jobs do not run in parallel Ensure that the patch level on source and destination farm is identical http://manish-sharepoint.blogspot.com/
Notas del editor
Create Production Site Collection When setting up a content deployment path, the site collections must be in separate content databases so that the unique identifiers (GUIDs) do not conflict. The easiest way to ensure that the production site collection is in a different content database is to create it in a new web application. Open Central Administration: Under Application Management: Select Create or extend Web application: Select Create a new Web Application: Choose an easy to remember port number, such as 12345: Type in a user name and credentials to create a new app pool: Type in a descriptive database name such as MOSS_PRODUCTION: Leave all other settings at the default and click OK, then wait for the Web application to be created: Click Create Site Collection: Ensure that your new Web Application is selected: Type in any name for the Title (it will be overwritten later): Select "Blank Site" as the template. This step is IMPORTANT, because Blank Site is the only template that you can import any other template into: Type in the names for the site collection owners: Click OK. Allow Incoming Content Deployment Jobs on the Production Site Select Operation: Select Content deployment settings: Select Accept incoming content deployment jobs: Select Do not require encryption and click OK: Create Content Deployment Path from Staging to Production Select Content deployment paths and jobs: Click New Path: Type a descriptive name for the path. Select the web application and site collection for the staging site. Then type in the URL of the Central Administration web site of the production site. Since we are putting both of our sites on the same server farm, the URL is the farm that we are on now. Click Connect: Once you see "Connection succeeded", select the web application and site collection that you created for production. You can also choose to deploy user names and security if you want the new site to have the same users and permissions. Click OK. Create Content Deployment Job Click New Job: Type a name, and then select the path you created: Keep all other default values, and click OK. Run Content Deployment Job From the context menu on the job, select Run Now: Refresh the page, and then click on the text Running: Watch the status of the job: When the status changes to Succeeded, you can click on the URL to the production site to verify that the content was deployed. Run Quick Deploy Job Select Quick Deploy Settings from the Quick Deploy context menu: Select Allow Quick Deploy jobs along this path, and set the schedule to check every 10 minutes, then click OK: Visit the staging site and edit a page: Make some changes: Publish the page: Show the page editing toolbar: From the Tools menu, select Quick Deploy: The changes will be picked up and deployed to production within 10 minute:
Create Production Site Collection When setting up a content deployment path, the site collections must be in separate content databases so that the unique identifiers (GUIDs) do not conflict. The easiest way to ensure that the production site collection is in a different content database is to create it in a new web application. Open Central Administration: Under Application Management: Select Create or extend Web application: Select Create a new Web Application: Choose an easy to remember port number, such as 12345: Type in a user name and credentials to create a new app pool: Type in a descriptive database name such as MOSS_PRODUCTION: Leave all other settings at the default and click OK, then wait for the Web application to be created: Click Create Site Collection: Ensure that your new Web Application is selected: Type in any name for the Title (it will be overwritten later): Select "Blank Site" as the template. This step is IMPORTANT, because Blank Site is the only template that you can import any other template into: Type in the names for the site collection owners: Click OK. Allow Incoming Content Deployment Jobs on the Production Site Select Operation: Select Content deployment settings: Select Accept incoming content deployment jobs: Select Do not require encryption and click OK: Create Content Deployment Path from Staging to Production Select Content deployment paths and jobs: Click New Path: Type a descriptive name for the path. Select the web application and site collection for the staging site. Then type in the URL of the Central Administration web site of the production site. Since we are putting both of our sites on the same server farm, the URL is the farm that we are on now. Click Connect: Once you see "Connection succeeded", select the web application and site collection that you created for production. You can also choose to deploy user names and security if you want the new site to have the same users and permissions. Click OK. Create Content Deployment Job Click New Job: Type a name, and then select the path you created: Keep all other default values, and click OK. Run Content Deployment Job From the context menu on the job, select Run Now: Refresh the page, and then click on the text Running: Watch the status of the job: When the status changes to Succeeded, you can click on the URL to the production site to verify that the content was deployed. Run Quick Deploy Job Select Quick Deploy Settings from the Quick Deploy context menu: Select Allow Quick Deploy jobs along this path, and set the schedule to check every 10 minutes, then click OK: Visit the staging site and edit a page: Make some changes: Publish the page: Show the page editing toolbar: From the Tools menu, select Quick Deploy: The changes will be picked up and deployed to production within 10 minute: