探路持续交付

眼下的这个项目是一个有趣的项目，它让我收获极大的部分并不在于写代码本身，更多的是关于软件开发的“Last Mile”。

自动化，让团队从繁琐重复中解脱出来的一个重要途径，这是所有一切的基础。一句话，能自动化的尽量自动化。

构建

在给InfoQ写的一篇文章中，我已经尝试总结了一些通用的内容，这里不再赘述。

软件开发地基

在云端

之前参与过的一些项目，很大的一个挑战在于环境。我们没有足够的机器用来做出足够的环境。

这个项目使用了Amazon EC2。在我们需要一台机器的时候，我们会敲下一个命令，自动在云端创建出一个完整的测试环境。当测试完毕，同样是一条命令，这个机器就烟消云散了。这种做法让团队按需创建自己的环境。

DevOps

有了机器，机器的内容是由我们自己决定的。托DevOps运动的福，这一切变得容易起来。所谓infrastructure as code。

我们采用Chef将所有的配置管理起来。比如，当我们搭建一台机器的时候，需要一个应用服务器，也需要安装我们最新的版本，所有这一切都是由脚本管理的。我们只要一条命令敲下去，那台在云中搭建出的新机器上就自动包含了所有这一切。

小结一下，云解决了机器问题，DevOps解决了配置问题。

自动化测试

自动化测试是所有一切验证的基础。相比于之前的项目，这个项目的一大进步在于验收测试。我们采用Cucumber做为我们的验收测试描述工具。比之于TDD，在验收测试的层面上，我们做的是BDD。

这更进一步的是，我们会从0开始搭建整个测试环境，然后，运行测试。基于前面的描述，这种测试会运行在云中。

部署流水线

有了上面的基础，我们构建了一条“部署流水线”。下面简单描述一下我们的“流水线”：

• 完成一个修改时，开发人员会在本地运行提交脚本。这个脚本会运行诸如编译、测试、质量检查等方面的东西。通过之后，才可以真正的提交。
• CI软件检测到新代码提交之后，就会启动“部署流水线”。首先是在提交阶段验证，内容与开发人员本地验证的内容相仿。
• 通过提交验证之后，进入到下一阶段，在云环境中创建出一个部署了最新软件的服务器，基于这个环境进行端到端的测试。
• 端到端测试之后，将软件发布到一个中央仓库里，这就是一个发布候选版本了。如果有需要，我们可以取出这个版本进行更多的探索测试和性能测试等。
• 负责运营的人，根据需要，发布适当的版本上线。