五步构建持续性部署(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]
Posted by 54chen 架构研究