更新SharePoint 2010生产站点的最佳做法

我有一个安装了SP 2010和SQL Server 2008的VM（#1）。它在负载和容量方面符合我们的需要。如果出现故障，我们可以将其恢复到快照

发展进程仍在继续。 问题是什么是更新生产虚拟机的好方法

变体1:

拥有生产虚拟机的副本（#2）

当迭代完成（开发->测试->修复）并准备进行更新时，我们交换虚拟机（#1#2）

测试VM#2变成生产，而#1变成测试

“+”：我们使用经过全面测试的解决方案

“-”：需要虚拟机之间的同步机制

变体2:

开发、测试并修复生产虚拟机

准备好后发布更改

“+”：我们不需要虚拟机之间的同步机制

“-”：崩溃可能会更频繁地发生

如有任何建议，将不胜感激

---

TIA

不要在生产虚拟机上进行开发。SharePoint在开发过程中很容易被破坏，您很可能会在某个时候破坏您的生产环境。风险基本上太高了

在单独的系统上进行开发。将您的解决方案/更改正确打包为WSP—在另一个系统上测试它（在开发环境和生产环境之间）。一旦通过了登台服务器上的所有测试，就将WSP部署到生产环境中

对于SharePoint来说，交换系统是一件很麻烦的事——您需要担心其他访问映射、IIS绑定等问题——而且需要花费更多的时间和精力，而不仅仅是上传一个新的WSP并点击“部署”（显然，在您的stating server上测试之后）。

这实际上取决于您正在开发的“内容”：

仅内容

• 在生产机器上执行此操作通常更容易。标准发布框架应该足以对标准用户隐藏更改

• 或者，您可以使用sharepoint的内容部署功能将其从开发服务器场移动到生产服务器场

• 也可以使用内容部署工具

Web部件、简单组件

• 在2010年，这些应该作为沙盒解决方案来完成（如果你能侥幸逃脱的话），那么在你的prod环境中上传/更改它们是非常简单的。构建您的开发环境，然后通过sharepoint网页上载

复杂组件

• 需要服务器场管理员在服务器上安装的东西（作业、复杂的web部件等）应该在开发环境中使用visual studio进行开发，然后以经过充分测试的方式转移到prod。尝试拥有一个测试/舞台环境

上述所有因素的组合

• 这通常取决于您的客户愿意将自己暴露在多大的风险之下，例如，如果它是一台全新的服务器，那么关闭系统用户的风险就不大

---

我不建议在生产设备上安装visual studioSharePoint server

您绝对不应该在生产设备上安装VS。调试项目太容易了，这会停止其他用户的SharePoint访问。