【翻译】持续部署

原文: http://timothyfitz.com/2009/02/08/continuous-deployment/

Alex 已经重构了一些网站后端的代码。当提交这个小任务的代码后，Alex 继续开发下一个特性。

当代码部署到生产环境两周以后，这段代码让整个网站宕机。自动化测试没有测试到一个字符导致的拼写错误，连锁故障让人想起了 Twitter 刚刚发布的时候。人们花了8个小时隔离问题，修复了这个错误的字符，并部署到生产环境，终于回复正常。

Alex 诅咒运气，指责人类的无懈可击，以及软件工程不可避免的成本，然后继续下一个任务。

这个故事每天都在我所知道的创业公司发生。这很糟糕。Alex 有一个她不知道的问题。她的软件开发实践是不可持续的。像这样“愚蠢的失误”会随着产品增长的越来越复杂、团队越来越大而变得更加频繁。Alex 需要切换到一个可以规模化的解决方案。

在我的到这个解决方案前，让我先告诉你一些常见的解决方案。当这些解决方案产生了真实的问题后，它们就不是能解决 Alex 境遇的解决方案。

更多的手动测试：这个明显不可能随着复杂性的提升而规模化。这么做也无法逐字的捕获每个问题，因为你的测试沙箱或者测试集群永远无法做到和生产环境一模一样。

更多前置的计划：前置计划就像烹饪菜谱中的条目。它无法准确的告诉你多少是多，多少是少。但是我将要告诉你要刚刚好——不要太多也不要太少，因为那些无疑会毁掉了食物或这产品。过度计划的自然趋势是专注于非现实问题。 现在你会犯更多愚蠢的错误，但它们将是针对那些无关紧要的需求设计的。

多的自动化测试：自动化测试很棒，更多的自动化测试更好。但无论多少自动化测试都无法确保在人类的天性下某个功能完全正常，因为没有任何自动化测试会像用户那样残酷、随机、恶意、无知或激进。

代码审查和结对编程是优秀的实践：这些实践将提升代码质量，防止缺陷并培养你的程序员。虽然这些实践可以在很大程度上减少缺陷，但最终他们受到以下事实的限制：虽然两个人比一个人好，但他们仍然是人。 这些实践只能捕获到你的组织作为一个整体已经有能力能够发现的故障。

降低发布频率：虽然这么做可以降低宕机时间（软件中断并回滚），但开发和返工时间会更大，失误仍然会继续出现。其自然的趋势会导致发布更加不频繁，直到你完全不发布。然后你会被强迫做一次完全的重写，这依然是末日。

那么 Alex 应该怎么办呢？ 持续部署！让每一次代码提交应当立即部署到生产环境。让我们重新看看 Alex 的故事，假设她已经可以使用理想的持续部署实践。Alex 提交代码。几分钟后她集群健康状态异常。故障很容易追溯到并会滚 Alex 的变更。Alex 花了最少的时间调试，找到它的拼写错误很容易。她的变更仍然导致了级联的故障，但是宕机时间已经最小了。

这是经典的快速失败模式在软件发布过程中的一个实现。你和引入故障变更越近，你就能获得更多的数据修复这个故障。在代码中快速失败意味着在输入无效的时候抛出一个异常而不是等待它在以后未知的地方出错。在一个软件发布的过程中快速失败意味着尽快发布未部署的代码，而不是等待一周后出现发布故障。

持续部署是简单的：只需要越来越频繁的发布你的代码。也许从今天开始替代每周或者每月的发布频率，但是随着时间的推移，你会达到理想的目标并且在过程中持续获得收益。

2009年2月8日

Timothy Fitz

（完）