[阅读笔记] Content Deployment 完全指南 之一 基础知识

提示: 简单易懂的部分, 或者不是那么要紧的部分, 就不再翻译, 简单陈列在此.

主要目的

===========

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 – but also to have a single authoring environment and then push the content to multiple different farms of different departments - potentially on different continents.

Content Deployment 是一个Feature

===========

You can find this feature in the following directory: …\12\template\features\DeploymentLinks

This feature is activated on the Root Web of the Central Admin site collection. Be aware that this is a hidden feature so you cannot see it in the site feature list in the UI.

Deactivating this feature will remove the Content Deployment section from the central admin Web site and also disable the underlying functionality of Content Deployment as several methods verify internally if this feature has been enabled on the central admin Web site or not. You can easily try this on your own using the following command: STSADM -o deactivatefeature -url http://central-admin-url -name DeploymentLinks After executing this command you will see that the content deployment section is gone from the operations tab. To reenable the functionality use this command: STSADM -o activatefeature -url http://central-admin-url -name DeploymentLinks

Content Deployment 的种类

============

MOSS2007中有三种可用: 完全部署, 增量部署, 快速部署. 下面是它们的简介:

完全部署

----------

不论何时创建的内容, 整个站点的内容都会被部署到目标站点集上. 一般在第一次部署一个站点集的时候使用.

缺点: 仅能部署原站点的当前状态. 如item的删除, 添加这样的历史信息都不会被部署 优点: 不管之前在目标站点上部署了什么内容, 它总是导出源站点集的当前状态. 警告: 向一个已经通过内容部署作业获得过内容的数据库使用完全部署, 会引起源场和目的场中的不一致, 因为历史动作信息时不会被部署的. 比如说, 一个列表项在源场中删除了, 而这个动作发生在两次内容部署动作之间, 你会发现这个列表项在目的站点集中没有被删除.
增量部署

-----------

增量部署会deploy上次content deployment job成功运行之后的, 所有的更改过的内容. 只有被更改过的内容会被deploy到目标服务器场上. 增量部署也传递诸如移动, 删除, 重命名这样的历史动作到目标服务器场中.

缺点: 复杂度要远远超过完全部署. 这是因为直接部署修改过的内容和item到服务器场中对应的内容上需要额外的处理逻辑. 这增加了发生问题的几率, 而这里的问题会导致增量部署失败. 第二个缺点是增量部署只会查看源系统来确定必须要被部署的数据. 它不会在分析源系统和目的系统的区别后再决定部署什么内容. 优点: 由于只部署修改过的内容, 增量部署通常都会比完全部署要快. 另外, 部署历史动作的信息会允许目标系统与源系统保持一致, 这超过了完全部署的能力. 警告: 如果一个增量部署重复地失败, 那么它可能需要从新执行一次完全部署, 从而使得源场与目的场的内容重新保持一致. 由于完全部署不会传输历史动作信息, 这样的动作仅在目标场是一个空数据库的时候才比较可靠.
快速部署

-----------

快速部署允许作者挑选特定的页面进行content deployment. 这对于某些需要快速更新他们站点中的特定页面, 而且增量部署不能满足他们的需要的公司来讲非常重要.

缺点: 快速部署仅deploy某些被选择了的页面以及与这些页面相关联的资源. 另外, 还不能选择普通文档库或者列表中的项目来进行快速部署. 优点: 快速部署允许作者注册某些项目, 快速的部署他们到目标场中, 同时忽略上一次成功的部署(完全或增量)后源服务器场的任何修改. 警告: 快速部署仅处理publishing pages, 还有与这些pages相关的资源. 站点和列表不能通过快速部署来deploy. 正因为如此, 所有的相关的目标文件夹和文档库必须已经在目的服务器场中存在, 要不然快速部署就会失败. 比如说, 一个新的图片库被创建出来了, 这个图片库中的一个图片与publishing page产生了关联, 而这个publishing page需要被快速部署. 这时, 快速部署就会失败, 因为这个图片库并没有被部署到目的站点集上.

关于完整, 增量, 快速部署的误区与事实 译注: 这段非常重要!

====================

误区: 每一个path至少需要一个完整部署的job和一个增量部署的job, 因为我不得不在开始时至少运行一次完全部署, 然后我才可以运行增量部署.

事实: 上面的说法是错误的. 最开始的增量部署总会是一次完全部署的. 所以没必要创建一个完整部署的job.

误区: 完整部署比增量部署要多.

事实: 上面的说法是错误的. 完整部署仅部署当前站点的状态, 而增量部署会部署自从上次部署之后所有完成了的修改. 这同时也包括删除和移动的操作. 一个极端的例子是一个上次deploy是拥有100,000个item的站点集. 在删除90,000个item之后, 完整部署仅会部署10,000个剩下的item, 并不会包括删除的操作(假设删除操作后没有其他的操作了). 而另一方面呢, 增量部署仅会部署90,000个删除了的item, 来确保目标站点集上这些item也被删掉. 换句话说: 经过完成部署之后, 源和目标数据库会不一致, 而增量部署会去保持他们的一致.

误区: 平时进行增量部署, 周末进行完全部署是保持内容数据库同步的最佳实践.

事实: 上面的说法是错误的. 每一次的完整部署都有让目标站点与原站点不一致的风险, 因为删除和移动操作并不会被应用到目标站点上, 同时这也会带来风险导致今后的content deployment job失败, 因为源和目的站点的不一致性.

误区: 如果增量部署失败了, 我可以通过完整部署来修复问题.

事实: 这个说法是错误的. 确实: 在增量部署失败的时候完整部署经常成功. 确实: 接下来的增量部署也都经常会再次成功, 但这是由于经过完整部署之后, 下一次的增量部署仅仅会部署上次完整部署后修改过的Item. 问题在于, 在这样的情况下, 你并没有真正的解决潜在的问题. 你仅仅是通过向包(package)中添加源站点集中已经存在的其他内容, 来迫使导致增量部署失败的源数据库的不一致性不再出现. 但是通常, 同样的问题会在几天之后增量部署不得不deploy问题item的时候再次出现. 并且, 通过完整部署, 你让情况更加糟糕了, 因为你使得潜在上的目标和源之间的不一致更多了, 为什么会更多了呢? 因为本来要通过错误的deployment来部署的删除和移动操作再不会被deploy了. 所以当你对稍早时候失败了的数据库中添加了更多的不一致的item的时候, 未来的content deployment会更加频繁的出问题(增量部署, 完全部署都一样).

误区: 快速部署是一种简单的方式, 来确保重要的内容可以

事实: 上面的说法不完全正确. 快速部署一定要小心使用. 对于每一个单个的快速部署的item, 而且对于所有依赖的item(比如说引用的图片和文档), 一定要确保: 这个item所存在的站点, 文件夹, 列表, 文档库已经被早些时候的增量部署部署到了目标站点上. 如果不是这样, 那么快速部署job就会失败, 并且所有未来的快速部署job都会失败, 之道下一次增量部署执行后为止. 这意味着一个用户的快速部署(部署一个页面应用了目标站点中不存在的图片或文档), 可以引发问题从而影响到所有其他用户的快速部署. 这里的主要问题是快速部署是由作者完成的, 而增量部署是由场管理员控制的. 所以, 通常作者并不清楚上一次增量部署什么时候成功, 还不知道哪个站点和列表已经被部署了.

原文地址:

Content Deployment – The complete Guide – Part 1 – The Basics

http://blogs.technet.com/stefan_gossner/archive/2009/10/30/content-deployment-the-complete-guide-part-1-the-basics.aspx