发布候选测试花费太长时间。
对于许多敏捷团队来说，这是一个最大的挑战。遗留应用程序启动的测试窗口时间长于sprint。这种情况在处理大型、集成网站和应用程序的客户和同事身上一再发生。
但是，如果在部署之前不需要人查看特定的、编号的构建来管理风险，那该怎么办呢?相反，如果abot告诉团队构建已经准备好，而所有人只需要单击deploy按钮，会怎么样呢?
实现这一目标需要一些基础设施和纪律。这对你来说可能不太可能，但是有些组织每天都在做这件事。
这正是Etsy.com的技术人员所做的，这家手工艺者在线商城2013年的销售额超过了10亿美元。2011年，Etsy有大约100名程序员。从那以后，它增长了不少。Etsy的新程序员在第一天就要经历一个过程来了解流程，包括做出更改、运行检查和生产部署。Etsy并不孤独;许多公司追求一种持续交付的模式。
消除回归测试的秘密
那些已经取消或至少大幅减少发布候选测试的公司有几个共同点:
测试工具。有许多工具可以运行软件，通过基本流程运行并寻找关键条件。这可以从单元测试或Web API测试一直到GUI的端到端测试。需要注意的一件事是:随着时间的推移，端到端测试往往会花费很长时间，以至于变得难以处理。选择正确的自动检查来实施是至关重要的;目标是要有足够的资金来减少风险、快速运行和减少维护负担，以保持检查的最新。
[相关:同行评审如何产生高质量的代码]
将工具挂钩到构建系统中。等待构建，然后在办公桌上手动运行检查，会增加流程的等待时间。让这在每个构建中自动发生，理想情况下是自动化的检出/构建/部署/测试/提升阶段管道。
从根本上减少回归误差。发现持续问题的持续集成将导致持续的修复和重新测试。为了让这些策略发挥作用，持续集成产生的代码需要后退——或者倒退——比行业标准要少得多。有了优秀的发布候选测试，它就不能了。安全网往往会导致糟糕的工作。请记住，消除发布候选测试意味着改进开发实践。
单独开发可部署的组件。这是真的:Etsy的程序员在第一天就投入生产。但是，他们编写的代码非常简单，只需将他们的名称和图像添加到关于我们>我们的队页。就是这样。这种变化不涉及数据库、web服务、样式表、任何代码库或生产代码;它仅限于一个常规的HTML文件和一个图像。程序员得到了具体的指示，所以最坏的情况是页面在几分钟内看起来是错误的。
通过组件，可以隔离每个更改。而不是一个单一的可执行文件，在Etsy的页面是在单独的文件。更改“push”一次只需要几个文件，不需要重新启动服务器。这在使部署(和回滚)更易于管理的同时减少了风险。
根据风险分开测试/部署策略。更新一个简单的网页是一回事，但那些需要信用卡、电子邮件和密码等个人信息的服务呢?每一种可能都需要不同的测试策略或过程。作为三年前报道的在美国，Zappos(亚马逊的一个分支)将受监管的代码与其他代码分开。影响受监管系统的变化要经过一个更严格的过程，但发布的频率更低，当然，还要进行更正式的检查。
持续监测生产。错误代码在生产中造成的损害是错误的严重程度乘以错误在生产中停留的时间。如果团队能够快速找到并修复缺陷，风险就会低得多。发现问题的一个关键是发现错误。对于Web应用程序，这包括500个错误、404个错误(不存在重定向)、崩溃和其他缺陷——所有这些都可以用工具绘制和可视化。
网页开发者/科学家Noah Sussman设计了Etsy的持续集成(CI)系统，他解释了Etsy的监控系统:
自动部署和回滚。监视产品以发现bug是很好的;通过敲击几下键盘或者一个基于web的应用程序来修复它，效果会更好。
(奖金)配置标志。在基于web的应用程序中，可以不使用补丁或手动回滚，而是关闭该特性。程序员所要做的就是将该特性包装在一个“if()”语句中，该语句绑定回一个代码库。将配置标志改为“Off”，新特性就消失了。苏斯曼的文章配置标志:一个爱情故事。
[相关:为什么敏捷技能比认证更有价值]
(奖金)增量推出。假设配置标志不是全局的，而是与用户绑定的。想要冒险的用户——雇员、他们的朋友/家人和已知的早期采用者——可以看到这个功能。免费和试用用户可以在配置标志翻转时看到该特性，等等。一般来说，更保守的用户，即使用软件来运行业务的用户，看到的是系统最稳定、测试良好的版本。在他们的书中我们在微软是如何测试软件的， Alan Page和他的合作作者将其称为“在生产中测试”。他们的团队没有使用配置标志，而是在不同的服务器上运行不同版本的应用程序，并根据用户类型将进程迁移到正确的服务器。
回归周期有多长
软件开发人员Abby Bangser描述了她最近参与的一个项目，该项目构建了持续部署的能力。出于业务原因，团队希望部署每个迭代，这是可以的。在迭代结束时，其中一位领导要求Bangser做一个“五分钟检查”，以确保一切正常。
她拒绝了。为什么?因为如果管理人员要求开发人员花5分钟去探索，那是因为他们对定义的系统没有足够的信心——不管是代码质量、工具、发现问题的能力，还是回滚的能力。邦塞想要那种自信。
为什么?为什么五分钟很重要?
因为这就是这些遗留应用程序如何以长达一个月的发布测试窗口结束的:它们开始时只有5分钟，然后一次增长5分钟。
再看一下cadence
拥有大型发布-候选测试流程的公司之所以这样做是有原因的，而且这个原因很可能包括公司仍然存在的原因。发布候选测试带来了成功。放弃它看起来很愚蠢。
在某些情况下，可能是这样。如果您关闭Web服务器，将整个登录系统与谷歌的用户id集成，或者进行任何其他彻底的更改，您可能需要几个月的时间来批处理这些工作，并将其隐藏在配置标志后面，甚至在发布之前进行一些候选测试。即使你是Etsy、Twitter、IMVU或其他媒体宠儿。
他们的关键是做正确数量的发布候选测试，以最聪明的方式交易时间风险。这可能意味着根据风险高低调整节奏。
问问自己这个棘手的问题:现在这个过程需要多长时间?你的节奏是什么?你是每两周减去五分钟还是增加五分钟?那你打算怎么办呢?
这个故事，“你是否过度测试了你的软件?首席信息官 。