49 | 发布、升级与版本管理
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
今天我们探讨服务治理的第一个环节：发布与升级。
在应用开发工程师完成一个版本的迭代后，他们交付的是软件新版本的源代码，这些代码存储在源代码仓库中。
一次正常的发布过程，大体分为这样几个典型的步骤：
构建：从源代码仓库检出源代码，编译出对应的目标文件，也就是我们新版本的软件。
测试：对新版本的软件进行测试，以确认软件的质量符合期望。
打包：将新版本的软件及其执行所需的相关文件，比如配置文件，一起打包并记录相应的版本号。
部署：将打包好的新版本更新到线上环境。为了保证线上环境的质量，更新过程往往需要灰度，而不是一步到位直接全面切换到新版本。
当然，并不是所有的升级都是发布新版本的软件。有时候我们仅仅只是进行配置变更，也就是修改线上的配置参数。配置参数可能存在于软件配套的配置文件中，也可能存在于线上的某个配置数据库。
整个发布与升级的过程，大体可以用下图来表示。
从上面我们可以看出，发布是一个具备很强的事务特征的工作，过程很复杂。不仅如此，发布工作的心智负担也很大。所有 SRE 都应该牢牢记住以下这句七字箴言：
变更是故障之源。
我们应该怎么做，才能彻底解决发布与升级的问题？
让我们从 “工程师思维” 的角度，用系统化、产品化的思维来考虑这样一个复杂事务。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
发布、升级与版本管理是软件开发中至关重要的环节。文章首先介绍了发布过程的典型步骤，包括构建、测试、打包和部署，以及配置变更。作者强调了发布过程的复杂性和事务特征，以及变更可能带来的故障。接着，文章提出了发布哲学的核心概念：密闭性与可重复性。作者强调了发布过程的自动化和自服务化，以及追求频繁发布的重要性。此外，文章还强调了质量保障和流程尊重在发布过程中的重要性，以及配置管理在发布过程中的作用。最后，文章鼓励读者从系统化的思维角度来解决发布与升级问题。 总的来说，本文强调了发布与升级的复杂性和重要性，提出了一系列解决问题的方法和理念，对于需要深入了解发布与升级的读者来说，是一篇具有指导意义的文章。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(18)
- 最新
- 精选
- Geek_88604f在配置管理中老师提到:‘’将配置管理与物理硬件环境彻底进行解耦，这也是数据中心操作系统（DCOS）在做的事情。本质上，你也把它理解成是将高频的配置变更支持做到应用逻辑中，只不过这由一个基础平台来实现罢了。‘’对于这一点不太理解，配置中心已经将服务的配置管理做的很好了，为啥还会有‘‘将配置管理与物理硬件环境彻底进行解耦’’的需求呢？这么做的优势是什么？
作者回复: 我们希望升级才需要配置变更，硬件环境改变不需要配置变更。这样的话，配置中心就需要针对集群的逻辑视图，而不是物理视图。
2019-11-067 
tingye“SRE 需要非常了解某个新发布中包含的所有具体改动，以便在发布出现问题时可以更快地进行在线调试”——发布出现问题还是应该先回退版本，恢复服务吧，调试定位问题感觉应该业务开发来做，SRE通常也无能为力，如果是devops就没什么可推脱了作者回复: 是这样，出问题首先第一要务应该先恢复服务，但是有可能的话还应该尽可能保留现场，所以把流量切走是更好的做法。
2019-10-154
Aaron Cheung七牛云项目发布是sre还是软件开发工程师自己发布呢作者回复: sre
2019-10-153- 虚竹老师好像漏了升级时另一个容易引起问题的地方，数据库表结构的变更，这部分应该也需要管理起来的吧？
作者回复: 这块的确至关重要，且不是版本管理能够解决。它独立于版本管理，但是的确会对版本管理有所影响。
2020-03-0432 - haike老师，我们目前想通过jenkins自动化构建完成后，修改软件的版本号。但是需要配置的git 账户需要有admin 权限，这样的方案又有较大的风险，有什么好的方案吗，期待你的回复
作者回复: 日构建对仓库是只读的，要admin肯定不合理
2021-11-03 
憶海拾貝从密闭性角度看,使用vendor目录保存Go项目的依赖,并提交到VCS维护,也是好的做法咯?作者回复: 是这样，只不过这样没有去做版本管理，只是给版本管理提供了便利。从这一点看go对版本管理的支持思路是有很大变化的。
2021-03-05
沉睡的木木夕“方式一是引入配置中心，把有些高频的配置变更支持做到应用逻辑中去” 这种是说类似于携程的 apollo 的么？把多个系统的配置统一管理，可以做到热更新和热备，但是后面紧接着说“服务发现”，这个说法我感觉不是很正确啊 还有方式二的说法“方式二是将配置管理与物理硬件环境彻底进行解耦...本质上，你也把它理解成是将高频的配置变更支持做到应用逻辑中，只不过这由一个基础平台来实现罢了”这个不就是方式一么？作者回复: 1、配置中心不只是可以做服务发现，服务发现可以用“配置中心”这个机制。 2、方案二与方案一本质相同，只是方案一是应用程序会感知，第二种方案应用程序不感知。
2020-03-08
谢晞鸣变更是故障之源，变更要做到可监控，可应急，可灰度。这个里面有很大的挑战，每个批次变更完之后，要确保对应的监控是精确的，实时的，有问题能及时发现，最好是自动检测的（系统性的比较简单，业务层的监控比较难），确认没问题后继续。作者回复: 是的
2020-01-27
Eternal将配置管理与物理硬件环境彻底进行解耦，这也是数据中心操作系统（DCOS）在做的事情。本质上，你也把它理解成是将高频的配置变更支持做到应用逻辑中，只不过这由一个基础平台来实现罢了。 讲的是将配置打包到douker镜像中吗？作者回复: 讲的是容器调度
2019-11-23
风清扬老师，发布升级版本管理后面会有详细讲解吗？光讲解原理，没实际操作，很难有具体的收获。2019-10-1515
收起评论
