前言
可借力的渠道级服务：字节的火山引擎 移动DevOps，腾讯的Coding，阿里云EMAS，支付宝mPaaS。 本篇全体实践是依据阿里云 EMAS+CodeUp流水线+自研东西链+内部协作流程
原文：10人小团队的移动 DevOps 实践经历概括
曩昔两年都在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则能够看作是一个超级大流程，它拆分出多个子流程，关联到了不同功能端的人员，分别为她们供给标准化作业引导。
滑到底部可点赞谈论
阅读橘子树其他文章：橘子树的飞书写作记载
