回顾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”工具。我们知道此重构是意义重大的,但请相信,我们有足够的测试计划。然而,回顾过去,很明显我们没有做到。我们正在总结对所有已报告的问题的修复,并在下周左右,所有的修复程序应该都是可用的。

我们还没有完成我们的回顾/后期练习,但几个经验教训正变得清晰:

  1. 我们要找出一个方法,以便能够进行重大的重构,同时又不损害on premises更新等。我们现在仍在思考通过什么战略 — — 分支?选择性的部署?不同的调度模型?其他的东西?
  2. 对于一台on premises服务器,配置的数量是庞大的,我们必须绝对获得一定量的预发行版的客户测试。我们并没有此版本。我们的"CTP"都没有"投入到产品中",并没有最终版本的升级路径。
  3. 我们当然找到了一些方法,改进我们的测试矩阵来捕捉更多的问题。
  4. 我们真的只有约 3 周的"结束游戏"— — 最后的bug修复和在QU1 中验证。

不要从此篇文章中得出结论:Update 1 充满了问题 — —不是这样的。相对较少的人会遇到问题。我们已经自己成功使用它几个月了。然而,我们可以做得更好。我对我们做的方式并不满意,我们将从中学习。我的目标并不是在一个Update之后做任何大致可用的"修补程序"。这一次我们不得不做Update 2。

我分享此,因为我很乐意分享好的和坏的事情。我将告诉你我感到自豪的事情,我也将告诉你我感到不自豪的事情。而且,一路走来,如果找到任何对你有价值的东西和帮助你找出如何构建更好的软件,我会很高兴。

Brian


Skip to main content