跳到主要内容

1.3-版本控制

Create by fall on 29 Nov 2023
Recently revised in 24 Oct 2025

版本控制​

版本控制公认的原则：语义化版本 2.0.0 原则

破坏性改动发布​

将破坏性改动分批发部

保证可用的基础上，采用 deprecate -> opt-in -> remove

先添加废弃标签，内置报错，最后移除

生态考虑​

生态库（基础设施）需要有更加合适版本策略生态

发布预览版针对一些框架维护者，发布正式版要关注普通用户

框架用强类型：typescript

对开发体验进行优化

对文档进行优化

多人协作​

  • 多人协作时，对于版本控制需要更敏感
  • 原子化提交，确保改动范围小
  • 多次同步 git 代码，保证人与人之间代码差异尽可能的小，及时对问题做出反应
  • 按照小改动进行提交

版本迁移示例​

示例：Vue2 升级到 Vue3

此时可以同时做到：

  • node 18 以上
  • 废弃 CommonJS API

同时摒弃多种类型的技术债

版本类型​

灰度发布​

灰度发布：Gray Release

将新版本的部分流量引导到新的发布版本上，可以用于测试、验证和用户反馈。相较于蓝绿部署，灰度发布可以更细粒度地控制新版本的流量，以降低部署风险。例如，可以将新版本的 1% 流量引导到新的发布版本上，然后逐渐增加流量的比例，直到全部流量都切换到新版本上。

金丝雀发布​

金丝雀发布：Canary Release

类似于灰度发布，但是引导流量的比例更小，例如只有 0.1% 的流量。金丝雀发布主要用于验证新版本的性能和稳定性。如果新版本发生故障，只会影响到极少量用户，不会对所有用户产生影响。

一般会用于版本新功能前瞻

彩色发布​

在金丝雀发布的基础上，引入自动化的测试和分析，以决定是否要将流量全部切换到新版本上。例如，可以使用自动化的性能测试工具，比较新旧版本在不同负载下的性能表现，或者使用自动化的异常检测工具，发现新版本中出现的问题并自动回滚。

蓝绿部署​

Blue-green deployment

在部署新版本之前，先将旧版本保留并运行，等新版本运行稳定后再将流量切换到新版本上。这种部署方式可以确保应用程序在更新过程中保持可用性和稳定性。

滚动发布​

滚动发布：Rolling Release

将新版本逐步部署到生产环境中，通过逐步增加新版本的实例数量来实现平滑过渡，同时也能够保证系统的稳定性和可用性。与蓝绿部署相比，滚动发布的风险更低，因为只有一部分流量会受到影响，并且可以随时停止部署并回滚到之前的版本。