将更改应用于SharePoint应用程序的最佳做法

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

---

我应该采取哪些步骤来提高明确确定应用程序状态并找到真正代表该状态的代码的能力？是否有第三方工具可以提供帮助？

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

功能范围从农场到单个web的所有级别；因此，从这个层面上进行维护有点困难。我只是尝试从（自上而下）解决方案级别组织所有部署的代码

---

在部署自定义计时器作业、事件处理程序等时，它变得更加复杂；我真的希望下一个版本能够解决很多开发者共同关心的问题。

我感觉到了你的痛苦。。。SharePoint 2007的应用程序开发生命周期让我苦不堪言

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

检查关键计时器作业的状态（我们进行部署的次数太多，无法找到未进行部署的WFE）

检查所有web前端上关键服务的状态（同样，在开始计时作业之前，我们想知道服务器场的运行状况）

显示GAC中选定程序集的文件版本和日期（在所有Web前端执行此操作）。我们以前也看到过一些问题，在这些问题中，程序集没有在整个服务器场中正确安装

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

推送内容类型更新（首次通过功能部署内容类型时，它工作得很好，但一旦需要更新该内容类型，它就会变得很困难）

在部署或升级后检查WSP包的状态

---

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

并不是拥有计划/控制部署过程和TFS等版本管理系统的唯一方法

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

连续构建

每日构建在开发服务器上

当我们发布要测试的内容时，我们将代码合并到版本管理系统（TFS）中的主bransch中

当测试并准备生产时，我们将主bransch合并到发布bransch

---

使用这种结构化的方式，我们总是知道在什么环境中部署了什么，并且还可以跟踪基于环境的所有更改或需求的更改（也在TFS中跟踪）

我还将把这与TFS源代码控制和工作项联系起来。当您部署某个东西时，请标记与部署相关联的变更集，并注意变更集实际对moss造成的影响（内容类型、功能、事件处理程序等）。对于这一点，我非常惊讶地将其忽略。TFS对于针对SharePoint开发的团队来说几乎是一个要求。哇，这听起来真的很酷。有机会释放到CodePlex吗？这将拯救很多痛苦！