所以，也许我有点老了，但是当我们过去创建网站时，我们会在开发服务器上开发网站，然后将页面和文件发布或推广到生产服务器。这似乎总是一个很好的方式，以便用户不会看到混乱的页面或（上帝禁止）一个倒下的服务器，因为我们中的一个搞砸了。
但是，当他们创建SharePoint时，微软似乎没有想到这个想法......至少，我无法在基础架构中找到一种方法来实现这一点。
有谁知道SharePoint开发是否有管理策略？我在网上看到，我们可以备份开发环境并恢复到生产服务器。这可能是第一次工作，但生产服务器的任何更新都无法做到这一点，而不会有生产服务器上的数据丢失的风险。我已经看到一些工具用于将列表内容，页面和文档从一个服务器迁移到另一个服务器 - 尽管如此，我还没有调查它们。
但是，我的另一个问题是自定义内容类型。似乎一旦列表使用内容类型，您就无法在不删除列表中的项目，取消内容类型关联以及重新关联内容类型的情况下更新它。不应该有某种方法来升级内容类型吗？
无论如何，如果你对这些当前的困境有任何建议，我很乐意听取你的意见。
提前致谢，
丹
感谢您的快速回复。
我们已经为我们的网站创建了多个功能，并且针对基础（内容类型，列等）的解决方案包捆绑功能，以及与品牌有关的功能的另一个解决方案（页面布局，母版页等）。 ）
但似乎这是一次性拍摄......基本上，它会让我们的服务器设置好吧？一旦人们开始使用生产环境，我们将在内容数据库中存在所有文档，页面，列表项，并且无法更新内容类型，列等内容。
您必须先停用和卸载功能才能安装和激活新功能，对吧？我在功能定义上看到了一个Version属性，但尽管我已经知道了，但它没有做任何事情。解决方案似乎可以通过增加版本号来升级，但它似乎不会修改内容类型和列等内容 - 特别是如果它们正在使用中。另外，我不确定解决方案的升级有多广泛。
对于这类事情，有很少的文档。似乎我正在阅读的所有内容都是如何最初设置SharePoint服务器......而不是长期管理它。
您有任何建议或意见吗？
谢谢大家的建议。
但我们已经在这个网站上工作了一年多了。我非常有信心，我们已经按照你们大多数人的建议进行了设置。我们已经有几个功能可以安装内容类型，列，母版页，页面布局和工作流等内容。大多数这些功能都包含在解决方案包中。我们将所有开发环境都设置为VPC服务器。
所以，我的初始部署几乎已经完成了。我真正希望了解的是如何升级内容类型和列以及其他内容。是否可以在使用后更改内容类型？因为根据我的初步测试，这似乎不可能。我不担心程序集，因为看起来它们交换得很好，但我更新内容类型的唯一方法是删除任何引用它们的项目（即我的页面库中的所有页面），删除内容类型，然后重新添加。
您是否知道在初始部署后是否有更新内容类型的方法？ ...当用户已根据我们已部署的内容类型创建了项目时？
（我的问题的另一部分实际上是将现有页面从开发服务器移到生产中，但我可以不用它。我主要担心的是内容类型。）
答案 0 :(得分：5)
最好的方法是开发功能。功能完成后，您可以使用解决方案包（称为WSP）部署它们。
唯一要做的就是重新激活这些功能。这样，您就可以逐步推出新功能，而无需在生产中完成所有工作。
WSPBuilder是一个帮助您构建WSP的应用程序。
为了实现所有这一切的自动化......祝你好运。涉及很多工作。
<强>更新 部署内容类型和列非常棘手。创建网站后，您无法再通过功能更新它们。您需要遍历代码并递归遍历所有站点并修改与名称匹配的特定内容类型。
我们已经尝试过并且通常不能通过功能来做到这一点。这需要经历我称之为“使用代码部署”的内容。
答案 1 :(得分：2)
您确实需要使用功能定义内容类型，因为每种内容类型都有一个设置GUID，并且将使用相同的名称存储在数据库中。这在通过网站运行CAML查询时变得很重要，如果你愿意的话，在创建内容类型时会有一些其他的小问题。
我更喜欢STSDev使用自定义内容类型推出解决方案。
有两种方法可以在服务器上编辑页面。您可以将页面库定义为具有主要版本和次要版本。这允许编辑者编辑页面和定义的发布者以发布它们。这在内部网站上很好，但不建议用于面向公众的网站。
对于面向公众的网站，您需要使用Content Deployment
我无法强调，在继续生产发布之前，请确保您拥有内容类型的功能。
如前所述，Chris O'Brian有一篇帖子说除非必要，否则不应使用功能。他的一个原因是它减缓了发展。
我不同意这一点。如果您不熟悉功能，则开发 会慢一些，但是一旦达到知识水平，它就不是主要因素。
请听取有关移动内容的备份和还原方法的信息。 如果你这样做，你可能在开发期间创建的内容类型，字段和网页中的所有内容（对我来说总是相当多）将被移动到您的生产站点。
而不是拥有一个干净整洁的网站，一切都是一致的，你最终会得到一些小错误，网站的某些区域与其他区域的行为不同仅仅是因为旧的开发过程。
答案 2 :(得分：1)
我建议看看Chris O'Briens最近的帖子，以及他出色的内容部署向导：it's not all about Features!
答案 3 :(得分：1)
Maxim的正确之处在于，大多数项目都应该通过包含在解决方案（WSP文件）中的功能进行部署。您的策略应该是确保您的解决方案和程序集分解为相关的功能。这也是有益的，因为特征可以在某些水平如网站和网状物上被隔离。更新任何内容更新时，应使用功能激活码，停用代码和功能装订。内容部署也很有意义。
一旦要记住的是，如果更新仅在代码中，则可以更新程序集，而无需重新激活该功能或撤消和重新部署解决方案。所需的只是要重置的应用程序池。
微软有几篇关于开发环境的文章，你可以向许多其他人推荐环境。我们在虚拟机上进行开发，并将大多数项目部署到虚拟集成服务器。一旦我们对它进行测试，我们就会将我们的解决方案部署到QA等等。我可以轻松收回功能和解决方案。一旦投入生产，就应该进行彻底的测试。
在SharePoint中开发有问题，不言而喻，但到目前为止我发现这些好处超过了问题。
Team-Based Development in Microsoft Office SharePoint Server 2007
答案 4 :(得分：0)
我们开发了一个自定义解决方案，可以更新网站集的内容类型和字段。在封面下，通过代码，SharePoint允许我们修改字段以及字段和站点/列表内容类型中的值。
为了将实际内容从QA转移到Prod，我们使用Echo