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

Question

我觉得我需要一个更好的框架来更新我的SharePoint（MOSS 2007）应用程序和自定义代码更改。我正在创建包含功能和新类型等的wsp解决方案文件，但一旦这些文件被测试和部署，我感到有点不放心，这让我有时候不愿意部署更改。部署后，很难将当前状态与在SharePoint服务器上部署的特定代码相对应。哪些功能实际上已安装在哪些站点上？哪些功能已启用或停用？这个自定义字段或内容类型的哪个版本真正存在？诸如此类的问题。如果出现错误，我必须依赖我对哪些代码存在并实际运行的假设，或者我必须花时间挖掘已部署的程序集和12个hive--虽然不是不可能，但相当令人不愉快。

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

- Chris Farmer

Answer 1

我理解你的痛苦... 在SharePoint 2007上进行应用程序开发生命周期让我感到非常不愉快。

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

1. 检查关键计时器作业的状态（因为有很多次我们会进行部署，但会发现一个WFE没有得到部署）

2. 检查所有Web前端的关键服务状态（再次强调，在启动计时器作业之前，我们想知道农场的健康状况）。

3. 显示来自GAC所选程序集的文件版本和日期（在所有Web前端上执行此操作）。我们以前遇到过一些问题，其中程序集未能正确安装在整个农场中。

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

5. 推送内容类型更新（第一次通过功能部署内容类型非常好，但是一旦需要更新该内容类型，就会变得困难）。

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

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

- Jeff

---

哇，听起来真的很棒。有没有可能发布到 CodePlex 上？这将节省大量 SharePoint 的痛苦！ - Alex Angas

Answer 2

不幸的是，SharePoint开发经验在这方面缺乏。只要您使用解决方案包部署所有功能时进行“命名空间”，则可以使用中央管理中的解决方案管理来跟踪版本以及部署到哪个站点集合。

功能从整个农场到单个Web的所有级别进行范围设置；因此，从该级别进行维护有些困难。我只是尝试从（自上而下）解决方案级别组织所有已部署的代码。

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

- Jason Watts

---

我也会将其与TFS源控制和工作项相结合。当您部署某些内容时，请标记与部署相关的更改集以及更改集实际引起的moss影响的一些注释（内容类型、特征、事件处理程序等）。 - Marc

非常赞同，很惊讶我没提到它。对于开发SharePoint的团队来说，TFS几乎是必需的。 - Jason Watts

Answer 3

难道你没有计划/控制部署流程和像TFS这样的版本管理系统，是唯一的方法吗？

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

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

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

- salgo60