许式伟的架构课
许式伟
七牛云CEO
立即订阅
21081 人已学习
课程目录
已完结 87 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (19讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
桌面开发篇 (14讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (13讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
服务治理篇 (10讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (11讲)
57 | 心性:架构师的修炼之道
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式:文本处理
66 | 架构老化与重构
67 | 架构思维篇:回顾与总结
软件工程篇 (10讲)
68 | 软件工程的宏观视角
69 | 团队的共识管理
70 | 怎么写设计文档?
71 | 如何阅读别人的代码?
72 | 发布单元与版本管理
73 | 软件质量管理:单元测试、持续构建与发布
74 | 开源、云服务与外包管理
75 | 软件版本迭代的规划
76 | 软件工程的未来
77 | 软件工程篇:回顾与总结
不定期加餐 (8讲)
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
加餐 | 如何做HTTP服务的测试?
加餐 | 怎么保障发布的效率与质量?
用户故事 | 站在更高的视角看架构
加餐 | 实战:“画图程序” 的整体架构
结束语 (1讲)
结束语 | 放下技术人的身段,用极限思维提升架构能力
免费
许式伟的架构课
登录|注册

72 | 发布单元与版本管理

许式伟 2020-01-10
你好,我是七牛云许式伟。
前面我们在 “68 | 软件工程的宏观视角” 一讲中谈到:一个软件工程往往是生命周期以数年甚至数十年计的工程。对于传统工程,我们往往把一个工程同时也称之为项目,项目工程。但软件工程不同,虽然我们平常也有项目的概念,但软件工程并不是一个项目,而是无数个项目。每个项目只是软件工程中的一个里程碑(Milestone)。
这意味着软件工程终其完整的生命周期中,是在反复迭代与演进的。这种反复迭代演进的工程,要保证其质量实际上相当困难。

源代码版本管理

怎么确保软件工程的质量?
很容易想到的一个思路是,万一出问题了,就召回,换用老版本。
这便是版本管理的来由。当然,如果仅仅只是为了召回,只需要对软件的可执行程序进行版本管理就好了。但我们如果要进一步定位软件质量问题的原因,那就需要找到一个方法能够稳定再现它。
这意味着我们需要对软件的源代码也进行版本管理,并且它的版本与可执行程序的版本保持一一对应。
但实际上这事并没有那么简单。
从软件的架构设计可知,软件是分模块开发的,不同模块可能由不同团队开发,甚至有些模块是外部第三方团队开发。这意味着,从细粒度的视角来看,一个软件工程的生命周期中,包含着很多个彼此完全独立的子软件工程。这些子软件工程它们有自己独立的迭代周期,我们软件只是它们的 “客户”。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(5)

  • 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、两者都有。趋势是后者,直接开源版本就是内部版本。

    2020-01-10
    1
  • Aaron Cheung
    补打卡 很受益的文章
    2020-01-12
  • 靠人品去赢
    其实容器化很方便,但是这种serverless带来的就是如何监控等一些新问题也挺头疼的。
    2020-01-10
  • 霜花香似海
    多模块开发,需要做好模块边界上下文问题。只要是架构师确定了各个边界之间的上下文问题,也就统一了版本兼容,或者说统一了各个模块之间的标准了。不晓得这么说对不对
    2020-01-10
  • leslie
    多人协作的标准化其实是引发这个问题的原因:当前就碰到。1个项目开发工期偏紧,直接就多个团队同时参与,各自团队内部的开发标准又不一样,开发完成进入测试改错的环节时就发现一堆标准不一致的问题-直接导致部分代码重写。
    如何在发布单元和版本控制中解决当下问题:这是将来相关项目时将会碰到的问题。多个小团队一起迭代发布就明显碰到了版本管理的问题。
    2020-01-10
    1
收起评论
5
返回
顶部