2007年10月29日,星期一

STSADM导出,内容部署,内容迁移API,功能/解决方案-比较部署选项

早在5月,我写了一篇标题为 的SharePoint部署选项:功能还是内容部署?,其中讨论了有关在SharePoint网站开发过程中将资产从开发转移到生产(或介于两者之间的环境)的“正确”方法的一些想法。现在,我从事其他项目并在每个项目上有意识地使用了不同的部署方法,我很快得出结论,部署的“正确”方法会因情况而异。因此,我认为可能有用的是对整个部署选项范围进行分析,并提供有助于您更轻松地决定如何完成此过程的关键步骤的信息。

因此,让我们看一下这些选项及其特征。顺便说一句,所有选项都不使用“破坏性同步”,其中 所有 导入之前先删除内容。

使用STSADM导出/导入

描述:

使用STSADM命令生成文件(导出),然后可以将其传输到目标以进行导入。将内容从一个地方移动到另一个地方的最简单方法之一,尽管不太可能适合作为连续部署机制。例子:

stsadm.exe -o导出-url http:// localhost-文件名C:\ Export.cab -includeusersecurity-版本4-覆盖

stsadm.exe -o导入-url http:// localhost / sites / newsite -文件名C:\ Export.cab -includeusersecurity

适用于:

  • 将整个站点/网站作为一个整体移动
  • 快速部署测试
  • 父网站(可以进入不同的网站集)

注意事项:

  • 目标上的内容将被覆盖(如果已存在)
  • 粒度仅限于网络
  • Object GUIDs 是 not preserved (so some things will need to be 'fixed up' e.g. anything that references a list by GUID - ListViewWebPart, using lists with InfoPath forms)
  • Not a backup/restore tool - 一种lthough it's the option which is most like backup/restore, things like alerts, audit trail, recycle bin items, security state, workflow tasks/state 是 not exported
  • 不交易

通过管理中心使用内容部署 *

描述:

通过Central Admin('/_admin/deployment.aspx')中的“内容部署路径和作业”进行配置。路径定义了源/目标和身份验证详细信息,特定的作业确切地定义了应部署的内容以及频率。快速部署功能允许具有权限的用户指定重要内容,这些内容应比管理员配置的现有作业计划更定期地部署(每15分钟部署一次快速部署项目)。

适用于:

  • 定期移动整个网站集/网站,例如在创作/制作或创作/登台/制作拓扑中
  • 仅部署增量更改,通过电子邮件通知成功/失败
  • 允许网站所有者通过“快速部署”对内容部署进行一些控制
  • 自动部署选择要部署的内容的依存关系,即使在不同的站点中(例如页面布局/内容类型/站点列/引用的图像等)
  • Automatically transferring 部署 package to the target environment (via HTTP[S])
  • 不交易

