将更改应用到 SharePoint 应用程序的最佳实践
我觉得我需要一个更好定义的框架来通过自定义代码更改来更新我的 SharePoint (MOSS 2007) 应用程序。 我正在创建具有功能和新类型等的 wsp 解决方案文件，但是一旦这些文件经过测试和部署，我觉得这有点信仰的飞跃，这让我感到紧张，有时不愿意部署更改。 部署后，很难将 SharePoint 应用程序的当前状态与部署在该 SharePoint 服务器上的特定代码关联起来。 实际安装了哪些功能以及安装在哪些站点上？ 哪些功能被激活或停用？ 此自定义字段或内容类型的哪个版本确实存在？ 诸如此类的事情。 如果出现错误，我必须依赖于我对那里有哪些代码并且实际运行的代码的假设，或者我必须花时间挖掘已部署的程序集和 12 个配置单元 - 并非不可能，但非常不愉快。
我应该采取哪些步骤来提高明确确定应用程序状态并找到真正代表该状态的代码的能力？ 有没有第三方工具可以帮助解决这个问题？
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我感受到你的痛苦...SharePoint 2007 的应用程序开发生命周期让我感到苦涩。
来回答你的问题。 我们构建了自己的部署实用程序，可以为我们做一些事情。
检查关键计时器作业的状态（我们多次进行部署以查找未部署的 WFE）
检查所有 Web 前端上关键服务的状态（在开始启动计时器作业之前，我们再次希望了解服务器场的运行状况）。
显示 GAC 中选定程序集的文件版本和日期（在所有 Web 前端执行此操作）。 我们之前遇到过问题，即程序集未在场中正确安装。
根据我们提供的自定义 XML 方案更新 web.config 设置。 我们在 web.config 更新方面遇到了一些问题，因此我们考虑创建一个实用程序来验证 web.config（特别是确保特定键没有重复条目）。
推送内容类型更新（第一次通过功能部署内容类型时效果很好，但是一旦您需要更新该内容类型，它就会变得很困难）。
部署或升级后检查 WSP 包的状态。
该实用程序使用 SharePoint API 来完成大部分工作。 其中一些是通过检查 WMI 事件来完成的。
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
不幸的是SharePoint在这方面缺乏开发经验。 只要您对使用解决方案包部署的所有功能进行“命名空间”，您就可以使用中央管理中的解决方案管理来跟踪版本以及部署到哪个网站集的内容。
功能范围涵盖从农场到单个网络的各个级别； 所以这个级别的维护有点困难。 我只是尝试从（自上而下）解决方案级别组织所有已部署的代码。
当部署自定义计时器作业、事件处理程序等时，它会变得更加复杂； 我真的希望下一个版本能够解决许多开发人员常见的问题。
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
这不是拥有计划/控制的部署过程和像 TFS 这样的版本管理系统的唯一方法
在我参与的当前项目中，我们有：
使用这种结构化方式，我们始终知道什么部署在什么环境中，并且还可以基于以下内容跟踪所有更改环境或需求变化（也在TFS中跟踪）
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)