回顾TFS 2012 Update 1
[原文发表地址] Retrospective on TFS 2012 Update 1
[原文发表时间] 2013-01-02 10:12
在 11 月下旬，我前往欧洲的几个城市，针对 VS/TFS 2012 和应用程序生命周期管理发表了演讲。其中，我多次谈到的是有关如何管理我们的新发布节奏。我们每3 周推出一个服务，每 3 个月推出一个新on premises服务器/客户端。我谈到了我们如何计划发布版本，如何管理日程安排、 质量等。在其中的某个会谈上，有人问我像这样的事情，"新的发布进程运行得如何?"我回答，“在一年左右之后再问我，我会告诉你答案的。”这是有点带幽默的回应，但同时— — 证据正在酝酿中。开发/发布过程同结果一样好 — —你只有在看到几个发布版本和优秀的追踪记录之后才能判断。
当我谈论软件开发管理做法时，我一直强调的要点之一是最重要的事情是不断地学习。尝试新的东西、 衡量影响、 学习，为问题设计解决方案。Update 1已推出有一个月了，我们现在有一些针对我们进程的早期数据，正在学习阶段。
我们正在尝试做的事情是非常激进的。每3 周推出一个服务是具有挑战性的。但每个服务有许多优点— —没有重大的配置矩阵 ；只有一个，修补它很容易 ；最严重的产品问题在 24 小时内修补好， 诊断更简单，因为我们运行系统，可以分析失败，等等。
最重要的是，采取相同的代码库，然后在3 个月内推出on premises是超级富有挑战性的。
虽然，我一般都很满意我们的在线服务的质量结果，我现在可以说，30 天之后，我对on premises TFS Update的质量不满意。所幸的是 VS Update 1 似乎进展顺利 — —没有报告重大的问题，但我们已经知道了几个TFS Update 1 的问题。
我在我们发布update 1之后，很快就我们发现的首个问题发表了一篇博文。原因是，如果任何请求被发送到服务器，但升级仍在进展中时 （这可能会发生，如果您针对服务器配置一台生成计算机） ，争用条件会导致一个内部组件进入无效状态。虽然不是一个严重的问题，但在那几天里造成了很大的不便，我们发布了一个刷新过的Update 1 下载来修复该问题。
在随后几天和几周里，我们了解到了客户遇到的其他问题。最严重的那个（影响最严重）记载在这篇文章中了。其根本原因实际上与客户报告的那几个问题的根本原因是一样的。在TFS 2012 和Update 1之间，我们重构了一些核心的 TFS 服务，像身份管理 (Active Directory 同步等)。这样做是因为我们正在让核心的服务框架在 TFS 中针对其他服务是可用的，而这些服务就是那些我们正在Developer Division中构建的 — — 例如，Jason在 7 月宣布的“Napa”工具。我们知道此重构是意义重大的，但请相信，我们有足够的测试计划。然而，回顾过去，很明显我们没有做到。我们正在总结对所有已报告的问题的修复，并在下周左右，所有的修复程序应该都是可用的。
我们还没有完成我们的回顾/后期练习，但几个经验教训正变得清晰：
- 我们要找出一个方法，以便能够进行重大的重构，同时又不损害on premises更新等。我们现在仍在思考通过什么战略 — — 分支？选择性的部署？不同的调度模型？其他的东西？
- 对于一台on premises服务器，配置的数量是庞大的，我们必须绝对获得一定量的预发行版的客户测试。我们并没有此版本。我们的"CTP"都没有"投入到产品中"，并没有最终版本的升级路径。
- 我们当然找到了一些方法，改进我们的测试矩阵来捕捉更多的问题。
- 我们真的只有约 3 周的"结束游戏"— — 最后的bug修复和在QU1 中验证。
不要从此篇文章中得出结论：Update 1 充满了问题 — —不是这样的。相对较少的人会遇到问题。我们已经自己成功使用它几个月了。然而，我们可以做得更好。我对我们做的方式并不满意，我们将从中学习。我的目标并不是在一个Update之后做任何大致可用的"修补程序"。这一次我们不得不做Update 2。
我分享此，因为我很乐意分享好的和坏的事情。我将告诉你我感到自豪的事情，我也将告诉你我感到不自豪的事情。而且，一路走来，如果找到任何对你有价值的东西和帮助你找出如何构建更好的软件，我会很高兴。
Brian