Deploying Content

Your content is ready and approved on your staging server. Now it's time to move this published content to your production servers which will probably be read only. SharePoint Server 2007 provides a feature evolved from Microsoft Content Management Server that will deploy content from one farm to another over the http or https protocol.

This feature, called Content Deployment, is covered in detail in Chapter 11, "Web Content Management and Publishing Features." This section focuses on how the choices you've made regarding languages and variations affect content deployment planning.

Your Web publication design may involve servers that are centrally located or dispursed around the world (geo-deployed). Content deployment can be used for both local and geo-deployed multilanguage sites when the various language sites are self-contained sites and not part of a variation hierarchy. The content deployment process is not language aware and deploys content in any language.

With local deployments from the staging process to production, content deployment is a useful tool for variation hierarchies because you are deploying the entire site collection. The Content Deployment feature can also be used in conjunction with the Variation feature to enable geo-deployed multilingual solutions. The goal of a geo-deployed solution would be to place the sites in various languages physically close to the largest user base of the language. However, this scenario does introduce some complications.

Although you might want to use variations to create the various language copies of the source site and then use content deployment to stage the individual sites to different servers around the globe (geo-deployment), this is not recommended.

The recommended method to implement a geo-deployment solution is to have Content Deployment jobs that deploy the entire site collection variation hierarchy rather than deploying only sites for specific languages. Some variation functionalities, such as picker controls, require the entire site collection to work properly. Using this approach, it's possible to have read-only instances of the same site collection distributed in multiple locations. Although using Content Deployment jobs will deploy more content than just an isolated site, it does assure functionality of the site collection.

If you are going to experiment with other content deployment scenarios, the treatment of reusable content should be considered in your trials. Also, remember that Content Deployment jobs only deploy content, not custom code; therefore, if you developed custom Web Parts or templates, they must be installed on the Content Deployment target sites.