72 | 发布单元与版本管理

许老师思维缜密，很多文章读起来仿佛是一个大的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）源代码的版本管理——git （2）运行环境的版本管理——容器 （3）api的版本管理——版本号 （4）模块的版本管理——包管理工具

补打卡 很受益的文章

只读的设计，增加了系统的确定性，也就可以把精力放在不确定的地方。 需要明确系统的哪部分是只读的，哪部分是易变的，只读的部分降低了系统整体的复杂度。

其实容器化很方便，但是这种serverless带来的就是如何监控等一些新问题也挺头疼的。

多模块开发，需要做好模块边界上下文问题。只要是架构师确定了各个边界之间的上下文问题，也就统一了版本兼容，或者说统一了各个模块之间的标准了。不晓得这么说对不对

学习打卡

接口API版本这个用过

还是不太明白只读设计，能否举个例子说明一下好处呢

多人协作的标准化其实是引发这个问题的原因：当前就碰到。1个项目开发工期偏紧，直接就多个团队同时参与，各自团队内部的开发标准又不一样，开发完成进入测试改错的环节时就发现一堆标准不一致的问题-直接导致部分代码重写。 如何在发布单元和版本控制中解决当下问题：这是将来相关项目时将会碰到的问题。多个小团队一起迭代发布就明显碰到了版本管理的问题。