前言
可借力的平台级服务：字节的火山引擎 移动DevOps，腾讯的Coding，阿里云EMAS，支付宝mPaaS。 本篇整体实践是基于阿里云 EMAS+CodeUp流水线+自研工具链+内部协作流程
过去两年都在toB型公司负责移动端团队技术建设，这是一段非常重要的经历，借助本篇内容做个沉淀。
做这个事情的前提是有平台，我准备做的时候技术中心处于巅峰时期，整体有近200人，移动端10多人。当然公司还有其他子业务线，他们也有自己的技术团队，一般在30人以下，如果我在这些团队，这事儿可能就没有做的必要了。
移动端负责公司主营业务全线产品研发，涉及商品购物端APP，TMS APP，CRM APP，PDA APP，工人 APP等多个APP的开发，而我作为移动端负责人才有机会与各业务线不同的上下游人员直接接洽。比如上游：产品团队，前后台研发团队。下游部门：测试团队，运营部，客成团队。甚至包括销售，仓库同事，一线用户等等。这就是所谓的屁股决定脑袋，或者是屁股决定眼界的理论。
在持续的协作中，我就会挖掘到大量与移动端关系紧密的问题，这里面有大部分都会直接影响产研团队的研发能效。
比如：
- 仓库人员下载PDA 使用蒲公英二维码，经常下载错误，或者反馈问题反馈的版本是错误的，导致排查问题经常做无用功
- 不同产品线，对接的产品，测试，运营都不同，每次都要倒追大家关注app发布事宜，避免事故，经常吃力不讨好，组员们哀声载道
- APP 上线后发现版本信息错误（版本号，更新说明，更新方式）
- APP打包时间等于“摸鱼时间”，我用的m1也要30秒-1分钟，有的同学得4-5分钟。每天有不少人找开发打包，同一个代码版本的包很有可能被打多次，这些消耗的时间最后不得不用加班时间去补。
- APP 打包没有质量监控与日志跟踪，谁打的，什么需求，什么分支，是否同步过master最新代码，是否通过code review ，有没有打 tag，在处理反馈问题时往往像个无头苍蝇
- 花很多精力做的技术分享，包含的最佳实践代码与需要避免的坏代码如何保障长期可靠的执行效果？
- 项目人员变更时总是容易出现版本发布事故，有些事故还被“藏匿”了，表现为大家很努力，加班到深夜终于解决了XX问题。但是这个问题应该出现吗？
- 同一个APP，多个版本，多人协作开发，并行开发，如何管理分支，如何管理版本
- 多个原生项目如何提供一致性的小程序，H5，Flutter混合开发支撑能力
乍一看似乎这些问题都太零碎了，有协作流程，工具服务，开发管理，软件架构，基础架构服务总之就是：乱！
建设移动 DevOps 就是为了解决或规避此类问题的，从系统思维出发，解决问题之后考虑如何彻底规避问题。通过优秀的流程+工具，提高团队整体的协作效率与生产质量。
根据我的实践经验，并不需要一次性建立完整的的移动 DevOps 才能获得效益。在定下一些基础的服务平台或技术栈以后，就可以进行有选择性的建设，快速投入使用发挥它的作用，更重要的是做长期规划。
我很喜欢一句关于研发能效的描述「在软件规模，产研发团队扩大时，研发能效无法被提高，我们能做的就是竭尽所能的减缓它下降的速度」，听起来好像有点悲观，但事实确实如此。
盘点与规划
盘点分为3个方向，按优先级顺序分别是业务侧技术服务、基础技术服务与人
既然是中小型公司，那么就不太可能为移动端设立独立的基础架构服务组，这过于奢侈且浪费资源。可行的办法之一就是抓住业务空窗期推进，根据业务压力，技术积累速度调整节奏，小步走，打持久战。
梳理业务侧技术
这一步是为了先打好基础，为后续技术建设提供「优质土壤」，不然后续就像是在沼泽地上盖房子。
从技术栈上看，Android 有 kotlin 与java，IOS 有 OC 与 Swift，另外还包括H5，小程序，Flutter。涉及代码架构，模块化技术方案，组件化方案，原生模块独立发布管理，混合开发模块发布管理管理，基础库管理。分析清楚项目开发现状，在业务侧都没有理顺形成标准化之前，弄其他的都属于本末倒置。
按照基础库>模块>宿主可以拆分成下图这样：
按照这样的架构用于指导后续向APP工程化迭代，老项目根据此架构进行代码剥离，解耦业务模块，沉淀基础库。梳理出全部组件，组织讨论会敲定优先级。最后落实到任务表中，穿插到业务开发任务间隙里进行开发。
这里在分配任务时要充分考虑团队成员的个人能力与自身兴趣，一开始鼓励大家自主认领，尽力让每个人都能自由选择，我一直觉得兴趣是最好的自驱力。但作为管理者要考虑是否存在眼高手低与畏难的情况，这是人之常情，有时候需要利用利责权的方式进行调配，与此同时基于他们充分的资源支持，一是调剂工作压力，二是协调外部测试资源配合验收，部分基础库上线会直接影响业务功能，测试能从专业务角度把把关能，充分避免发生低级错误。
这一步就已经需要开发部分与DevOps相关的基础服务了，如：
- 提供 Maven 仓库，CocoaPods服务
- 提供配套自动化&标准化发布脚本（native，小程序，H5，flutter）
- 制定独立库发布流程
- IM 信息同步脚本，@相关负责人，形成发布记录，避免口口相传
制定严格的基础库开发规范，版本管理规范，做好防劣工作，避免因为个人疏忽或新人不熟悉导致整体模块化快速劣化，保障业务侧可以长期更新并安全使用。
模块化一定要彻底，保证后续能支撑多项目同步升级。基础库开发要高标准，超过平时业务侧的标准是必然的，从技术选型，方案设计，设计模式，API命名，性能测试，注释文档都要严格要求，一丝不苟。因为基础技术服务马虎一点，就是对业务侧极大的不负责任，直接为公司产品带来严重损害。
99%的方案都是别人做过的，在做之前充分收集信息，汇总同方向的开源库进行深入调研，最终决定是二开还是从0开发，尽可能的满足接口隔离原则，为业务层屏蔽实现细节，未来可以随时更换底层服务。
设计基础技术服务蓝图
这部分是对上面平台层模块的再次抽象，形成服务型结构。对框架组件提供更细的拆分，从底层支持跨平台混合技术栈的统一解决方案。降低业务侧完成产品需求的前期成本。
从开发效率，软件质量监管，版本发布，线上质量监控预警四个大方向进行设计。需要配置构建机器，开发打包插件、Lint插件、CI/CD，集成热修复、APM，企业办公软件应用。兼顾上游产品与下游测试的协作，提供配套的自动化流程与工具服务，形成移动DevOps的整体布局框架。
优先考虑可快速接入的服务，比如提供API接口的第三方服务。同时根据团队实际情况，对部分迭代需求较大的模块进行自研。比如CI，整体调研完后决定用阿里云的EMAS做部署容器，省去自己搭建容器，与Jenkins开部署，但是整个打包控制插件进行自研，并自动采集数据入表分析。
完整的蓝图：
最早参考的是阿里云EMAS的文档，之后不断结合美团，字节等大厂团队的分享，吸收经验后根据团队情况进行了更换与补充。
人员规划
根据上面的规划计算人力与时间的关系表，在内部做人才盘点，在外部寻找借力。
把内部人员从学习能力，技术热忱，抗压能力，自我要求这几个维度排个序，挑出靠前的小伙伴。因为做移动DevOps 需要极强的学习能力，可能每隔几天就要突破下舒适圈，学习新技术栈，不能止步于一种语言和一个端。也不能止步于所谓的开源方案应用，学习的同时敢于挑战它们。
在招聘时设置与此对应的HC，不过没有硬核实力的团队挺难招到这类人的，因为他们就属于完全胜任了基础工作，额外还在这方面做出了不错的成绩。当时好不容易从技术圈子里“勾搭”了一个，最后人家去B站了，即使当时给的待遇超过了B站。所以把手上的牌打好比总想着下一张会更好要实在的多
同时自己作为负责人要孜孜不倦的如饥似渴的拓展自己的技术视野，这样在团队向前推进的时候自己才有更全面的判断力，分析能力，尽可能减少大家不必要的试错成本，节省宝贵的时间。
包含后端云服务器，容器化部署，CI 链接企业应用，对象存储服务，web后台开发，第三方服务定制化开发方案评估等等。
实施
建立里程碑
到了这一步就是执行力与项目管理方面的实践了，整体来说在团队技术氛围浓郁，KPI设计大家都认可的时候很好推进。也有难点，那就是大家也会经历完全陌生，缺乏信心的时期。在大家都觉得做不出来，或者觉得已经到极限没有更好的解决方案时，我要想办法再推大家往前再进一步，可以身先士卒带头公关，要么竭尽所能的为辅助他们分析阻碍原因，扫清障碍，降低难度，直至达成目标。
技术沉淀
公司以ToB业务为重心，平时APP侧面临的技术挑战都不算太大，远不如后端。而移动DevOps 则会带来更难的挑战，包括网络质量监控需要深入协议层理解分析，优化编译速率需要了解APP构建全流程，模块拆分需要深入结合设计原则与业务特性， CocoaPods 私有化部署，自动化发布 成熟的完整资料少之又少，需要自己摸索尝试等等。
更重要的是，你写的代码不再只是测试从表面去验证IO正确性，而是每天会被大家使用，重复的阅读，无形中提高了大家的自我要求，也发挥出了团队优势。
一些记忆犹新的里程碑：
- Android 侧开发了包管理服务，设计的安装包二维码，一码一包，之后再未收到下错包，找不到包的反馈
- 在挖掘了所有的 Android Lint方案后，完成了深度二开，形成很强的Lint实践，支按文件类型，文件时间等维度自定义扫描范围，支持SDK动态更新，规则持动态发布，局部降级等等，与CI 无缝结合。（关于Lint 我之后准备单独进行开源，我想这是一个非常具备实用价值的事情。）
- APP网络质量监控预警，反向挖掘出了多个服务器接口质量问题
- 分析Android 主线程卡顿后完成xml预加载自研
- IOS 模块化部署后支持CI上云，完成自动化发布
- 提供完整的CI服务：
到这一步整体移动DevOps的服务已经完成初步建设，下一步就是将还未进行自动化串联的服务模块串联。以及一些需要依赖web后台进行可视化展示，我在21年做年终述职时提出移动DevOps，那时候就给自己制定了一个22年的年度目标：学习后端开发技术，这一flag在22年11月完成。非常遗憾的时最终没能应用到移动DevOps建设上来，因为公司面临重大危机，业绩持续下滑，这时候已经没有必要再推进研发能效相关事宜了。
- 主干梳理：
原文可查看全部roadMap：10人小团队的移动 DevOps 实践经验归纳
推广使用
想要落地推广一个协作流程，要充分考虑到：人天然是抵触新事物的。
后记：管理经验归纳
移动DevOps对很多移动开发者或管理者来说可能还是一个比较暧昧的词。因为一些刚起步的小型公司，管理上开发资源多是项目制度的，前端单端一般不会超过4个人，单项目人数不超过20个。会采取Scrum等敏捷开发模式，团队规模小有灵活度高，协作效率高，问题发现快，响应速率高等优点。这时候要的是快速交付，满足产品做MVP，对交付质量的宽容度高，都是单兵作战为主，很少涉及到研发能效影响到产品速率的问题。
在公司逐渐壮大时，项目变多，有大有小，有的项目可能长达几个月，有的只需要几天。人员超过50，100人时就会调整管理模式，因为再继续按照项目制配人就会造成严重的研发资源空置。
这时候一般会采取职能划分制，比如分为后端组，前端组，测试组，产品组，架构组，运维组等等职能部门。端内再按业务分主辅AB小组或AB角色。
各个项目按照评出的优先级申领开发资源进行开发。相比较原来的求快，这时候如何保持安全、稳定、高效产品发布节奏就更为重要。
为了保证协同效率，团队会设计协作流程，操作规范等严格的产研发制度，这时候往往一些同学需要一段时间适应，觉得原来简单的事情搞复杂了。比如APP 要发版了，产品就在群里喊一下不就完了吗？App我打个包点一下鼠标的事情，企业IM发给测试就完了，这能出什么错？
从个人角度出发这都没有问题，但是从团队角度看就很不一样了。比如大家工作能力高低不同，同样一个事情交给P2，p3与p6，P7 得到的理解与执行效果差别会很大。再加上同事之间相互了解程度不同，对对方的能力判断有偏差，很容易产生团队摩擦。（“ta能力太差了，这种常识性的问题都出",其实ta可能才毕业不到1年，需要时间学习）
设计流程制度就是为了解决这一问题的，用同一套流程去跑，让不同能力水平的人，跟着流程就都能得到80分的结果。好的流程在各个节点上会提供绝对清晰的标准化的执行规范，尽可能的避免了因个人能力不同导致的执行偏差。
那么移动DevOps则可以看作是一个超级大流程，它拆分出多个子流程，关联到了不同职能端的人员，分别为她们提供标准化作业引导。
滑到底部可点赞评论
浏览橘子树其他文章：橘子树的飞书写作记录