DevOps实战: RingCentral Glip持续集成最佳实践

随着移动互联网的这么多年的发展，App的开发也越来越成熟，长期维护一款App成了新的常态，快速稳定的迭代发布成为了衡量产品开发团队的重要指标。

这也导致了平时1，2个月才提交一次App Store的事情，变成了1，2周就需要做一次。产品团队甚至每天都需要看一下研发的daily build是不是符合期望值，做出及时的设计调整。

这让研发团队中，平时时间占比很小的编译，unit test, 准备build，上传build，分发给PM,QA,监控产品各项数据指标，修复crash report中的bug，等等变得占比非常大。

以上的工作我简称DevOps，说白了是为开发者服务，让开发者很投入的专注在代码工作中，其余的交给Team Lead。用魔兽的语言来说，就是光环，加攻加防。

那么怎么做好DevOps呢？

首先在心中要有一点，加攻加防要考虑投入回报比，只有划算的投入才值得投入。

还是以魔兽塔防来举例，一个塔默认攻击100点；摆在面前的选择是升级攻击300块，可以增长100点攻击； 旁边盖一个光环加攻加防也是投入300块，可以每个塔增加10%攻击，那你只会获得10的收益。显然这300块用来直接升级比较好。 如果你有30个塔，那么300块的光环塔的投入就可以带来300的攻击总收益，显然这300块用来盖光环塔更加划算。

那么研发工作中哪些有共性的投入很划算呢？

1.硬件升级

如果你的team member还在使用过时的电脑作为开发机器，编译时间超过10分钟，checkout代码需要10来分钟以上，配置证书每个人都花费大半天琢磨，debug需要更长的时间，甚至机器卡死，当年作为team lead发现这样的事情的时候，你就要警惕了。这是研发效率低下的显著影响因素，你有责任向老板说清楚升级的必要性。

这里向老板汇报，其实也是有技巧的。

一个不善于沟通的team lead会怨气很大的说，你看，编译时间这么长，我也没办法啊！老板心里其实想的是，这Team Lead只知道抱怨，不知道多加加班么？

一个聪明的team lead会拿出事实数据来说话，譬如你看经过我观察，每个开发每天debug 20次，每次要花费5分钟时间干等，或者去喝杯茶，10人的研发团队就是1000分钟，整整2人天的时间白白浪费了，每个月你会浪费40人天，如果你能节省下来这个时间，你就省下来2个程序员的工资。而这部分的固定资产的投入可能是非常少的，譬如每个人8GB内存升级到16GB，也就几百块而已。

2.jenkins持续化集成

这个概念以前叫Continue Integration，现在Jenkins 2.0的概念叫Continue Delivery。

jenkins的可扩展能力非常强，建议大团队都选用这个。Xcode Server虽然有着类似的理念，但是不开放导致了各种坑，作为淌过各种坑的我，真心不推荐。

那么jenkins可以让开发团队中绝大部分的工作自动化执行。

下面我就以在RingCentral的例子来谈谈我们是怎么做的。

首先，我们有需求做出来各种不同的build，有内测in-house版本，有QA测试的正式版限定100台机器，有Automation用的开发破解版。那么怎么一套代码做出来不同版本的build?手动维护，显然不符合我们的理念。 于是我们写了脚本来自动替换代码中的配置，其中shell, python混用。后来我们注意到改的配置就那么几个东西，我们干脆用git diff文件来代替，脚本简化了，更加从容的配置。这样也方便了开发者，轻松sourcetree apply一下diff文件，就可以智能切换各种配置。

jenkins配置了不同的job，通过名字，就能智能判断当前该用的profile configuration，这样team member只需要拷贝job，就可以轻松实现生成自己的feature build，省去了大量繁琐的配置，team member不需要浪费精力在这些上面。

我们的mobile app集成了crash监控服务crittercism,他可以做到实时监控crash数据，汇报新的crash。但是开发之前每次都需要手动上传dSYM文件，显得很麻烦。 于是网上找到jenkins插件，配起来，每次编译完build，自动上传，省心又方便。注意，官方的插件还是坑挺多的，经常上传文件假卡死，后来我们干脆写到编译脚本里，更加定制化。

编译好了job，我们还需要动态的发布给PM,QA等，并且要通知他们。怎么办？

我们国外采用了HockeyApp，微软收购后，质量更稳定了，也找到了hockeyapp插件，自动发布，自动推送。

针对国内网速，我们采取了fir.im，国内下载更快，更加方便。不过他们的2015年维护的脚本，实在是坑很大，费了我很大的功夫才能调整好搜寻文件路径。

还有针对Adhoc/App Store的上传TestFlight的神器，叫fastlane，其中gym和deliver两大神器结合使用最牛逼。可以全自动上传App Store，作为公司内部25核心人员（其实是领导）使用，不仅傻瓜化好用，而且还带push notification功能。感觉有点离不开TF了。不过不建议全部使用fastlane，没有他们网站上说的那么天花乱坠，很多开发者直接在自己电脑上跑一下，自然不错。但是fastlane劫持了output输出，导致放到server跑的时候jenkins build的日志不全面，关键信息看不到。毕竟jenkins slave是一个个纯净版的Mac Pro的slave组成的，这个可以让工作自动分配到闲时的机器上运行，还可以保证不会遇到之前的病毒版xcode的坑，想想微信，网易云音乐的那些病毒版build就知道，不能相信开发者自己电脑的编译了。

关于jenkins的集成，还有很多应用，诸如code analyse, cppcheck, warning report, doxygen集成，等等，我不一一阐述。

重点是用上了这些后，本来需要数个小时的任务，让工作全自动化了。彻底解放Team Lead的节奏！

3.会写一些脚本

虽然术业有专攻，但是懂一些基本的script，php,python，nodejs，技多不压身。举个例子，我们的每个build都有个版本号，在很多平行的job之间，怎么维持一个统一的自增build数字号，看似很简单的要求，却需要一整套的方案。

Jenkins自然不会有这么定制化的插件，于是发挥自己创造力的时候来了。php写一个内部的自增server，编译前运行script去执行一段python代码，获取http result，通过plist插件写入代码的配置文件，编译完的build自动读出来build number，便于qa汇报问题。执行完毕后自动回退代码git reset –hard，轻松清理现场。

如果没有这个小功能，每次领导说遇到一个BUG，开发就会问，“你是不是安装的最新版？” 这下彻底堵住了嘴，效率提升了，更加专注于修bug，写代码。

DevOps, Deploy better software faster

这不恰好符合一个Team Lead的职责么？很多Team有着优秀的开发人员，没有道理因为公司体制或者其他原因限制了个人能力的发挥。

一个优异的Team lead会让开发成员更专注更高效的研发产品，让市场感受到开发者在后面的每一个feature后面的良苦用心，我一直认为好东西靠宣传，开发者也一样，good stuff deserver louder voice!