• 2011-10-27

    探路持续交付

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/169752584.html

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

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

    构建

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

    软件开发地基

    在云端

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

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

    DevOps

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

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

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

    自动化测试

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

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

    部署流水线

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

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

    历史上的今天:

    Hello Velocity 2004-10-27
    引用地址: