将更改应用于SharePoint应用程序的最佳实践

Question

我觉得我需要一个更好定义的框架来更新我的SharePoint（MOSS 2007）应用程序并使用自定义代码更改。我正在创建具有功能和新类型等的wsp解决方案文件，但是一旦经过测试和部署，我觉得这是一种信念的飞跃，这让我感到紧张，偶尔也不愿意部署更改。部署之后，很难将SharePoint应用程序的当前状态与该SharePoint服务器上部署的特定代码相关联。实际安装了哪些功能以及哪些网站？哪些功能已激活或停用？这个自定义字段或内容类型的哪个版本真的存在？这样的事情。如果出现错误，我必须依赖于我对那些代码和实际运行代码的假设，或者我不得不花时间挖掘已部署的程序集和12个蜂巢 - 不是不可能，而是非常不愉快。

我应该采取哪些措施来提高我明确确定应用程序状态并找到真正代表该状态的代码的能力？是否有第三方工具可以帮助解决这个问题？

Answer 1

我感觉到你的痛苦...应用程序开发使用SharePoint 2007的生命周期让我感到苦涩。

回答你的问题。我们构建了自己的部署实用程序，为我们做了一些事情。

1. 检查关键计时器作业的状态（我们会进行多次部署以找到一个未部署的WFE）

2. 检查我们所有网络前端的关键服务状态（在我们开始启动计时器工作之前，我们想要了解服务器场的健康状况）。

3. 显示GAC中所选程序集的文件版本和日期（在所有Web前端执行此操作）。我们在集群未在整个服务器场中正确安装之前遇到过问题。

4. 根据我们提供的自定义XML方案更新web.config设置。我们遇到了web.config更新的一些问题，所以我们考虑创建一个实用程序来验证web.config（特别是确保没有特定键的重复条目）。

5. 推送内容类型更新（第一次通过功能部署内容类型，它运行良好，但只要您需要更新该内容类型就很难）。

6. 检查部署或升级后WSP包的状态。

此实用程序使用SharePoint API完成大部分工作。其中一些是通过检查WMI事件来完成的。

Answer 2

不幸的是，SharePoint开发经验在这方面缺乏。只要您使用解决方案包“部署”所有功能，您就可以使用中央管理员的解决方案管理来跟踪版本以及部署到哪个网站集的内容。

功能范围从场中的所有级别到单个Web;所以这个级别的维护有点困难。我只是尝试从（自上而下）解决方案级别组织所有部署的代码。

在部署自定义计时器作业，事件处理程序等时，它变得更加复杂;我真的希望下一个版本能解决许多这些常见的开发人员问题。

Answer 3

不是您拥有计划/受控部署流程和TFS

等版本管理系统的唯一方式

在我参与的当前项目中，我们有：

1. 持续构建
2. 每日在开发服务器上构建
3. 当我们发布要测试的东西时，我们将代码合并到版本管理系统（TFS）中的Main bransch
4. 经过测试并准备投入生产后，我们将主要的bransch合并到发布bransch

使用这种结构化方式，我们始终知道在什么环境中部署了什么，并且还可以根据环境或需求变化跟踪所有变更（也在TFS中跟踪）