注意事项:

  • 目标上的内容将被覆盖(如果已存在)
  • 粒度仅限于网络
  • 网站内容(例如页面/图像)和网站“基础结构”(例如母版页,页面布局)之间没有区别
  • Object GUIDs 是 preserved
  • 空白网站模板应用于 来源和 目标网站集(请参阅 http://support.microsoft.com/kb/923592)
  • 也不是备份/还原工具(请参见上文)

使用内容迁移API *

涉及编写使用内容迁移API(称为PRIME)导出然后导入内容的代码-该API易于使用。

适用于:

  • 完全灵活的部署选项
  • 对部署内容进行细粒度控制(直至项目级别)
  • 保留对象GUID的能力(因此列表GUID不需要修复)
  • 能够选择安全性,版本控制和用户角色的选项

注意事项:

  • 空白网站模板应用于 来源和 目标网站集(请参阅 http://support.microsoft.com/kb/923592)
  • 不交易
  • 也不是备份/还原工具(请参见上文)
  • 需要开发技能才能编写代码

使用功能/解决方案

此博客的重点 几篇文章。涉及定义XML配置文件,SharePoint用来以正确的方式在目标上添加工件。这可能比仅在SharePoint Designer中进行开发要复杂得多,但可以在解决方案的整个生命周期中进行更好的管理。

适用于:

  • 迭代开发/部署
  • 部署程序集和文件系统文件(其他方法都不能解决此问题)
  • 能够使用解决方案包将程序集/文件系统文件部署到服务器场中的所有服务器
  • 持续整合的可能性

注意事项:

  • 开发人员负责评估和部署依赖项(例如基础内容类型)。
  • 通过功能部署的内容类型,列表定义,站点列等的更新必须使用API​​完成-修改原始功能文件,然后不支持重新配置
  • 由于缺乏当前工具的帮助,可能会非常耗时

* 有关使用Content Deployment或Content Migration API的一些其他说明:

- 一种ppropriate Features will 自动ally be 活性 在目标上,但必须存在(即已安装)它们才能进行内容部署(目标首次启用时,不应在目标上启用N.B.发布功能)

-不应将带有RetainObjectIdentity选项的Content Deployment或内容迁移API与STSADM -export / import结合使用,因为后者将分配新的ID!

因此很明显,在选择如何进行项目部署时可以考虑几个方面。在很多情况下,功能/解决方案不是最合适的选择,我倾向于使用内容迁移API,这主要是因为其他任何选项都没有提供灵活性。当然,这的确意味着编写代码,但是正如我上次提到的那样,我将很快分享我编写的微型应用程序,因此您不必这样做!

一些有用的参考:

2007年10月14日,星期日

使用STSADM导出或内容迁移API进行部署

有 focused on 部署使用 Features 对于几篇文章, 早在五月,我写了一篇标题为 的SharePoint部署选项:功能还是内容部署?,它探讨了围绕 SharePoint项目的部署策略。可以使用多种方法 将SharePoint工件和内容从一个地方移动到另一个地方,我认为可以说部署方面仍然存在一定的混乱 适用于许多SharePoint开发人员。我当然不会声称获得所有答案,但是上周交付了另一个项目之后,似乎是回顾一些经验和交流的好时机。 reflect 在不同的方法上。

不用说,就总体部署策略而言,最好的主意是 拥有一个!我看到许多来自 人们接近  在开发阶段结束时,询问他们应该如何将工作转移到 实时服务器。我发现离开部署直到 end of the project, is that none of the approaches are 完全地 直接(尤其取决于您的解决方案组成),等等 if your project is 准时交货很重要 to 知道您可能需要执行哪些步骤。

附带说明一下,让我们在这里阐明一些可能引起混淆的术语:

  • 内容部署-可用于移动内容的“路径和作业”功能, surfaced by 管理中心中的屏幕
  • 内容迁移API-基础API(有时称为PRIME),实际上用于两个STSADM导出 除了“管理内容和结构”工具以及从CMS2002迁移而来的内容部署(以略有不同的方式)

这次,我决定使用内容迁移API来部署我们的解决方案,并且它可以正常工作 适合我们的情况。这与我过去完成的功能开发形成了对比,选择这种方法的主要原因是: 

  • 无需迭代部署 - 尽管我们的整体项目是分阶段进行的, 对于这个组件,我们能够 开发解决方案,然后部署我们开发环境中的所有内容。 (这种方法将 not work 对于后续部署,因为我们的客户在实时网站上生成的内容将在每次部署中被覆盖-有关更多信息,请参见下一篇文章。
  • 保留对象GUID的能力 - 因为我们的项目大大简化了部署,因为 如果我们的列表在部署时被分配了新的GUID(与STSADM导出/导入一样),则引用这些列表的组件(ListViewWebPart,InfoPath表单等)将无法正确连接 the 部署 target. This would add a lot of "fix-up" steps to 部署 process if we were to use STSADM export.
  • 没有从源Central Admin到目标Central Admin的直接HTTP访问 -这是在Central Admin中使用Content Deployment功能(路径和作业)的先决条件,但是我们需要的是可以复制到实时服务器中的文件。内容迁移API提供了此功能,还为大量数据提供了压缩选项。
  • 自动 包含数据库 dependencies - 与STSADM导出(但不包括功能)一样,SharePoint将分析并收集所有依赖项,例如字段,内容类型,母版页等。 us.

该API使用起来相当简单,您可能已经看到 斯特凡的系列精彩文章 就此主题而言 - these serve as 一个很好的伴侣 MSDN文档.

重要的是要记住,任何非数据库资产 (例如用户控件,程序集等)需要手动部署到目标环境-使用STSADM导出或 内容迁移API。就我们而言, 现场环境是一个单一的 server (and 版本控制将由我们的主要源代码控制系统处理),这些由XCOPY部署,因为 deployment using 解决方案包 在这里没有提供任何引人注目的优势。 

在讨论文件系统文件时,请务必注意,在执行(例如)STSADM之后,如果在目标计算机上看到404错误, 导入,很可能您忘记了部署用户控件之类的东西。 404实际上来自引用的文件而不是实际的页面,因此请不要假定导入有问题 - a 检查“查看所有网站内容”,导入日志可能会确认所有网站页面均存在!

希望这为您可能没有考虑的方法提供了一些思考的方法。我想我的主要意思是,尽管STSADM导出非常简单,但由于GUID更改,它可能无法完全解决所有部署难题。在接下来的文章中,我将提供更直接的部署策略比较(扩展“功能或内容部署”文章),并分享我的微型应用程序,它为内容迁移API提供了前端。

[P.S. Sincere apologies to people who left 评论 whilst I was on holiday which 是 still not published - I'll publish these 和 respond over the next few days.

C。]