32 | 细谈移动APP的交付流水线（pipeline）
王潇俊
该思维导图由 AI 生成，仅供参考
你好，我是王潇俊。今天我和你分享的主题是：细谈移动 APP 的交付流水线（pipeline）。
在上一篇文章《了解移动 App 的持续交付生命周期》中，我和你分享了移动 App 的整个交付生命周期，并把移动客户端的交付与后端服务的交付方式进行了对比。从中，我们发现移动 App 自身的特点，使得其持续交付流程与后端服务存在一定的差异。
所以，今天我会在上一篇文章的基础上，和你分享移动 App 持续交付中的个性化内容。这些个性化的内容，主要表现在流水线的三个重要环节上：
采用与发布快车（Release Train）模式匹配的代码分支管理策略；
支持多项目、多组件并行的全新构建通道；
自动化发布，完全托管的打包、发布、分发流程。
接下来，我就从这三个角度，和你详细聊聊移动 App 的持续交付吧。
发布快车模式
首先，我先和你说说什么是发布快车。
顾名思义，发布快车，就像一列由多节车厢组成的火车，每一节车厢代表一个发布版本，整个火车以一节节车厢或者说一个个版本的节奏，定期向前发车。而工程师们，则会把自己开发完成的功能集成到一节节的车厢上，这样集成在一节车厢的功能代码，就形成了一个新的版本。
如图 1 所示，就很好地展示了发布快车的含义。
图 1 发布快车详解图
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
移动App持续交付是一个关键的技术话题，本文从发布快车模式、代码分支策略和构建通道三个方面详细探讨了移动App持续交付的个性化内容。首先，介绍了发布快车模式以及其适应移动App需求的特点，强调了选择与发布快车模式匹配的代码分支策略的重要性，以确保功能分支的合并和版本构建的顺利进行。最后，强调了构建通道的改造对于高效持续交付的重要性，包括增加合并构建过程以保证Master分支上的任何commit随时都可以成功构建。文章还介绍了移动App发布的自动化流程，包括iOS和Android系统的发布步骤以及利用Fastlane等工具实现发布的自动化。总结了移动App持续交付流水线的几个详细点，并提出了思考题，引发读者对团队持续交付流水线的思考和优化。整体而言，本文深入探讨了移动App持续交付的关键技术点，并提供了实用建议和工具，对于需要深入了解移动App持续交付的读者具有重要参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《持续交付 36 讲》，新⼈⾸单¥59
《持续交付 36 讲》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
lyonger老师，移动APP的自动构建和持续集成工具有什么区别呢？不知我下面这么理解有无问题。 1）自动构建比如gradle/maven是解决工程类的打包编译，包依赖问题，实际上是一个包管理器是么？ 2）而持续集成工具是一个可以自定义流水线的平台？2021-03-13
三件事老师还有一个问题 3.如果我们的实际开发比线上版本领先一到两个版本的话，采用 git flow 这种方式，分支管理就比较麻烦。对于这一点老师有没有什么好的办法？2019-10-15- 三件事老师你好，受益匪浅，想请教两个问题： 1.如何最大程度的提高构建速度？在打包设备一定的情况下。 2.从 master merge 回 dev 的时候有没有什么好的实践方式？2019-10-15
春和景明老师，我们知道 stages有如下特点 : 所有 stages 会按照顺序运行，即当一个 stage 完成后，下一个 stage 才会开始 只有当所有 stages 成功完成后，该构建任务 (Pipeline) 才算成功 如果任何一个 stage 失败，那么后面的 stages 不会执行，该构建任务 (Pipeline) 失败 针对第三个特点，我们有没有办法，让所有stage都能够执行呢？ 另外经常遇到的 Stage "xxx" skipped due to earlier failure(s) 是什么意思？该如何避免呢？2019-05-141
心在飞我们分支模型为 master -> integration->feature, 叫法不同，但使用方式上一样。master 打tag发布，每次feature合并到integration都要做DoD(definition of done)检查，包括sonar，coverity等。但我们是嵌入式设备（医疗行业），没有持续交付，只有持续部署。2019-02-27
收起评论
