促进 MOSS '07 网站从开发到生产

Question

所以，也许我有点老派，但是当我们过去创建网站时，我们会在开发服务器上开发网站，然后将页面和文件发布或推广到生产服务器。这似乎一直是一个好方法，这样用户就不会看到混乱的页面或（上帝保佑）因为我们中的一个人搞砸了而停机的服务器。

但微软在创建 SharePoint 时似乎并没有考虑到这个想法……至少，我还没有找到在定义的基础架构中执行此操作的方法。

有人知道是否有针对 SharePoint 开发的管理策略吗？我在网上看到我们可以备份开发环境并恢复到生产服务器。这可能是第一次工作，但是对生产服务器的任何更新都无法做到这一点，而不会冒生产服务器上的数据丢失的风险。我已经看到了一些用于将列表内容、页面和文档从一台服务器迁移到另一台服务器的工具——尽管不可否认，我还没有研究过它们。

但是，我关心的另一个问题是自定义内容类型。似乎一旦列表使用了内容类型，您就无法在不从列表中删除项目、取消关联内容类型并重新关联内容类型的情况下对其进行更新。不应该有一些方法来升级内容类型吗？

无论如何，如果您对当前的这些困境有任何建议，我很乐意听取您的意见。

提前致谢，

丹

---

感谢您的快速回复。

我们已经为我们的网站创建了几个功能，一个解决方案包捆绑了针对基础（内容类型、列等）的功能，以及另一个与品牌相关的功能（页面布局、母版页等）的解决方案。 )

但这似乎是一次性的……基本上，它会设置我们的服务器，对吧？一旦人们开始使用生产环境，我们的内容数据库中就会有文档、页面、列表项，并且不可能更新内容类型、列等内容。

您必须先停用和卸载这些功能，然后才能安装和激活新功能，对吧？我在功能定义上看到了 Version 属性，但据我所知，这没有任何作用。解决方案似乎可以通过增加版本号来升级，但它似乎并没有修改内容类型和列之类的东西——尤其是在它们正在使用的情况下。另外，我不确定解决方案的升级范围有多大。

这类事情几乎没有什么珍贵的文档。似乎我正在阅读的所有内容都是如何在最初设置您的 SharePoint 服务器...而不是长期管理它。

您有什么意见或建议吗？

---

谢谢大家的建议。

但是我们已经在这个网站上工作了一年多。我非常有信心，我们已经按照你们大多数人的建议进行了设置。我们已经有几个功能可以安装内容类型、列、母版页、页面布局和工作流等内容。大多数这些功能都包含在解决方案包中。我们将所有开发环境都设置为 VPC 服务器。

所以，我已经基本完成了初始部署。我真正希望找出的是如何升级内容类型和列之类的东西以及未来的东西。内容类型在使用后是否可以更改？因为根据我的初步测试，这似乎是不可能的。我不担心这些程序集，因为看起来它们交换得很好，但是我更新内容类型的唯一方法是删除引用它们的任何项目（即我的页面库中的所有页面），删除内容类型，然后重新添加。

你们中有人知道在初始部署之后是否可以更新内容类型？ ...当用户已经根据我们已经部署的内容类型创建了项目？

（我的问题的另一部分实际上是将现有页面从开发服务器移动到生产服务器，但我可以不用它。我主要担心的是内容类型。）

Answer 1

最好的方法是开发功能。功能完成后，您可以使用解决方案包（称为 WSP）部署它们。

剩下要做的就是重新激活这些功能。这样一来，您就可以逐步推出新功能，而无需在生产环境中进行所有操作。

WSPBuilder 是一款可帮助您构建 WSP 的应用程序。

为了自动化所有这些......祝你好运。涉及很多工作。

更新： 部署内容类型和列很棘手。创建网站后，您将无法再通过功能对其进行更新。您需要遍历代码并递归遍历所有站点并修改与名称匹配的特定内容类型。

我们已经尝试过，但使用功能通常无法做到这一点。这需要经过我称之为“使用代码部署”的事情。

Answer 2

您确实需要使用功能来定义您的内容类型，因为这样每个内容类型都将具有一个设置的 GUID，并且将使用相同的名称存储在数据库中。在网站上运行 CAML 查询时，这一点变得很重要，如果您愿意的话，当内容类型被创建时，还有一些其他的小问题。

我更喜欢 STSDev 使用自定义内容类型推出解决方案。

有两种方法可以在服务器上编辑页面。您可以将页面库定义为具有主要和次要版本。这允许编辑者编辑页面和定义的发布者来发布它们。这在内部网站上很好，但不建议在面向公众的网站上使用。

对于面向公众的网站，您需要使用Content Deployment

我再怎么强调都不为过，在继续发布正式版之前，请确保您拥有内容类型的功能。

正如这里提到的，Chris O'Brian 有一个帖子说除非必要，否则您不应使用功能。他的原因之一是它会减慢开发速度。

我不同意这一点。如果您不熟悉功能，开发会比较慢，但是一旦达到一定的知识水平，这并不是主要因素。

请听他讲述移动内容的备份和恢复方法。 如果您这样做，您在开发过程中可能创建的内容类型、字段和网站中的所有混乱（对我来说总是相当多）将被转移到您的生产站点。

您最终会遇到一些小错误，并且站点的某些区域的行为与其他区域不同，这仅仅是因为旧的开发问题。

Answer 3

我建议查看 Chris O'Briens 最近的帖子，以及他出色的内容部署向导：it's not all about Features!

Answer 4

Maxim 是正确的，因为大多数项目应该通过包装在解决方案（WSP 文件）中的功能进行部署。您的策略应该是确保您的解决方案和程序集被分解为相关的功能。这也是有益的，因为可以在某些级别（例如站点和网站）上隔离功能。更新任何内容更新时应使用功能激活码、停用码和功能装订。内容部署也很有意义。

要记住的是，如果仅在代码中进行更新，则可以更新程序集，而无需重新激活功能或收回并重新部署解决方案。只需重置应用程序池即可。

Microsoft 有几篇关于开发环境的文章，您可以在 Google 上搜索许多其他推荐环境的文章。我们在虚拟机上进行开发，并将大多数项目部署到虚拟集成服务器。一旦我们对它进行烟雾测试，我们就会将我们的解决方案部署到 QA 等等。好处是功能和解决方案很容易收回。一旦投入生产，就应该对其进行彻底的测试。

在 SharePoint 中开发存在问题，这是不言而喻的，但到目前为止我发现好处超过了问题。

Team-Based Development in Microsoft Office SharePoint Server 2007

Answer 5

我们开发了一个自定义解决方案，可以更新网站集的内容类型和字段。在幕后，SharePoint 允许我们通过代码修改字段以及字段和站点/列表内容类型中的值。

为了将实际内容从 QA 转移到 Prod，我们使用 Echo