[转载] TFS 云服务下的发布节奏 敏捷开发的周期
[原文发表地址] TFS Shipping Cadence
[原文发表时间] 2012-08-28 8:13
http://blogs.msdn.com/b/brian_harry/archive/2012/09/07/tfs-ship.aspx
我早就想写有关此的文章了，但不知何故，时光流逝，然而我一直没得空。
Team Foundation Service
如果你一直在阅读我的博客，那么这几个月以来你已经看到我的有关的服务更新的帖子。但还是让我退回去，然后从头开始。
约 2 年前，我们开始将TFS引入到云计算中。在最初，它只是一个尝试 — — 我们可以将TFS移植到 Azure中，并拥有一个可行的云托管解决方案吗？我们花了一个夏天来证明我们可以做到，然后在秋冬天充实它，并将它准备好做成产品。因此在一年前，我们决定认真对此事，并开始询问该产品的计划是什么样的。
显然我们的背景是作为一个on-premises任务的关键服务器团队 — — 我们10 年来一直在做它。进一步讲，我们是微软"机器"的一部分，它具有自己一套根深蒂固的做法。我们以 2-3 年的周期推出。如今拥有了强大的客户接洽、 良好的规划、 敏捷的发布机制 （如动力工具） 等，我相信我们已经有一个很好的 2-3 年周期，但它仍然 — —是 2-3 年的周期。我们知道进入云空间，它就不会这样运作了。
在云计算中，人们期望新鲜事物。他们期望进展。如果你的站点/应用程序最近没有什么进展，人们开始猜测它死了。我们需要重新思考我们要做些什么。这种想法起始于试图找出我们想要的东西。像人们经常做的，我们从我们所知道的东西开始，并试图从其中演变。我们花了几个月思考"如果我们每年做一次重大发布和每 6 个月做一次小型发布怎么样？"每6 个月做一次重大发布，每月做一次修补程序怎么样？"，"每季度做一次发布怎么样— — 我们的发布周期能有那么快吗？"等。我们花时间辩论重大发布和小型发布的构成。有多少改动是客户愿意容忍的？我们四处访问。最终我们得出结论：我们只是处理问题的方式错了。当一个大的变化是必要时 — — 忘记你所在的位置，只是问问你想去的地方，然后问问如何去那里。
所以去年夏天，我们每 4-6 个月推出服务更新，我们说我们将每周做一次更新。此目标是每周推出新功能 （而不仅仅是 bug 的修复）。在某种程度上，这是一项声明。让我们看看我们可以走多快。一些人问为什么不是每天呢？— —当然其中有些服务可以做到这一点。最终，我觉得这对于我们的产品/用户基础/团队大小来说是不必要的。也许有一天会有理由这么做，但我觉得目前并不合适。为了避免在每周节奏里发布的功能是随机的，我们决定以6个月作为规划线。我们计划了大约 6 个月分区，然后每周提供增量。
去年秋天，我们开始致力于此（以后我将写更多有关这种努力的文章），并逐步从 4-6 个月更新中提高了频率。团队正在执行一个基于 Scrum 的进程，使用3周为单位的sprint。当我们的发布周期越来越短时，我们意识到这些 3 周的sprints实际上形成了团队的自然节奏。我们计划sprint、 我们构建它、 我们交付一个"潜在可推出的增量"— — 除了在这种情况下，它不是"潜在的"；现在它真的是"可推出的"。由于这种天然的划分方式，我们决定将周期调整停在 3 个星期，然后每 3 个星期推出服务功能更新，而不是每星期。我们知道我们仍需要方法来更新服务以此更频繁地解决高优先级的问题，所以我们制定了一项"星期一修补程序"计划，就是说任意给定的星期一，如果需要的话，我们可以推出重要的但非紧急的服务修补程序。我们还可以在任意给定的一天推出紧急修复程序 – 可以说是在发现问题的几小时内。
最后一部分是意识到 6 个月的规划不够现实来确保团队真的清楚我们的目标，所以我们添加了一个12-18 个月"愿景"以确保我们都在朝同一方向前进。
所以我们的节奏是：
12-18 个月愿景— — 这是相当高的层次，它描述了我们想要实现的一系列场景。这通常包括一些可以演示价值所在的图板但不是设计或功能列表 — — 它只是我们想要创造的体验种类的说明。
6 个月规划— — 此窗口中，我们更清晰了解我们正在构建的功能。在这里我们做了一个跨团队的高层次的约定— — 我们的工作经常需要跨多个团队协调。这仍然不是设计，而是在有关我们提供的方案和所支持的功能方面达成一致。
3 周sprints— — 我们通常制作一个sprint安排来为每个功能团队找出2-3 个sprint。它有更多“sprint”的详细信息，而有关接下来的几个sprint的信息相比较少，但它明确告诉了我们接下来的事情和时间，这允许下一级的依赖项规划，并让我们了解我们对方案正在所作的进展，平衡我们所需要的工作。在每一个sprint末 — — 我们将部署到产品中。我们所部署的一些东西可能会"隐藏"在功能标志的背后。这让我们能够在工作过程中部署，并在适当的情况下，将其公开到有限的用户组来测试/给予反馈。
星期一修补程序— — 每个星期一我们部署重要但非紧急的服务修补程序。所有团队都知道如果他们有什么事情需要跟进，每个周一将会有一个窗口提醒。如果没有什么需要的话，我们不会部署，大部分时间我们不需要。
日常的修补程序— — 在任意给定的一天，如果我们有任何紧急的服务问题，我们将会给该服务打修复补丁。在实践中，这约每 6 周 发生一次（每两个sprint一次)。它通常都是由于部署sprint末的服务更新引起的功能回退，但有时也是新的服务更新引入的新问题
我期望随着我们继续学习和成熟，这可能会进一步发展。也许有一天我们会打破规划的sprint模型，然后转到每周部署。但现在，这对于我们运作良好，似乎对于TFSPreview 使用者也运作良好，所以我们会继续做下去。
团队资源管理器客户端
一旦我们开始着手相当快节奏的服务更新，我们意识到我们将会有另一个问题。一些新的服务功能需要更新客户端，从而以适用于开发人员的方式真正公开它们。这意味着，计划3 周为单位的服务和以2 年为单位（或甚至 1 年，如果你算上中间的服务包）的客户端将不能运作。因此，去年秋天，随着敲定了服务的节奏，我们开始去发现可以对客户端做些什么。
我们很快就意识到 Visual Studio 客户端每隔 3 周做出重大变化，是不太可能的。大多数客户不想经常更新他们的客户端。对于on-premises版本的质量保证模式必须比云服务更严格，因为一旦它部署之后，解决问题更加困难了。于是我们开始查看一个模型，其中包括几个约束：
- 经常推出以此不让服务演变回来。
- 提供比之前更好的载体来提供响应的创新和基于客户的反馈而改进。
- 确保on-premises更新的质量是高等的。
- 将更新以方便找到的合理方式推出，对客户使用影响最小，以及拥有合理的获取体验。
- 假设不是每个人都会每次更新，因此它需要很容易地跳过更新，然后接收新的。
我们最终将季度更新做为频繁的更新费用和滞后的服务之间的合理折衷。但是，很显然若要实现此目的，我们就需要考虑到我们在这些季度更新中作出什么改变。3个月的时间不足够来为任意改动集合运行一个完整的验证测试。为此我们不得不主要着重于对"堆栈中更高"的变化来尽量减少潜在的破坏稳定的影响。若要使用一个荒谬例子，每 3 个月为.NET Framework作出重大功能的更改，并部署到世界中，鉴于我们当前的能力，这将是一个非常糟糕的主意。
我们引进了 VS 2010 中的一个Visual Studio 扩展和更新功能。当我们查看 VS 提供更新的机制时，它看起来像一个有吸引力的机制。我们也考虑过 Microsoft Update和其他选项，但我们觉得 VS 更新机制是最具有吸引力的。不幸的是，在 2010 中，它不完全支持我们需要更新的组件的广度。幸运的是，自从去年秋天我们开始思考想法，我们齐心协力作出一个计划来扩展 VS 2012中的更新机制以支持我们所需要的东西。
因此，既然 VS 2012 已推出，这项计划是为我们的客户端移动到季度更新的节奏。这当然不会消除我们做更长时间"重大更新"的需要。所以继续期望重大的发布，但我很高兴能够定期提供持续的价值。
Team Foundation Service
一旦我们锁定了每 3 周服务更新和每季度客户端更新的计划, 一个显而易见的问题就是有关我们的on-premises TFS 服务器。很明显大量的客户将继续想要使用on-premises解决方案 — — 你可能会说这就是我们的本职工作。我们也有一些很好的托管合作伙伴，当我们Team Foundation Service不能解决，那些人想要提供最新的功能时，他们能满足需要。这些人会怎么想,等待2 年的功能，而在线服务在 3 周内就可以发布？事实上，它比这更糟糕。在我们发布TFS 2012的几个月前，我们不得不开始锁定变更，结果服务获得了新功能，而这些都不在 TFS 2012中， 甚至在推出TFS 2012＊ 前 ＊。
另一方面，真的不是每个人都想要每 3 个月更新其客户端，更是如此，不是每个人都想要每3 个月更新其服务器。此外，我们还没有一个像更新客户端那样清洁、 简单的服务器更新机制。关键服务器的 QA 过程要比客户端更多涉及并花费更多。
这一切合起来，我宁愿不尝试每 3 个月更新on-premises服务器。然而，当我们开始弄清楚如何将服务器任意节奏计划付诸实施时，我们发现它实际上很大程度上取决于我们正尝试推出的功能种类。最终，我们已经降落到了我们所说的地方，所以我们不打算对on-premises服务器作出固定的节奏。相反，我们就会"随机应变"。在这一点上，很显然，我们＊ 将 ＊需要在今年晚些时候的首个季度更新中更新on-premises服务器。一旦我们通过这些周期，我们将重新审视节奏问题，以及看看我们是否在更好的位置来锁定节奏，还是我们继续"随机应变。"
结论
这是一篇很长的博文，对此我感到抱歉，但是我想让你更好地了解旅程。总结是:
- Team Foundation Service每 3 周更新一次
- Visual Studio 客户端每季度更新一次
- Team Foundation Server比每 2 年更新更频繁，但仍正拟订有关细节。今年秋天我们将绝对推出一个，然后到时我们会看到它。
希望这会对你有所帮助 
Brian
