语义版本控制和持续部署

Posted 2023-03-07

【中文标题】语义版本控制和持续部署

【英文标题】：Semantic Versioning & Continuous Deployment

【发布时间】：2017-04-23 22:30:51

【问题描述】：

大约一个小时前，墨菲踢了我的 a$$。

上下文：

我最近加入了一个新雇主，该产品在依赖关系方面已经过时了，Angular 1.2.x、Angular-UI 0.12.0 等...

这是我工作过的第一个负责日常构建以生产产品等的雇主。（以前我只在所谓的大公司工作过，周转速度要慢得多）我最初的部分任务是升级我可以的依赖项。因此，今天早上早些时候，我们与一些开发人员进行了一次水冷式谈话，讨论了为什么我们所有的凉亭依赖项都被硬编码为特定版本。

两种思想流派是：

硬编码版本显然提供了 100% 的安全性，因为版本不能动态跳转，但缺点是如果有人不主动更新，我们将再次落后。 我认为语义版本控制为我们提供了某种形式的安全性（再加上具有多个暂存环境），并且应该足以让 Angular 设置为^1.5.9。

引自语义版本文档：

次要版本 Y (x.Y.z | x > 0) 如果是新版本，则必须递增，向后 公共 API 中引入了兼容的功能。一定是 如果任何公共 API 功能被标记为已弃用，则递增。 如果有实质性的新功能或改进，它可能会增加 在私有代码中引入。它可能包括补丁级别 变化。当次要版本为 0 时，补丁版本必须重置为 0 递增。

问题：

今天早上早些时候，我们部署到暂存区，一切看起来都很好，然后我们在一个小时左右前部署到生产环境中...... BOOM

问题是 AngularJs 从 1.5.9 更改为 1.6.0。我在迁移文档 (migrate 1.5 -> 1.6) 中看到了这一点：

您可能还会注意到，此版本的版本比平时更长 重大更改列表。不要让这让你灰心丧气，因为 它们中的大多数都是很小的——通常不会影响真实的 应用程序。这些重大更改是必要的，以便：

问题：

我的断开连接在哪里？ ...或者语义版本文档只是我一直以来的一种错误的安全感？

人们如何处理这些情况？人们是否在任何现实世界的解决方案中使用自动依赖升级（如果这对某些人来说非常明显，请原谅），就我而言，构建通过暂存并在生产中中断的事实实际上更令人担忧。

（我之所以这么问是因为对小幅增量更新的恐惧现在又回来了，而且比以往任何时候都更加强烈，我不确定我是否同意这一切的情绪......） em>

【问题讨论】：

在版本 2 之前，Angular 不遵循语义版本控制。见angularjs.blogspot.co.za/2016/10/…。

@Brett... 我想我必须再次从中学习，假设是所有问题的根源。 ://

【参考方案1】：

看起来很简单，如果他们做出重大更改，他们应该将其提升到 2.0.0。他们没有进行语义版本控制。并非所有项目都使用 X.Y.Z。样式版本正在进行语义版本控制。

尝试在您的测试和暂存环境中以自动化的方式了解它是如何“蓬勃发展”的。不要害怕前进，它必须在某个时候完成，我宁愿更频繁地一步一步地移动，而不是像完全手动的过程那样突然升级许多版本。

【讨论】：

除此之外，不要在生产部署期间进行自动包升级。您总是希望完全部署经过测试的内容。如果我误解了您的情况并且您确实部署了测试的内容，那么您需要更好的测试。