【免费】《持续交付2.0+业务引领的DevOps精要》_乔梁1

需积分: 0 154 浏览量 2022-08-03 16:37:45 上传评论 1 收藏 19.16MB PDF 举报

资源详情

资源评论

资源推荐

8.4

分支策略的选择

129

应的发布质量标准后，才能发布该版本。前后两次发布之间的时间间隔井没有明确的规

定，而是在根据新版本要求的特性集合开发完成并达到发布标准后，对所需时间进行评

估确定的。

这种模式是最古老的发布方式，其目标是：针对

一

个特定版本，在确定了版本中的特

性数量和质量标准以后，再估计版本交付周期，这相当于固定了特性数量和质量要求，那

么团队可能交付的时间点也就相对固定了。

项目制发布的好处在于

：

可以确切地知道每个版本包括哪些具体功能，有利于商业套

装软件的售卖模式（卖版本副本和授权，收取软件维护费用，当包含有新功能的版本发行

后，再向客户收取新版本的升级费用）。同时，这也符合人们的安全生产习惯，即绝对不

能把未完成的功能带到即将发布的版本中。

不足之

处

在于：通常项目整个交付周期较长，参与人员众多。在版本研发周期中由于

某些原因导致需求变更（如增加需求、修改原有需求实现方式或者进行需求置换）时，需

要重新确定项目的交付时间，这会影响那些原本能够按期交付的需求。因为，这种项目制

发布模式需要等所有需求全部实现完成后才能

一

起发布。

发布火车

模

式

发布火车模式常见于大型套装分发类软件。大型传统软件企业通常有多条产品线，各

产品线之间存在非常复杂的相互依赖关系。为了能够使各产品线协同发布，这些企业通常

会为每条产品线都制订好每个版本的发布周期，即每个版本都像

一

列火车，事先计划好什

么时间点发车。为了能够准时发布，要求所有参与到该版本开发的团队必须对齐该版本的

各个开发阶段。这种严格的时间一致性要求是因为该产品线的时间变更会引起其他产品线

的变更，而这些更改很可能影

向共享的系统集成测试环境的分配。在大多数情况下，由于

计划和集成依赖关系，因此发布火车设置为季度交付窗口，但通常不会超过

个月。

当公布这种火车时间表时，发布管理团队通常与负责各产品开发的团队进行提前沟

通，讨论要发布哪些内容，有时甚至需要提前几个月的时间，井将其结论发布在企业版本

表中，类似于图

中

LiberOffice

的发布火车的时刻表。提前几个月制订发布火车的时间

表，目的是让各种业务和技术部门有足够多的时间进行预计划，以便做出依赖和影

向的相

关评估工作。

制订发布计划的活动是

一

个非常正式和结构化的过程，需要一些格式化数据，以确保

参加发布火车的团队能够对正式发布的可行性做出判断。这些数据包括发布详细信息（相

对标识、名称、部署日期、风险级别、发布类型·企业、计划或投资组合）、整个生命周期

中各个阶段及预定日期（如图

8-18

所示）、每个阶段要完成的活动和任务、里程碑时间和质

量要求以及负责管理发布火车的主要负责人。

130

第

章

利于集成的分支策略

Ubr

副何＇＂

UbnoO

何

6 0

晤。俯

S.4

Ubr

哩。俯

，曹。

ffice

S.2

LibreOffice

发布

UbreOffico

5.1

υbr

哩。俯

5.0

Ubr

回

ffice4

UbreCffi

ce 4 3

noOffl

ce 4. 2

Ubr

哩。

fflce

晤。何区

’e

4 O

UbnoOffke

3 6

UbreOI

由ε.

3.5

UbnoO

甜

3.•‘

Ubn!O

甜

3.3

到

21112

2014

211

。

2017

2018

甜

202

Old

verso

幅

Siii • fresh

End

Life

民

阳

re\ler9on

Updated

却

18·05·2'l

图

LiberOffice

的

发

布火

车的时刻表

6.o

release

日

asic

dates

。

the

initial

and

bugfix

releases

Release

Freeze

Publishing

＋－一－－

自由－节”’－－－

－－一－－』－』－町』－一－－一－响『【归属”－

6.0.0

