我想花几天时间从演示中添加屏幕截图，但我’现在，我已经在SharePoint最佳实践会议上的演讲中发表了自己的看法。我花了很多时间在演讲中，尽管这次演讲的准备工作比其他人要难。’我完成后对结果感到满意。我认为这个主题开始受到更多关注，您知道那里’当您最终在演讲者房间中向不能’不参加演讲。演讲围绕构建平台的Team Foundation Server 2010进行。这里’演示之一的摘要：
- 开发人员签入（对我的演示中的数据访问层进行了重大更改）并触发了自动构建
- 程序集和WSP被构建（以发布模式）并部署到远程SharePoint服务器
- 部署完成后，将对应用程序池进行预热，我们开始使用自动UI测试（Visual Studio 2010 Premium及更高版本的功能）访问该网站。
- 如果测试失败，则说明构建失败，并且通知所有开发人员（通过TFS构建通知工具）
- 构建经理/开发人员检查构建报告并看到：
- UI测试失败的屏幕截图
- 当时事件日志中的关键条目
- >>生成经理/开发人员现在可以理解为什么最新的代码更改会破坏生成
- “Added value” bonus demo
- 相同的过程，但还捕获了以下数据：
- 代码分析（查看应优化代码的哪些位）
- IntelliTrace（在测试过程中遇到异常时启动调试会话）
- UI测试的视频记录（不仅仅是屏幕截图）
当然，这个想法是，如果每24小时（或者一天中生成的信息可能更频繁地）出现一次此信息，则它’在编写代码时很容易快速发现问题。由于可以更快地排除错误和其他问题，因此可以增加成功的机会，从而降低了修复成本。
Download/view the 滑台
未来
在这次演讲中，我得到了很多积极的反馈，这使我确信可以撰写有关此主题的博客系列。虽然我知道有些人会立即认为这与他们无关，但我认为 具有某些自定义代码（例如上述3个Visual Studio项目）并且具有Team Foundation Server的任何SharePoint 2010项目至少应执行“first level”构建自动化（构建程序集和WSP） –构建本身需要花费几分钟的时间来配置（尽管构建服务器是前提条件），并且可以带来很多好处。
而且看起来像我’将与Microsoft合作（ 柯克·埃文斯（Kirk Evans） 特别是在有关该主题的MSDN白皮书上）。这将是我计划在博客系列中概述的许多原理/技术的较正式的处理方式，并有望成为那些希望实现自动化构建的人的宝贵资源。
