• 2011-08-24

    迈向《Continuous Delivery》

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

    前不久,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评奖词中所写,这会是一本改变游戏规则的书。

    分享到:

    历史上的今天:

    引用地址: