持续交付36讲
王潇俊
携程系统研发部总监
立即订阅
7094 人已学习
课程目录
已完结 41 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 量身定制你的持续交付体系
免费
基本概念 (3讲)
01 | 持续交付到底有什么价值?
02 | 影响持续交付的因素有哪些?
03 | 持续交付和DevOps是一对好基友
配置管理 (4讲)
04 | 一切的源头,代码分支策略的选择
05 | 手把手教你依赖管理
06 | 代码回滚,你真的理解吗?
07 |  “两个披萨”团队的代码管理实际案例
环境管理 (6讲)
08 | 测试环境要多少?从现实需求说起
09 | 测试环境要多少?从成本与效率说起
10 | 让环境自己说话,论环境自描述的重要性
11 | “配置”是把双刃剑,带你了解各种配置方法
12 | 极限挑战,如何做到分钟级搭建环境?
13 | 容器技术真的是环境管理的救星吗?
构建集成 (5讲)
14 | 如何做到构建的提速,再提速!
15 | 构建检测,无规矩不成方圆
16 | 构建资源的弹性伸缩
17 | 容器镜像构建的那些事儿
18 | 如何做好容器镜像的个性化及合规检查?
发布及监控 (6讲)
19 | 发布是持续交付的最后一公里
20 | Immutable!任何变更都需要发布
21 | 发布系统一定要注意用户体验
22 | 发布系统的核心架构和功能设计
23 | 业务及系统架构对发布的影响
24 | 如何利用监控保障发布质量?
测试管理 (3讲)
25 | 代码静态检查实践
26 | 越来越重要的破坏性测试
27 | 利用Mock与回放技术助力自动化回归
持续交付平台化 (3讲)
28 | 持续交付为什么要平台化设计?
29 | 计算资源也是交付的内容
30 | 持续交付中有哪些宝贵数据?
持续交付移动App (3讲)
31 | 了解移动App的持续交付生命周期
32 | 细谈移动APP的交付流水线(pipeline)
33 | 进阶,如何进一步提升移动APP的交付效率?
实践案例 (4讲)
34 | 快速构建持续交付系统(一):需求分析
35 | 快速构建持续交付系统(二):GitLab 解决代码管理问题
36 | 快速构建持续交付系统(三):Jenkins 解决集成打包问题
37 | 快速构建持续交付系统(四):Ansible 解决自动部署问题
特别放送 (2讲)
持续交付专栏特别放送 | 答疑解惑
持续交付专栏特别放送 | 高效学习指南
结束语 (1讲)
结束语 | 越痛苦的事,越要经常做
持续交付36讲
登录|注册

32 | 细谈移动APP的交付流水线(pipeline)

王潇俊 2018-09-15
你好,我是王潇俊。今天我和你分享的主题是:细谈移动 APP 的交付流水线(pipeline)。
在上一篇文章《了解移动 App 的持续交付生命周期》中,我和你分享了移动 App 的整个交付生命周期,并把移动客户端的交付与后端服务的交付方式进行了对比。从中,我们发现移动 App 自身的特点,使得其持续交付流程与后端服务存在一定的差异。
所以,今天我会在上一篇文章的基础上,和你分享移动 App 持续交付中的个性化内容。这些个性化的内容,主要表现在流水线的三个重要环节上:
采用与发布快车(Release Train)模式匹配的代码分支管理策略;
支持多项目、多组件并行的全新构建通道;
自动化发布,完全托管的打包、发布、分发流程。
接下来,我就从这三个角度,和你详细聊聊移动 App 的持续交付吧。

发布快车模式

首先,我先和你说说什么是发布快车。
顾名思义,发布快车,就像一列由多节车厢组成的火车,每一节车厢代表一个发布版本,整个火车以一节节车厢或者说一个个版本的节奏,定期向前发车。而工程师们,则会把自己开发完成的功能集成到一节节的车厢上,这样集成在一节车厢的功能代码,就形成了一个新的版本。
如图 1 所示,就很好地展示了发布快车的含义。
图 1 发布快车详解图
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 三件事
    老师还有一个问题

    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-14
  • 心在飞
    我们分支模型为 master -> integration->feature, 叫法不同,但使用方式上一样。master 打tag发布,每次feature合并到integration都要做DoD(definition of done)检查,包括sonar,coverity等。但我们是嵌入式设备(医疗行业),没有持续交付,只有持续部署。
    2019-02-27
收起评论
4
返回
顶部