Intercom的持续部署实践:一天部署100次,1次10分钟


【编者的话】这篇博文分享了 Intercom 公司在持续部署的经验和体会。Intercom 公司从创业起步时就开始认定持续部署的重要性,从2002年每天10次部署,到今年每天接近100次的部署,积累了丰富的经验,对持续部署有着较为深刻的认识,虽然本文没有详尽的技术细节,所谓的干货,不过个中经验分析,比如 "帮助新来的工程师"这个想法蛮有新意,另外正如文中所说 -- "部署时间的增加,会使你的产品变得越来越无趣 ...... 因为效率在降低,学到的东西在减少,工程师会变得很沮丧 ...... ",编者作为同行,也深有感触,特此推荐。

对于持续部署,湾区日报这样评论:


一个团队工程技术水平高低,直接反映在部署代码上。我碰到其他公司的人,都喜欢问你们怎么部署代码的,非常大开眼界。你很难相信,很多(有一定规模的)公司仍然是人肉SSH到十几、二十台机器上git pull、手动重启服务器,部署一次代码几个小时 -- 这么原始,活该加班:)
快速自动部署新代码,对 Intercom 来说,是整个产品构建的重中之重。Intercom的运维工程师如是说。

持续部署这件事在公司的初期就已经开始了。最近 Intercom 的On Product会议,我讲了有关持续部署带来的那些未曾预期的回报,下面这个版本在此基础上稍稍有所更新。

Intercom 的一个核心价值在于我们的目标很大,但从小处开始着手。也就是说,对那些大的不确定的但有影响力的项目,我们会将它们拆成一系列小的、安全的步骤。开发新的产品功能时,我们先做一个最简单的版本,给它一个标签来部署,当然这些标签只有 Intercom 的成员能看到。根据反馈,会打补丁并改进,之后推给Beta客户使用。再经过一轮的迭代、修改之后,我们就会将这个功能发布给每个人。
Feedback-loop-624.png

这一条反馈路径价值巨大,用在每一个产品开发中。从中我们学到了客户如何使用这些功能,代码如何在线上环境发挥作用,甚至讨论这些想法够不够好。对于大多数新功能来说,在真正把它推给客户之前,几十次的迭代开发我都进行了部署。而且,多个功能在同一时间被开发,也就是说,我们一天都要部署很多次。
Ships-per-day-624.png

通过我们内部的部署图表,可以看出,过去三年我们每一天部署的次数。2012年中期的时候,一天大约要部署10次,而今天则要超过80次。我估计2015年年末的时候,一定会超过100次。

其中,部署次数的大规模提高,主要源自团队人数的显著增长。当我们有很多开发者,需要每天80次的改变,来共同完成一个产品时,这要求我们的部署流程更快、更流畅且更可靠。

回想曾经我们只有六个人,一起构建 Intercom 的自动化部署系统。
Continuous-Deployment-Overview-624.png

下面是一个关于这个系统的介绍:

在GitHub上做完代码检查之后,工程师就会将他们做的功能放进主代码树。GitHub会发通知给Codeship,由它运行我们的测试用例,保证之前存在的功能不会因为这些新的改动而出现问题。GitHub也会发通知给我们的工具"Muster",用来准备最新版本的代码做发布。

一旦测试用例都跑通过,Codeship会给Muster发消息,代码会被推到我们线上的环境中,大约200台的EC2机器。

整个部署过程,全都算上,也没超过10分钟,很快。这样,工程师不用等很久就可以见到自己的功能上线了;如果是在做Beta的功能,在上线前,我们有一堆的bug要修,假设代码写得够快,就可以保证在一天之内把它们都部署上去。

额外的回报

过去的三年,由于天天做这些事,我们注意到持续部署对我们的工作还有一些其他有意思的好处。

帮助新来的工程师

Friday-demos-1248.png

一个新来的工程师,第一周,我们都会为他设定两个初始目标:他们第一天必须要发布一些代码到线上环境,第一周必须要发布一个功能。这会让他们感觉到自己很棒很高效。周五的时候我们会有专门一个环节,给整个公司来展示这一周我们做的事;站在那,给你的同事展示,你在公司的第一周,就给客户带来的线上新功能,很有成就感吧。

当然这些目标对于一个新来的工程师而言,还是蛮有挑战的。在你完成这个目标之前你需要做很多的准备工作:配好笔记本,和团队讨论,想出你将做的事情,然后写代码,可能 Intercom 中使用的编程语言并不是你熟悉的那种,所以这里有很多的困难,也许你在第一周完不成这个新功能。

不过有一点,不会拖慢你在 Intercom 工作效率,那就是搞清楚如何部署你的改动。因为有全自动化的部署系统,这一困难就不复存在,新工程师也能随时部署他们的改动。如果他们对此有兴趣的话,也可以后面再来研究自动化部署是如何工作的,甚至看懂代码改进部署系统。对于他们的第一周,不用去学习部署的规则和流程,确实帮助很大。

摒除坏习惯

> 线上环境打补丁:pic.twitter.com/saD82hLacz
-- Practical Developer (@ThePracticalDev) August 11, 2015

另一个有意思的好处是持续部署可以帮助我们摒除坏习惯。当你在线上环境中发现一个很严重的bug,会尽可能的想办法快速修掉这个问题。

如果部署的系统很慢,从代码入主树到最后部署上线需要二十分钟的话,你会想用任何可能的方法来尝试修复,包括一些很不正规的方式。这听起来有点莽撞,但它可能是正确的选择。因为你不想坐在那里,等待20分钟,结果看着你的程序奔溃。这里的诀窍就是得让你的部署系统快速,足够可靠,更容易使用,这样就可以避免在线上环境那些不正规的修复方式。

优化我们的部署效率

Optimising-Deployment-Rate-624.png

这件事的工作量很大。我们知道目前部署过程需要8-9分钟,这并不差,但可以更好。我们团队当前很多的工作就是优化部署系统,让它变得更快。理想中,我们只要3-4分钟,这样就可以保证有每一天100次以上的部署。

如果你的公司很成功,一段时间之后呢,很多事情也会开始变化。你会雇佣更多的人,你的团队会增加,你们会写更多的代码,你的代码库会增长,也会引入新的流程(比如六个人能干的事不要100个人去干),期望中你们会写很多的自动化测试,加新功能时可保证不会干扰到已有的。但所有这些都会增加部署时间,也就是说会减慢反馈路径所经历的时间。

这也会使你的产品变得越来越没趣。因为每一天你的效率在降低,学到的东西也在减少,工程师会变得很沮丧,这会让你的产品变得很糟糕。很有可能会犯错误,构建错误的功能,投资在一些其实并不需要投资的地方。

所以呢,在 Intercom 的早期,我们就认定减少部署时间,对于反馈路径的缩短极为重要,即我们要能够在最短的时间内为客户构建准确的功能。

原文链接:Why Continuous Development Just Keeps On Giving(翻译:Henry Huang)

===================================
译者介绍
Henry Huang,目前供职于趋势科技 Trend Micro(南京),负责集群运维的工作。

1 个评论

哈哈,顶一下!

要回复文章请先登录注册