赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式

赵成 2018-02-04
在前面 5 期文章中,我们分别详细介绍了持续交付体系基础层面的建设,主要是多环境和配置管理,这些是持续交付自动化体系的基础,是跟我们实际的业务场景和特点强相关的,所以希望你一定要重视基础的建设。
本期文章是我们持续交付系列的第 6 篇文章,从本期开始,我们进入到交付流水线体系相关的内容介绍中。

持续交付流水线简要说明

从一个应用的代码提交开始,到发布线上的主要环节,整个流程串起来就是一个简化的流水线模式。如下图所示:
我们前面介绍了持续交付的多环境以及配置管理,而流水线模式的整个过程正是在这个基础上执行,所以它的某些环节和要素与我们的多环境是有一些交叉的。比如,功能测试会在线下相关的几个环境上完成,比如我们前面介绍到的开发联调环境、项目环境和集成测试环境。
但是,它们要达成的测试目的是不同的:对于非功能验收,我们会在线上的预发环境完成,因为预发环境更接近真实场景,所以像容量、性能、安全这些跟线上稳定性相关的能力验收,越接近真实环境,效果越好。
后面几期文章,我会结合我们的实践,分环节来介绍。本期文章我们先看项目需求分解和开发模式选择。

项目需求分解

持续交付我认为更多的是针对应用层面,所以项目需求分解这一部分,这里我们就不展开讲了。这里我们的工作重点,就是将项目管理中的需求与持续发布中的应用这二者很好地关联起来。
比较通用的做法,就是要求业务架构师在做需求分析和功能设计时,要针对一个需求进行拆分,最终拆分成一个个的功能点,这些功能点最终落实到一个个对应的应用中,对应的逻辑体现就是应用代码的一个 feature 分支
如下图所示:
举个简单的例子,比如我们要做大促的优惠活动,同一店铺商品购满 500 元,可以使用 10 元店铺内优惠券,同时还可以使用 10 元全站优惠券。
这样一个需求最终拆解下来,可能需要店铺应用支持多优惠活动的叠加,同时下单应用和购物车应用在计算价格时也要设定相关的优惠逻辑,这一个需求可能就拆出三四个功能点。
这样做的好处就是,从一开始的需求管理维度,就确定了最终多个应用联调、测试以及最终发布的计划和协作方式,从而就会让我们明确同一个项目环境中到底需要部署哪些应用,这些应用的发布顺序怎样安排。
比如,如果 A 应用依赖 B 应用,那么 B 应用就必须优先发布。所以,上述这个过程对于项目进度管理、团队协作以及最终的发布计划都是有帮助的。
讲到这里,你是不是又进一步感受到了运维的重要性呢?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(2)

  • 唐😊 木木
    分支开发模式看起来很像gitflow模式少了devlope和hotfix分支。直接把master当dev分支,拉出的特性开发分支然后merge到release分支,release在经过测试合并到master分支。不知道这么看对不对。
    2019-06-14
  • 森馫鑫
    系统功能一直是按固定版本发布,因此基本都是选用了gitflow开发模式,不过对于新系统更加追求小步快走,在这个时候会用主干开发模式。
    2018-07-15
收起评论
2
返回
顶部