代码之家 › 专栏 › 技术社区 › Chris Farmer Marcelo Cantos

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

configuration-management deployment sharepoint

3

Chris Farmer Marcelo Cantos · 技术社区 · 16 年前

我觉得我需要一个更好的定义框架来用自定义代码更改更新我的SharePoint(Moss 2007)应用程序。我正在创建具有特性和新类型等的WSP解决方案文件,但一旦这些文件得到测试和部署,我觉得这是一种信仰的飞跃,这让我紧张,有时不愿意部署更改。部署之后,很难将SharePoint应用程序的当前状态与部署在该SharePoint服务器上的特定代码相关联。实际安装了哪些功能以及在哪些站点上安装了哪些功能?哪些功能被激活或停用?此自定义域或内容类型的哪个版本是真正存在的?像这样的事情。如果一个错误突然出现,我必须依赖于我对代码存在和实际运行的假设,或者我必须花时间挖掘已部署的程序集和12个蜂巢——这不是不可能的,但相当令人不快。

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

3 回复 | 直到 16 年前

1

7

Chris Farmer Marcelo Cantos 16 年前

我感觉到你的痛苦…使用SharePoint2007的应用程序开发生命周期让我苦不堪言。

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

检查关键计时器作业的状态(我们执行部署的次数太多,无法找到一个未获得部署的WFE)
检查我们所有网络前端的关键服务的状态(同样,我们希望在开始计时作业之前了解农场的健康状况)。
显示从GAC选择的程序集的文件版本和日期(在所有Web前端执行此操作)。我们以前看到过这样的问题:在农场中没有正确安装程序集。
根据我们提供的自定义XML方案更新web.config设置。我们在web.config更新中遇到了一些问题,因此我们考虑创建一个实用程序来验证web.config(特别是确保没有针对特定键的重复条目)。
推送内容类型更新(第一次通过功能部署内容类型时,它工作得很好,但一旦需要更新该内容类型,它就会变得很困难)。
在部署或升级后检查wsp包的状态。

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

2

1

Jason Watts 16 年前

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

从服务器场到单个Web,所有级别的功能都有其作用域;因此从该级别进行维护有点困难。我只是尝试从(自上而下)解决方案级别组织所有已部署的代码。

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

3

0

salgo60 16 年前

不是只有这样,你才能有一个计划的/控制的部署过程和一个像TFS这样的版本管理系统

在我参与的当前项目中,我们有:

连续构建
每天在开发服务器上构建
当我们发布要测试的东西时,我们将代码合并到版本管理系统(TFS)中的主Bransch中。
当测试并准备生产时,我们将主膜与释放膜合并。

使用这种结构化的方法,我们总是知道在什么环境中部署了什么,并且还可以根据环境或需求的变化跟踪所有的更改(也可以在TFS中跟踪)