请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 243|回复: 0

发布工程的基本思想之三(测试、打包、部署)

[复制链接]
发表于 2020-12-5 23:59:22 | 显示全部楼层 |阅读模式
分支
所有的代码都默认提交到主分支上(mainline)。然而,大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支,新分支的内容永远不会再合并入主分支。Bug 修复先提交到主分支,再cherrypicking到发布分支上。这种方式可以避免在第一次构建之后,再引入主分支上的其他的无关改动。利用这种分支与cherry picking 的方法,可以明确每个发布版本中包含的全部改动。
- R. m. H4 Z. ?4 l+ ^$ Q- ~% F
0 D" J2 c: f( }/ U. R$ e8 @/ c$ u, b
测试
一个持续测试系统会在每个主分支改动提交之后运行单元测试,这样我们可以快速检测构建错误和测试错误。建议使用项目中定义的构建目标及测试目标的执行结果来决定是否发布某个版本。同时建议使用最后一个测试全部通过的软件版本来进行最新的发布。这些方法可以降低在真正发布时由于主分支上其他无关改动造成问题的几率。
+ p. @' X4 A2 G# `

* b/ i2 [4 A5 S1 q4 T0 [4 D
在发布过程中,我们会使用该发布分支重新运行全部单元测试,同时为测试结果创建审核记录。这一个步骤非常重要,因为如果一个发布过程需要cherry picking,发布分支可能会包含主分支上不存在的一个代码版本。我们必须确保在发布分支上全部测试确实通过。
# @9 C0 e" v" b3 R# a! V9 A
0 }  I& s+ G1 {/ ?
为实现持续测试系统,我们使用一套独立的测试环境来在打包好的构建结果上运行一些系统级别测试。这些测试可以从 Rapid 网站上手工启动。
. P8 U- U3 s; @6 J+ j2 @
: Q7 r6 j4 P: \7 k5 h$ O
打包
软件通过Midas PackageManagerMPM)系统分发到生产机器上。MPM基于Blaze 规则中列出的构建结果和权限信息构建 MPM包。每个包有固定名称(如search/shakespeare/rontend),记录构建结果的哈希值,并且会加入签名以确保真实完整性。MPM 同时支持给某个版本的包打标签。Rapid也会加入一个构建ID 标签,这样某个包可以用名字和这个标签来唯一识别。
6 X, p2 B  {3 ?* o1 ]8 |2 v9 r
) F2 V2 Y2 N6 r7 u9 C/ {8 N% w2 X' b
我们可以给某个MPM包加标签,标记该MPM包在整个发布过程中的位置(如devcanary production等)。如果将某个现有标签应用到新包上,这个标签会自动从原来的包上移除。例如,如果一个包标记为 canary,之前的 canary包上的标签就被自动去掉了,后续安装 canary 版本的包的人会自动使用最新的包版本。
. v% D$ p0 T3 D  p5 F! J. E: P- Z* A* c




上一篇:谷歌SRE发布工程哲学第二部分
下一篇:谷歌SRE发布工程的Rapid 系统

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-22 05:46 , Processed in 0.151153 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表