(

，

由

week

2) Week 42 , Oct 16, 2017 - Oct 22, 2017 , Week 5 , Jan 29, 2018 - Feb 4, 2018

川

一一－

ek6

，品

201

汇

Feb11,2010

阳

JS:

Feb

王

20l8

-:fe

山

2010

6.0.2

6.0.3

6.0.4

6.0.5

6.0.6

6.0.7

n d

。

Life

Week

Feb 19, 2018 - Feb 25, 2018

Week

, Mar 12,

2018-

Mar 18, 2018

Week

16,

Apr

日，

2018

- Apr 22, 2018

Week 22 , May 28, 2018 - Jun 3, 2018

Week

28,

Jul

2018 - Jul 15, 2018

Week

40,

Oct 1, 2018 - Oct 7, 2018

」一－

Week 9 , Feb 26, 2018 •

Mar4

, 2018

十

Week 14 ,

Apr2

, 2018

-Apr

8, 2018

中

甲

一

－一一

Week 19 , May

2018-

May 13, 2018

喃←一－一句』－一一一一一一｝－

』－一一一一－

Week 25 , Jun 18, 2018 -

Jun

饵

，

2018

Week

, Jul

』

2018

”

Aug

2018

Week 43 , Oct 22, 2018 - Oct 28, 2018

November2

日，

2018

图

-1

LibreOffice

发布火车的

时间

表

该模式

的好处在

于

：对企业

来

说，可以

通过并

行

多列

火

车的方式，将

突发需求

排入某

一

列发布火车

。

用户可以提前体验最新产品版本所提供的新特性，而不必影响原有生产线

上正在使用的旧版本。体验之后再决定是否将其应用于自己的生产环境中。即便已经决定

将这个新版本用于自己的生

产

环境中，也可以

等

到这个新版本成熟稳定之后再这么做。在

这种

模

式下，如

果

参与团队的人数较

多

，沟通协调成本就会较高。

8.4

分支策咯的选择

131

城

际快线模式

城际’快线模式是指在发布模式

三

要素中，固定其中的时间和质量两个维度，且时－间周

期相对较短（女口

一

周，甚至一天或更少），针对那些在发布时间点已达到固定质量标准的

特性进行

一

次发布。它与发布火车模式的区别在于两点：

一

是发布周期间隔较短，通常在

两周以内；二是负责特性开发的团队可以自己选择搭乘

lg]~

列城际快线，而不必提前很长时

间确定下来。

这种模式常见于提供互联网服务或

Saas

服务的软件公司。其好处在于减少了团队及角

色之间的协调成本。因为每个人都事先知道每次发布的具体时间点，所有工作任务都可以

按这个时间点提前进行协调。而且，即使某个特性没有及时赶上最近的一次版本发布，团

队也确切地知道这个特性是否可以在下

一

次发布时间点对外发布。例如，

Facebook

的

Web

网站在

年的部署推送频率已达到每天发布两次，每周发布

一

次大版本。其分支发布策

略如图

-1

所示。

release to production (pub I

）

：

固

comm

川

hat

：

固

branch

吨

cut

a commit to go live before n

branch cut

食

时

ease

ff : going

…

叫

因

branch rename

囚

叩。

erry

pick)

图

-19

Facebook

2013

年的分支发布策略

每

个周日从主手上拉

一

个发布分支，自动化测试验证通过以后，即在公司内部人员开

放（在公司内访问，直接重定向到

latest.face

book.com

）

。运行过程中如果出现缺陷，可以

在主干上修复，然后分捡到（

CherryPick

）发布分支上。发布分支上的代码每天两次更新

latest.facebook

com

，供公司员工开发使用。如果版本稳定，就向外部用户发布，同样是每

天两次。据报道，自

2017

年开始，

Facebook

公司网站的分支发布策略已经从

一

天发布两次

的“主干开发，分支发布”模式改变为平均每天发布

到

次的“主干开发，

主干

发布”

模式。

132

第

章

利于集成的分支策略

这种城际快线模式的优点有两个，

一

是每个人都非常清楚各个时间点，二是更加聚焦

于生产质量。

当然，

也

有其不足之处，由于发布频率较高，因此未完成功能的代码

也

会

一

同发布出

去，对于代码提交质量的要求较高，需要强大的质

量

基础设施保证。

使用这种城际快线模式，间隔多长时间发出

