| 2010-04-09
正文
在科技圈的各种大会上，我们和很多人有过交谈，他们对我们在 IMVU 网站上的持续部署流程很感兴趣，想知道我们是如何每天部署50次代码的。我们也听到一些问题，关于我们是如何做到在不引入新缺陷和回归问题的情况下使用这种方法，以及我们是如何在这样快节奏的环境中保障质量的。
事实是我们有时候也会因为抢速度而对顾客造成一些负面影响，而这些特性也是我们学到教训的来源。有时候我们做出的特性对于顾客没有什么价值，有时候会在生产环境中引入一些回归问题或是新的缺陷。
但是同时，我们小心翼翼做出的特性客户也曾经并不感冒——而这实际上耗费更多，因为我们花了更多的时间来学习和改变方向。举一个例子，我们曾经用了一个月的开发时间忙活一个叫做“更新”的特性——有点像Facebook的“Friend feed”（朋友新鲜事），而用户使用这个特性的方法和我们预估的完全不同。我们花了很长的时间交付了一个没有人需要的功能，而结果就是这延后了一个更加重要特性的交付，那就是：群组。
问问用户他们想要什么，节省了内部产品开发讨论的时间，让很多问题的解决变得很简单。
“我们应该做一些工具让用户把阿凡达装备分类，还是直接做一个搜索工具，还是两个都做？”
我们会在已有客户数据、竞争分析以及综合经验的基础上做一个尽量好的决定——然后尽快地做出一个功能，用客户来验证我们是否正确。
我们还发现在这过程中的代价——主要是缺陷和不太精细但是好用的特性——是值得的，这是因为我们能从顾客那里尽快得到关于产品创意的第一手反馈。一旦从客户那里得到反馈，就可以确定我们关于产品的设想和决策是否正确，我们也就能够更快地改变路线或是在一个好创意上增加投入。
你觉得我们并不担心如何给客户提供高质量的特性，或是他们的用户体验会受到影响吗？我们担心得不得了。
首先，我们很重视自动测试。这种对于测试和其框架的重视是我们如何架构QA团队和其使用方法的核心。我们的前CTO，也是IMVU的联合创始人Eric Ries曾经详细地描述过我们用来支持持续部署的基础设施，这里概括一下，我们是这么做的：
每一行提交代码都用一个持续集成服务器（Buildbot）运行监控自动测试 为了确保出问题的时候不让新代码加入代码库需要运行一个源控制提交检查 为了保障万无一失，需要在部署软件到集群时加一个脚本。我们编写了一个集群免疫系统来监测和对严重的回归问题发出警告，当发生错误时，自动回滚到上一个好的版本 如果错误不小心加入到了部署过程中，实时监控和警报会在第一时间通知团队 根因分析（五个为什么）可以驱动部署和产品开发流程中的不断改善 这个框架和自动测试就意味着软件工程师必须为我们编写的每行代码都编写测试。我们并没有一个单独的角色来编写测试和研究基础设施——这个工作是由整个工程团队承担的，这是能保持QA团队精简的原因。但是用这样的方法也不能防止所有的回归问题和缺陷。有一些用户使用实例，而有一些实例过于边缘，复杂到无法使用自动化的测试。活生生的人还是比可以做多维、多层测试的机器要聪明。我们的QA工程师依靠他们的洞察力和经验在实战中发现潜在的问题，他们用客户可能使用的方法来使用并且测试特性。
QA工程师会用几乎一半的时间手动测试特性。一旦发现测试实例可以自动化，我们就会把它加入到测试覆盖范围（在Scrum流程中，其中的一个环节可以确保我们能够捕捉到了这类测试用例）。在Scrum流程中有一步要求工程师向另一个成员展示特性，——其实就是在有人在场的情况下，做一些基本的手动测试。因为我们需要构造的特性比QA工程师有时间测试的要多得多，这就使得团队必须要做一些权益取舍，回答这样的问题：“哪些特性值得QA花时间来做？”有时候这个问题不是那么容易回答的，也使得团队开始考虑是不是应该让其他成员，甚至是整个公司加入到更有组织更有规模的测试环节中来。当我们觉得这是行得通的时候，QA工程师就会组织这样的测试环节，帮助团队更快地发现和分类问题。
我们的QA工程师还有两个更重要的责任。第一个就是Scrum计划流程中的重要组成部分，编写测试计划并和产品所有者和技术带头人一起做评估。这能确保重要客户的用例没有被遗漏，而且保证工程团队知道特性将怎么测试。也就是说，QA工程师帮助整个团队认识到顾客会如何使用他们正在搭建的特性。
第二个责任就是大家众所周知的QA工程师在敏捷环境中的作用：他们在特性开发阶段就和软件工程师一起工作，同时尽量多地测试进程中的特性并和整个团队面对面地讨论这些特性。当功能最终应该“交由QA处理”的时候，它们实际上已经被测试过了，而且很多潜在的缺陷已经被发现和修补过了。
无论在发布前已经进行过多少次手动测试，我们最终还是会依靠自动化：基础设施允许我们完成控制条件下的转出，而我们的集群免疫系统对于回归问题的监测也减少了对顾客产生负面影响的风险。
最后，当特性呈现在顾客眼前的时候，我们会等待A/B分裂实验系统的实验结果，并倾听社区管理和客户服务团队的反馈。当反馈开始增加的时候——通常是马上，我们已经是准备好了的。我们已经特地为报告的缺陷和问题留出了快速反应的工程时间，也为让特性更加有趣的一些小变化做好了准备。
我们绝非完美：一直努力迅速向用户传递价值但是QA资源有限，也经常在生产过程中引入缺陷并且提交不完美的功能。但重要的是，我们能马上就知道用户想让我们做什么，然后一直迭代。