SharePoint开发/生产环境

Question

我在SharePoint中遇到的最大挑战之一是它不能很好地适应典型的项目环境，而这种环境至少包含开发和生产环境。我遇到的问题是内容和列表紧密耦合，如果不对生产环境执行内容冻结，就很难执行设计更改。例如，如果我有一个包含计算列的列表并希望添加一些新功能，我将不得不在生产服务器上执行内容冻结，从生产服务器创建列表模板（包括内容），将该列表还原到开发环境，进行我的更改，然后反转列表模板过程。对于页面以及SharePoint中的任何其他内容也是如此。似乎一旦部署了网站，最好直接在生产盒上工作，但由于显而易见的原因，这打破了大量的最佳实践。

您是否有其他SharePoint开发人员处理此限制？

Answer 1

SharePoint“开发”实际上有两个（更多？）级别。您拥有部署到服务器的代码，例如Web部件，内容类型，工作流操作等。这在部署和最佳实践方面相对较好。

然后你有了你的例子，这更像是对网站实例的定制。当我们必须在Portal的“站点目录”列表中自定义计算字段时，我们所做的就是尝试调整开发中的更改。然后编写要进行的自定义的详细说明，并让具有适当权限的单独人员使用这些说明在集成（登台）服务器上进行更改。然后让同一个人在生产中进行更改。

我不确定您的更改是否容易受到此方法的影响，但值得考虑。

然后我们有另一个使用SharePoint设计器进行大量自定义的网站，以及我们正在使用的网站。

Answer 2

您可以使用内容部署向导（http://www.codeplex.com/SPDeploymentWizard）快速迁移列表和库等内容。您还可以获取生产的备份/恢复副本，然后对其进行更改，然后在凌晨时间内进行内容冻结（希望没有人会关心），将所有已更改的数据从生产中导入到您的副本中，然后恢复生产副本。至少冻结可能会被推迟，只有在export-gt; import-＆gt;恢复过程的持续时间内才需要冻结。

在实践中，我只是手工更改生产。

Answer 3

使用FeatureActivation代码将更改部署到列表的字段。代码更新字段后，您将停用该功能并将其删除。这样可以在QA环境中对结果进行测试。