五步构建持续性部署(CD)

cd

错误被发现的时间越迟,修复的难度越高,代价也最昂贵。如果工程师在敲下代码的时候就发现了问题,那修复的成本几 乎为零。如果编译器捕获了bug,它对开放时间造成的影响就是以分钟计的。如果bug进入了产品,而且在一段时间内没有被发现,找到bug、修复bug的 代价就会让人觉得难以承受。千年虫问题就是一个典型的例子。
----题记 from http://www.infoq.com/news/2009/03/Continuous-Deployment

持续部署的目标是通过减少批量工作的大小,并加快团队工作的节奏,帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态, 让团队更容易去创新、试验,并达到可持续的生产率。

下面是来自Eric的五步构建快速部署的办法: 1.CI服务器。持续性部署的前提是持续性构建。我们需要一个地方去做单元测试、功能测试、集成测试和所有测试。这些事情会在每次commit之后进行。一定要确保所有的test在10到30分钟内全部跑完。如果不可能做到,那就将它们进行归类。

2.代码控制提交脚本。不管是svn还是git,都有各种hook的勾子程序,在每次commit前嵌入检查逻辑。这概念来自于传统意义上的“生产线”,一旦在线上的产品发现问题,将停止进入,进入暂停阶段。修好之后继续运转。如果1中的持续构建有一个test case不能过,那这个脚本要能够阻止再来的commit。简单地说,就是让代码能够检查的bug代码不能进入。

3.简洁的发布工具。不需要多复杂的工具,只需要每个人都遵守的、简单的办法,同时要遵循CI没通过就不能使用的原则。

4.实时的报警。不管多好的部署,都会有bug的存在。最讨厌的事情是部署了很久之后bug才出来。要抓住这些讨厌的bug,需要一个监控平台,出错的时候能够立即发现,找出bug。推荐使用nagios来加上自定义的数据进行监控,建议只要一两个关键数据,而且一定要报警准确。坚持一个原则就是,一旦报警,停止提交与发布。

5.寻根问底。这一步是方法学,多问为什么,可以让这个流程变得自我学习和成熟。比如:为什么没有在部署早期发现?为什么nagios没有报警?为什么没有在CI时发现?然后找到答案,改进这个过程。

再辅以上周在velocity上Etsy的操作过程,staging环境,让影响程度可控。更加细节一些,你需要对业务所处的层次进行划分,处于越上层的项目改动,越可以CD。


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]

捐款订阅54chen
捐赠说明

Comments