2008年8月31日,星期日

开发人员的经验教训-金融领域的SharePoint WCM

所以在我最近 金融部门中的SharePoint WCM 帖子中,我谈到了我们构建的内容以及为什么我认为结果很有意思。我今天想做的是分享一些已学到的技术经验,并了解什么有效,哪些无效。正如我上次提到的那样,当该网站在 的SharePoint UK用户组,这意味着我们将回答您关心的任何问题,而不是我今天要讨论的一些开发人员问题。

现在要构建所有这些框架,重要的是要考虑这是什么类型的项目-术语对不同的人意味着略有不同的事情,但对我而言,重点是“开发”,而不是“实现”或“定制”。用代码术语,我们得出以下结果:

  • 总共17个Visual Studio项目
  • 4 Windows服务
  • 5个每晚批处理
  • 5个补充SQL表(SharePoint数据库外部)

8周的工作还不错。顺便说一句,尽管第一个数字似乎高得令人惊讶,但在与团队的技术交流中,没有人想到这 不是 正确的代码分解方式。这部分地由以下事实解释:该单个项目实际上是为客户执行的更大项目计划的一部分,还部分由Endeca搜索实施和我们所需的批处理流程的复杂性组成。

效果很好(无特定顺序)

  • 在开发人员中使用“开发农场” -这意味着内容数据库是共享的,因此一个开发人员无需费力即可查看其他人创建的列表,站点列,内容类型,母版页/布局等。这实际上是 只要 我可以在SharePoint中进行团队开发的一种方式,但值得一提的是,因为我知道并非所有SharePoint商店都以这种方式进行操作。
  • 正确使用跟踪- 这是在整个代码中编写日志语句的想法,以便在将代码部署到其他环境(例如QA / UAT /生产)后轻松诊断问题。我们使用标准的.Net System.Diagnostics跟踪框架 具有详细,信息,警告和错误的级别-我很早就熟悉了,但是一些开发人员是新手,并认为它非常宝贵。特别是,我们有很多库代码,当您无法在屏幕上直接看到某些结果时,通常很难找到逻辑错误。对我而言,跟踪实质上使您能够在几秒钟或几分钟内找到某些错误,否则可能要花费数小时才能解决。尽管添加跟踪代码会减慢编码速度,但为减轻这种情况,我们使用了..
  • 锐化器 - 在项目开始时,我创建了多个ReSharper模板来调用我们的通用代码,例如进行跟踪,并让所有团队下载ReSharper的试用版。这意味着我们只需几次按键即可添加跟踪语句,这意味着“我没有时间添加跟踪!”借口不能用:-)
  • 我的 Config Store框架 基于SharePoint列表*- 我们存储了130多个“配置项”,从“真” /“假”配置开关(例如“强制用户首次登录时更改密码”)到已知URL,再到整个网站上显示的某些字符串。我们还发现了一些需要改进的地方(例如,字段不足以存储XML片段!)有望将其纳入下一个版本。
  • 为未处理的异常实现日志记录/通知- 我知道MS Enterprise Library是为此的一个组件,但是我们使用位于SharePoint SPRequest处理程序前面的HTTP处理程序开发了自己的组件。这意味着,只要代码中发生了意外的事情,我们就可以立即对其进行查找,并可以在电子邮件中看到堆栈跟踪和其他调试信息。当测试人员开始工作时,这是非常宝贵的,因为这意味着我们可以在甚至未报告错误之前就主动对其进行处理。一旦发现有新异常的邮件,我们就会大声喊叫到特定的测试人员(由用户ID标识)"What exactly did you 只是 做?"(这给他们留下了深刻的印象!),因此我们准确地确定了导致此错误的环境/数据集。  
  • 我的 内容部署向导 工具*- 我还曾在该项目中扮演过“部署/发布经理”的角色,所以我可能是从中受益最大的人,但是自从构建它以来,我实际上已经在我完成的每个项目中都使用了它。对于团队更新了x个页面布局,x个查找列表和x个Config Store项目的版本,该工具对于挑选出无价的工具 只是 更改的项目并将其部署到其他环境。特别是对于“配置存储”项目,这很有用,因为某些配置在环境之间有所不同(类似于web.config项),因此您不想覆盖整个列表。对于早期版本,当团队进行了许多复杂的“模式”更新(例如,对网站列/查找/内容类型进行了许多复杂的更改)时,由于我选择时间的压力,“一切都会以这种方式工作” '将网站集路由并放置到目标上,然后导入整个内容(因为没有要保留的宝贵数据),因此我仍然没有亲自测试过一些复杂的部署方案,但是在dev环境之上有3个环境部署到向导很容易挽救生命。
  • 的SharePoint解决方案的跨站点查找字段 - 这解决了查询列只能在当前Web中查询数据的问题。我们将其用于几个关键数据集,因此我们只能拥有一个副本和一个副本。该死的有用。
  • LINQ转SQL - 我们将其用于补充SQL表中的CRUD操作,并且使用它的人都同意,他们在编写ADO.Net代码的标准方法上节省了大量时间。

