DevOps 该是 Team Lead 的必备技能

随着移动互联网的这么多年的发展,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!

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

任选一种支付方式

1 2 收藏 评论

关于作者:蒋 伟

(新浪微博:@幻想哥呀幻想哥,个人博客:Jacob) 个人主页 · 我的文章 · 2 ·    

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部