迈向《Continuous Delivery》

前不久，Perryn Fowler在西安办公室帮忙，闲暇时，他捧着本书在读，我问他什么书，《Continuous Delivery》。他说，你应该读一下。

最近，客户负责我们这个项目的人在我们的办公室里，他也经常在翻一本书，我很好奇，结果，《Continuous Delivery》。他说，你应该读一下。

今年的Jolt大奖发布了，获奖者是《Continuous Delivery》。

作为一个ThoughtWorker，这本书里描述的很多东西对我来说，并不算陌生，很多东西甚至是我做咨询的时候，讲给客户听，帮着客户做的。但还是有很多东西，超出了我对问题的认识，换句话说，比我以为的步子更大。

持续交付这个概念，即便是在ThoughtWorks内部来说，也是一个很新的领域。以前，我们更多谈到的是持续集成。通过一些项目实践，我们发现很多内容逐渐超出了持续集成的范围。

当build越来越复杂的时候，我们会考虑将build分解到不同的阶段，每个阶段的build承担不同的职责，提交阶段主要做单元测试和集成测试，在提交阶段成功之后，后面的阶段开始做验收测试。

原本build分阶段只是为了解决放在一起时间太长的问题，但一旦开始分阶段，我们就会思考，是不是在不同的阶段以不同的目的做一些事情。比如，经过验收阶段，我们就可以给QA提供一些做探索性测试的版本，再比如，我们是不是可以需要有一个专门做性能测试的阶段等等。于是，形成了一个所谓的build pipeline。

通过了build pipeline的发布包，基本上可以认为它是功能上可用的。我们需要能够把它更方便的方式将其发布到产品环境中。这就是所谓devops做的事情：把基础设施当做代码。仔细想一下就不难发现，只要能够把基础设施代码化，那也就可以反过来，用在build里面的。

如果有足够的环境，比如使用云，我们就可以一键式的把整个环境，包括各种软件和我们的发布包，一并发布到云上，这样配合我们的验收测试用例，就可以做真正的端到端的测试。

如果所有一切就绪，我们的工作模式就变成了，开发人员提交一段代码，如果可以顺利通过build pipeline，也就是经过了功能测试和部署测试，形成了一个候选的发布包。只要有人同意，随时随地就可以真正发布了。

我还没有读过《Continuous Delivery》，而上面提到的一切，正是我们在现在这个项目里努力做的事情。这是在从前想都不敢想的事情，而如今，我们正在实现它。

我真的需要读一下这本书，让自己对持续交付有一个更完整的认识。诚如Jolt评奖词中所写，这会是一本改变游戏规则的书。