本文讲的是Intercom的持续部署实践：一天部署100次，1次10分钟，
【编者的话】这篇博文分享了 Intercom 公司在持续部署的经验和体会。Intercom 公司从创业起步时就开始认定持续部署的重要性，从2002年每天10次部署，到今年每天接近100次的部署，积累了丰富的经验，对持续部署有着较为深刻的认识，虽然本文没有详尽的技术细节，所谓的干货，不过个中经验分析，比如 "帮助新来的工程师"这个想法蛮有新意，另外正如文中所说 -- "部署时间的增加，会使你的产品变得越来越无趣 ...... 因为效率在降低，学到的东西在减少，工程师会变得很沮丧 ...... "，编者作为同行，也深有感触，特此推荐。
对于持续部署，湾区日报这样评论：
一个团队工程技术水平高低，直接反映在部署代码上。我碰到其他公司的人，都喜欢问你们怎么部署代码的，非常大开眼界。你很难相信，很多（有一定规模的）公司仍然是人肉SSH到十几、二十台机器上git pull、手动重启服务器，部署一次代码几个小时 -- 这么原始，活该加班：）快速自动部署新代码，对 Intercom 来说，是整个产品构建的重中之重。Intercom的运维工程师如是说。
持续部署这件事在公司的初期就已经开始了。最近 Intercom 的 On Product 会议，我讲了有关持续部署带来的那些未曾预期的回报，下面这个版本在此基础上稍稍有所更新。
Intercom 的一个核心价值在于我们的目标很大，但从小处开始着手。也就是说，对那些大的不确定的但有影响力的项目，我们会将它们拆成一系列小的、安全的步骤。开发新的产品功能时，我们先做一个最简单的版本，给它一个标签来部署，当然这些标签只有 Intercom 的成员能看到。根据反馈，会打补丁并改进，之后推给Beta客户使用。再经过一轮的迭代、修改之后，我们就会将这个功能发布给每个人。
这一条反馈路径价值巨大，用在每一个产品开发中。从中我们学到了客户如何使用这些功能，代码如何在线上环境发挥作用，甚至讨论这些想法够不够好。对于大多数新功能来说，在真正把它推给客户之前，几十次的迭代开发我都进行了部署。而且，多个功能在同一时间被开发，也就是说，我们一天都要部署很多次。
通过我们内部的部署图表，可以看出，过去三年我们每一天部署的次数。2012年中期的时候，一天大约要部署10次，而今天则要超过80次。我估计2015年年末的时候，一定会超过100次。
其中，部署次数的大规模提高，主要源自团队人数的显著增长。当我们有很多开发者，需要每天80次的改变，来共同完成一个产品时，这要求我们的部署流程更快、更流畅且更可靠。
回想曾经我们只有六个人，一起构建 Intercom 的自动化部署系统。
下面是一个关于这个系统的介绍：
在GitHub上做完代码检查之后，工程师就会将他们做的功能放进主代码树。GitHub会发通知给Codeship，由它运行我们的测试用例，保证之前存在的功能不会因为这些新的改动而出现问题。GitHub也会发通知给我们的工具"Muster"，用来准备最新版本的代码做发布。
一旦测试用例都跑通过，Codeship会给Muster发消息，代码会被推到我们线上的环境中，大约200台的EC2机器。
整个部署过程，全都算上，也没超过10分钟，很快。这样，工程师不用等很久就可以见到自己的功能上线了；如果是在做Beta的功能，在上线前，我们有一堆的bug要修，假设代码写得够快，就可以保证在一天之内把它们都部署上去。
额外的回报
过去的三年，由于天天做这些事，我们注意到持续部署对我们的工作还有一些其他有意思的好处。帮助新来的工程师
一个新来的工程师，第一周，我们都会为他设定两个初始目标：他们第一天必须要发布一些代码到线上环境，第一周必须要发布一个功能。这会让他们感觉到自己很棒很高效。周五的时候我们会有专门一个环节，给整个公司来展示这一周我们做的事；站在那，给你的同事展示，你在公司的第一周，就给客户带来的线上新功能，很有成就感吧。
当然这些目标对于一个新来的工程师而言，还是蛮有挑战的。在你完成这个目标之前你需要做很多的准备工作：配好笔记本，和团队讨论，想出你将做的事情，然后写代码，可能 Intercom 中使用的编程语言并不是你熟悉的那种，所以这里有很多的困难，也许你在第一周完不成这个新功能。
不过有一点，不会拖慢你在 Intercom 工作效率，那就是搞清楚如何部署你的改动。因为有全自动化的部署系统，这一困难就不复存在，新工程师也能随时部署他们的改动。如果他们对此有兴趣的话，也可以后面再来研究自动化部署是如何工作的，甚至看懂代码改进部署系统。对于他们的第一周，不用去学习部署的规则和流程，确实帮助很大。
摒除坏习惯
> 线上环境打补丁： pic.twitter.com/saD82hLacz-- Practical Developer (@ThePracticalDev) August 11, 2015
另一个有意思的好处是持续部署可以帮助我们摒除坏习惯。当你在线上环境中发现一个很严重的bug，会尽可能的想办法快速修掉这个问题。
如果部署的系统很慢，从代码入主树到最后部署上线需要二十分钟的话，你会想用任何可能的方法来尝试修复，包括一些很不正规的方式。这听起来有点莽撞，但它可能是正确的选择。因为你不想坐在那里，等待20分钟，结果看着你的程序奔溃。这里的诀窍就是得让你的部署系统快速，足够可靠，更容易使用，这样就可以避免在线上环境那些不正规的修复方式。
优化我们的部署效率
这件事的工作量很大。我们知道目前部署过程需要8-9分钟，这并不差，但可以更好。我们团队当前很多的工作就是优化部署系统，让它变得更快。理想中，我们只要3-4分钟，这样就可以保证有每一天100次以上的部署。
如果你的公司很成功，一段时间之后呢，很多事情也会开始变化。你会雇佣更多的人，你的团队会增加，你们会写更多的代码，你的代码库会增长，也会引入新的流程（比如六个人能干的事不要100个人去干），期望中你们会写很多的自动化测试，加新功能时可保证不会干扰到已有的。但所有这些都会增加部署时间，也就是说会减慢反馈路径所经历的时间。
这也会使你的产品变得越来越没趣。因为每一天你的效率在降低，学到的东西也在减少，工程师会变得很沮丧，这会让你的产品变得很糟糕。很有可能会犯错误，构建错误的功能，投资在一些其实并不需要投资的地方。
所以呢，在 Intercom 的早期，我们就认定减少部署时间，对于反馈路径的缩短极为重要，即我们要能够在最短的时间内为客户构建准确的功能。
原文链接：Why Continuous Development Just Keeps On Giving（翻译：Henry Huang）
===================================
译者介绍
Henry Huang ，目前供职于趋势科技 Trend Micro（南京），负责集群运维的工作。
原文发布时间为：2015-09-28
本文作者：henrysher
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：Intercom的持续部署实践：一天部署100次，1次10分钟
