5

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

但微软在创建 SharePoint 时似乎并没有想到这个想法……至少,我无法在定义的基础架构中找到实现这一点的方法。

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

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

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

提前致谢,


感谢您的快速答复。

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

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

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

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

你有什么意见或建议吗?


谢谢大家的建议。

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

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

你们中的任何人都知道是否有办法在初始部署后更新内容类型?...当用户已经根据我们已经部署的内容类型创建了项目时?

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

4

5 回答 5

5

最好的方法是开发功能。完成这些功能后,您可以使用解决方案包(称为 WSP)部署它们。

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

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

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

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

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

于 2008-10-23T16:36:42.600 回答
2

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

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

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

对于面向公众的站点,您将需要使用内容部署

我再怎么强调都不过分,在继续发布产品之前,请确保您拥有内容类型的功能。

正如这里提到的,Chris O'Brian有一篇文章说除非必要,否则不应使用功能。他的原因之一是它减缓了发展。

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

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

与其拥有一个一切都一致的漂亮干净的网站,您最终会遇到一些小错误,并且网站的某些区域由于旧的开发问题而与其他区域的行为不同。

于 2008-10-23T20:27:59.543 回答
1

我建议看一下 Chris O'Briens 最近的帖子,以及他出色的内容部署向导:不仅仅是功能!

于 2008-10-23T19:53:30.970 回答
1

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

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

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

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

Microsoft Office SharePoint Server 2007 中基于团队的开发

于 2008-10-23T20:20:10.463 回答
0

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

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

于 2008-11-06T18:14:36.253 回答