72 | 发布单元与版本管理
许式伟
你好,我是七牛云许式伟。
前面我们在 “68 | 软件工程的宏观视角” 一讲中谈到:一个软件工程往往是生命周期以数年甚至数十年计的工程。对于传统工程,我们往往把一个工程同时也称之为项目,项目工程。但软件工程不同,虽然我们平常也有项目的概念,但软件工程并不是一个项目,而是无数个项目。每个项目只是软件工程中的一个里程碑(Milestone)。
这意味着软件工程终其完整的生命周期中,是在反复迭代与演进的。这种反复迭代演进的工程,要保证其质量实际上相当困难。
源代码版本管理
怎么确保软件工程的质量?
很容易想到的一个思路是,万一出问题了,就召回,换用老版本。
这便是版本管理的来由。当然,如果仅仅只是为了召回,只需要对软件的可执行程序进行版本管理就好了。但我们如果要进一步定位软件质量问题的原因,那就需要找到一个方法能够稳定再现它。
这意味着我们需要对软件的源代码也进行版本管理,并且它的版本与可执行程序的版本保持一一对应。
但实际上这事并没有那么简单。
从软件的架构设计可知,软件是分模块开发的,不同模块可能由不同团队开发,甚至有些模块是外部第三方团队开发。这意味着,从细粒度的视角来看,一个软件工程的生命周期中,包含着很多个彼此完全独立的子软件工程。这些子软件工程它们有自己独立的迭代周期,我们软件只是它们的 “客户”。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》,新⼈⾸单¥68
《许式伟的架构课》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(11)
- 最新
- 精选
- ecareyu许老师,关于上线后出错,版本回退有个问题一直困惑着我,就是有时候一个新版本可能会有表字段的变更,这个时候回退回去后,肯定会出现找不到字段的报错,这个时候怎么解决?
作者回复: 把数据库变更做得更加鲁棒一些,前后版本维持向前兼容。比如要改变某字段语义从A改为B。一般我们不建议直接改字段,而是新增一个字段,在一段时间内双写这两个字段,直到升级完成一段时间后才删除老字段。
13 - Geek007许老师思维缜密,很多文章读起来仿佛是一个大的switch case,基本所有的条件都考虑到了,同时又能够把握主次。非常佩服,是我的榜样。 版本管理看似简单但其实复杂。有两个问题: 1. 对go mod了解不深,想了解go mod 对外部依赖的管理的层次,比如发布单元依赖外部包A,但其实外部包A又依赖外部包B, B 又依赖C...go mod会把这个依赖的chain: A->B->C都管理起来么? 2. 接上面的问题,如果外部包B里依赖了的外部包C没有指定版本,用的是latest的版本,怎么能够及时发现和避免呢? 3. 想了解七牛云如果管理开源软件,如果开源软件有bug,是维护一个本地版本修复bug,还是说会直接在开源社区提交修复,等开源社区的修复发布后再正式的把新的开源软件打包到产品里? 再次感谢!
作者回复: 1、支持的 2、在Go mod中,就算指定的是latest,对于具体的一个版本,也是依赖于具体版本,也不是latest。 3、两者都有。趋势是后者,直接开源版本就是内部版本。
5 - Jeyrce.Lu(1)源代码的版本管理——git (2)运行环境的版本管理——容器 (3)api的版本管理——版本号 (4)模块的版本管理——包管理工具4
- Aaron Cheung补打卡 很受益的文章3
- 亢(知行合一的路上)只读的设计,增加了系统的确定性,也就可以把精力放在不确定的地方。 需要明确系统的哪部分是只读的,哪部分是易变的,只读的部分降低了系统整体的复杂度。1
- 靠人品去赢其实容器化很方便,但是这种serverless带来的就是如何监控等一些新问题也挺头疼的。1
- 霜花香似海多模块开发,需要做好模块边界上下文问题。只要是架构师确定了各个边界之间的上下文问题,也就统一了版本兼容,或者说统一了各个模块之间的标准了。不晓得这么说对不对1
- ifelse学习打卡归属地:浙江
- 亢星东接口API版本这个用过
- 小炭还是不太明白只读设计,能否举个例子说明一下好处呢2
收起评论