*希望包含这些内容不会成为无耻的自我宣传-我构建它们的根本原因是为了解决我在SharePoint开发项目中看到的重复出现的问题,并且这两个实用程序的确为我们提供了帮助。

项目挑战(无特定顺序)

  • Team Foundation Server怪异- 由于我们仍未确定的原因,我们发现只要开发人员编译解决方案,都会检出该Web项目(即最关键的VS项目!)的.csproj文件。启用多重检出功能后,这意味着几乎每个开发人员都始终将项目文件检出,无论他/她是否进行任何项目更改(例如添加新类)。这意味着我们的合并问题比平常多得多-不好玩。
  • 虚拟机问题- 有一阵子我们以为ReSharper是罪魁祸首,但是VS修补程序带来了更多的稳定性。直觉地说,至少有一些问题是与64位相关的(在这方面我们的开发环境与生产相匹配),因为问题通常是通过Visual Studio(记住是32位应用程序)表现出来的。频繁的VS崩溃,"尝试读取或写入受保护的内存"事件日志中的消息-太好了。
  • 无法尽快识别共享代码 -当团队高速工作时,通常会关注复杂的开发项目。我们每天举行站立会议(类似于Scrum),但我怀疑我们可能专注于 问题 而不是什么 原为 被成功开发。所以我们浪费了一些时间 重构 使事情恢复一致,这就是为什么我喜欢将这种方法视为“危险地 快速应用程序开发”(适用于那些记得该术语的人;-)
  • 在SSL上共享IP地址引起的问题- 在我们的几个环境中,我们尝试使用Adrian Spear记录的技术 在IIS 6.0下使用主机头在多个Sharepoint 2007 Web应用程序上设置SSL。我过去曾经成功使用过此方法,但这次却遇到了一些问题-尽管在我们的质量检查环境中工作正常,但在其他地方也有问题。在仔细分析了差异之后,我发现该技术将 只要 如果正在使用的SSL证书是通配符证书,或者在计算机名而不是站点URL上匹配,则可以正常工作。这对其他人可能是显而易见的,但对我而言却不是!

希望有人觉得这有用!

5条评论:

匿名 said...

谢谢克里斯,这里有一些很棒的技术/过程。顺便说一句,我同意您的发展农场方法。

您能否提供VS修补程序的KB号?我一直以为是Resharper遇到了同样的问题。

干杯,亚历克斯。

匿名 said...

有趣。我喜欢HTTP模块用于捕获异常和警报的想法。整齐!

我同意拥有一个开发场-但是它属于客户吗?我在这里竞选虚拟开发场,但我们似乎一直都为服务器提供过多的VM,而这取决于客户端的数量。但是,如果我们使用客户端的硬件,那将是不同的...

说到哪种-您使用哪种类型的虚拟机?我们拥有VMware,并且没有任何问题(无论如何,都是来自虚拟化!)

克里斯·奥'Brien说过...

@Alex,

我相信KB号码是 KB 947841.

现在可以使用的另一种替代方法(但是当我们遇到问题时则不能)可能是为VS2008安装SP1。

干杯,

克里斯。

克里斯·奥'Brien说过...

@安迪

开发人员场和QA(测试)环境就在我们这一边。除了生产之外,客户还具有UAT(用户接受测试)环境-这是我的经验中相当普遍的现象。

我们使用VMWare进行虚拟化是因为我们的开发服务器场是64位的(以匹配生产环境)。现在,即使在Windows 2008下,也可以使用MS技术来做到这一点。

HTH,

克里斯。

布莱恩·普里亚姆说过...

感谢您发布此信息,非常有帮助。