实践中的持续部署

持续部署，Ash Maurya 称之为：“在一天内多次完成发布同一款软件的过程，相比以前几天、几周乃至几个月的时间，现在可能几分钟就完成一次部署。”最近, 在以精益为主的“消除在制品”活动中，持续部署成为热门话题。然而，虽然很多人可能会发现这是个吸引人的目标，而且从道理上讲也很值得去做，但能想明白该怎么做的人却没有多少。 Ash Maurya 用自己公司的实施经验帮助填补了这个空白。

以前，发布过程至少要用半天，甚至有时候是一整天。如果一周要用 20% 的时间来发布软件，对于小团队实在是太浪费时间了。发现重要的新问题时，还要不断改变发布特性的优先级，为此所做的协调占用的时间还没有计算在内。

他开始转而采取 Eric Reis 的

5 步持续部署入门建议 ，这帮助他理顺了自己的工具。从那时起，他开始挑战最有难度的事情——“学着适应随时可以发布软件”，这也成了他接下来讲述的焦点。

先做简单的事情 - 进行小的变更，然后疯狂审核发布流程。我开始严重依赖功能测试，而且超过了对单元测试的依赖，这让我能像用户那样测试应用中的变化。我还发现了一组事件，它们的出现表示可能发生了特别不对劲的问题（比如，系统中没有用户），并且依此（使用 nagios/ganglia）建立了一个实时报警系统。 我们慢慢建立了自信，并逐渐提交范围更大的多部分变更，每次提交也让我们的测试套件和监控脚本变得更为完善。经过一系列的迭代，相比过去的阶段性发布，我们的恐惧感实际上也降低了很多。因为每次发布提交的代码量变少了，我们就能够放心地把互相关联的问题解决方案放在一起进行发布。

Maurya 使用下面的原则和实践来描述他的持续部署过程：

• “别去推功能” 这是基本的精益箴言。 让客户向你的 MVP 提供反馈，以此来“拉动” 新的功能。
• “少量编码”对于 Maurya 而言，两个小时的编码结束后，就要签入代码了，并由此导致自动构建 。
• “尽量采用功能测试而不是单元测试”Muarya 使用了 Selenium(基于 web 的自动功能测试工具，由 ThoughtWorks 开发) 。
• ****“必须测试用户激活流程”**** 绝对要保证让用户“初步满足的关键路径”是起作用的。
• “使用自动软件更新”应该尽可能保证用户在不受影响的情况下收到更新。Maurya 详细描述了他是如何为基于 OSGI 的应用做到这一点的。
• “集成警告和监控”使用 nagios 和 ganglia， Maurya 可以获得任何系统使用异常的缺陷通知。
• “集成应用程序级别的诊断”一个应用程序能够通过自检来发现问题，而且这些问题是用户和测试可能无法发现的。
• “未预期的错误只能允许发生一次”花点时间来理解真正的原因并彻底根除它。