一

趟合适呢？我的建议是

：

在不影

向用户

体验、不增

加

成本且合规的前提下，让发布周期尽可能缩短到令你感到有些紧张的节奏。

例如，原来每个月发布一个版本，现在可以把两周作为

一

个目标。

8.4.2

分支策略与发布周期的关

系

分支策略与版本发布周期之间有

一

定的相关性，如图

所示。通常，软件开发周期

极长的“项目制”团队和软件发布频率极高的“城际快线式”团

队

会使用“主干开发，主

干发布”的分支策略。而次之的团队会使用“主干开发，分支发布”的分支策略。它们之

间的团队会使用“分支开发、主干发布”的分支策略。当然，这并不是绝对的，其中会有

很大的重叠部分

，

通常会受团队成员人数、产品架构和质

量

保障基

础

设施

状

况的影

响

。

主干开发

，

主干发布

主干开发，主干发布

主干开发，分支发布

分支开发，主干发布

个月

周

天

发布周期

图

8-20

分支策略与发布周期的关系示意图

项目制发布模式不会消失。毕竟每个新产品在完成第

一

个可推广的

1.0

版本前，都需

要这样一

个

首次启动过程。目前

仍

旧有很多传统

企业采用项目

制

发布模式。

城际快线模式是“持续交付

2.0

”所提倡的模式。越来越多的企业开始使用这种城际

快线模式。即使在那些目前的版本发布周期较长的企业中，也常常在项目

制

发布模式中套

用城际快线模式，即在项目周期内加入固定时间的选代

，

井要求在每个选

代

结束时都能得

到可交付状态的产品。这里的可交付状态是指软件可以正常运行，且已完成的软件特性达

到发布质量标准，并非商业

化

发布。

一

般来说

，

当发布周期缩短到

一

定程度后，主干开发模式更具有优势，因为分支开发

模式的合并成本会成为短周期发布的障碍

。

如果发布周期短于两周，软件团队就应该毫不

犹豫地转向“主干开发模式”。

剩余31页未读，继续阅读

评论收藏

内容反馈

好运爆棚

粉丝: 29
资源: 342

《持续交付2.0+业务引领的DevOps精要》_乔梁1

评论0

最新资源

《持续交付2.0+业务引领的DevOps精要》_乔梁1

评论0

藏经阁-持续交付2.0 ——业务引领的DevOps.pdf

持续交付指导文件，包含DevOps持续交付工作流程介绍以及相关的工具

【《持续交付2.0(DevOps)-乔梁》最新版梳理结构脑图】

Continuous Delivery(持续交付英文原版)

持续交付成熟度模型V12中文版.pdf

持续交付最佳实践

持续交付成熟度模型 V1.2

百度持续交付体系与最佳实践大解密

基于kubernetes+docker+jenkins的DevOps实践

HCIP-Cloud+Service+DevOps+Engineer+V2.0第一章.xmind

HCIP-Cloud+Service+DevOps+Engineer+V2.0第二章.xmind

2019马哥全新Linux云计算+安全+Devops+K8s高薪运维工程师课程大纲v11.0(最新版)1

Pro Continuous Delivery With Jenkins 2.0 无水印pdf

携程无线持续交付平台.pdf

gitlab+harbor+sonarqube+jenkins+maven实现Devops

陈展文-建立多层度量体系助推DevOps落地_脱密版.pdf

DevOps_java_devops_

陈展文-建立多层度量体系助推DevOps落地_脱密版.zip

The+DevOps+2.2+Toolkit_Self-Healing+Clusters-Packt+Publishing(2018).epub

了解如何使用 Amazon Spot 实例在 EKS 之上部署游戏服务器 的devops示例_C语言_代码_下载

DevOps_with_OpenShift.pdf_devops_

深圳Devops峰会_20181102

DevOps_with_OpenShift.pdf

基于Spring boot 2.0+ 脚手架重构微服务系统，CI、DevOps、Redisson

DevOps精要业务视角读后感.docx

DevOps_in_Practice.ppt

最新版ISO/IEC 27001:2022、ISO 27002:2022中英文合集

Goby红队版-win-x64-2.4.7版本

最新资源

了解如何使用 Amazon Spot 实例在 EKS 之上部署游戏服务器的devops示例_C语言_代码_下载