语义版本控制和持续部署
Semantic Versioning & Continuous Deployment
Murphy 大约一个小时前踢了我的 a$$。
上下文：
我最近加入了一个新雇主，产品在依赖项方面相当过时，Angular 1.2.x、Angular-UI 0.12.0，等等...
这是我工作过的第一个雇主，每天进行产品构建等工作（以前我只在所谓的大型公司工作过，周转速度慢得多）我最初的部分任务是尽可能升级依赖项。因此，今天早上早些时候，我们与一些开发人员就为什么我们所有的 Bower 依赖项都硬编码到特定版本进行了一次水冷式谈话。
两个思想流派是：
- 硬编码版本显然提供了 100% 的安全性，因为版本不能动态跳转，但缺点是如果有人不主动更新我们就会再次落后。
- 我认为语义版本控制为我们提供了某种形式的安全性（加上具有多个暂存环境），并且它应该足够好，比如说，让 Angular 设置为
^1.5.9.
引自语义版本文档：
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated.
It MAY be incremented if substantial new functionality or improvements
are introduced within the private code. It MAY include patch level
changes. Patch version MUST be reset to 0 when minor version is
incremented.
问题：
今天早上早些时候，我们部署到暂存区，一切似乎都很顺利，然后我们在大约一个小时前部署到生产环境……BOOM
问题是 AngularJs 从 1.5.9 更改为 1.6.0。我在迁移文档 (migrate 1.5 -> 1.6) 中看到已注意到这一点：
You may also notice that this release comes with a longer-than-usual
list of breaking changes. Don't let this dishearten you though, since
most of them are pretty minor - often not expected to affect real
applications. These breaking changes were necessary in order to:
问题：
我的断开连接在哪里？ ...或者语义版本文档只是我一直以来的一种虚假的安全感？
外面的人是如何处理这些情况的？人们是否在任何现实世界的解决方案中使用自动依赖升级（如果这对某些人来说非常明显，请原谅），对我来说，构建通过了暂存，并在生产中中断的事实实际上更令人担忧。
（我问的原因是因为对小增量更新的恐惧现在又回来了，而且比以往任何时候都更强烈，我不确定我是否同意这一切的情绪.. .)
看起来很简单，如果他们进行重大更改，他们应该将其升级到 2.0.0。他们没有进行语义版本控制。并非所有项目都使用 X.Y.Z。样式版本正在进行语义版本控制。
尝试在您的测试和暂存环境中以自动化方式了解这 "boom" 的进展情况。不能害怕前进，它必须在某个时候完成，我宁愿更频繁地逐步移动，而不是像完全手动过程那样突然升级许多版本。
Murphy 大约一个小时前踢了我的 a$$。
上下文：
我最近加入了一个新雇主，产品在依赖项方面相当过时，Angular 1.2.x、Angular-UI 0.12.0，等等...
这是我工作过的第一个雇主，每天进行产品构建等工作（以前我只在所谓的大型公司工作过，周转速度慢得多）我最初的部分任务是尽可能升级依赖项。因此，今天早上早些时候，我们与一些开发人员就为什么我们所有的 Bower 依赖项都硬编码到特定版本进行了一次水冷式谈话。
两个思想流派是：
- 硬编码版本显然提供了 100% 的安全性，因为版本不能动态跳转，但缺点是如果有人不主动更新我们就会再次落后。
- 我认为语义版本控制为我们提供了某种形式的安全性（加上具有多个暂存环境），并且它应该足够好，比如说，让 Angular 设置为
^1.5.9.
引自语义版本文档：
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
问题：
今天早上早些时候，我们部署到暂存区，一切似乎都很顺利，然后我们在大约一个小时前部署到生产环境……BOOM
问题是 AngularJs 从 1.5.9 更改为 1.6.0。我在迁移文档 (migrate 1.5 -> 1.6) 中看到已注意到这一点：
You may also notice that this release comes with a longer-than-usual list of breaking changes. Don't let this dishearten you though, since most of them are pretty minor - often not expected to affect real applications. These breaking changes were necessary in order to:
问题：
我的断开连接在哪里？ ...或者语义版本文档只是我一直以来的一种虚假的安全感？
外面的人是如何处理这些情况的？人们是否在任何现实世界的解决方案中使用自动依赖升级（如果这对某些人来说非常明显，请原谅），对我来说，构建通过了暂存，并在生产中中断的事实实际上更令人担忧。
（我问的原因是因为对小增量更新的恐惧现在又回来了，而且比以往任何时候都更强烈，我不确定我是否同意这一切的情绪.. .)
看起来很简单，如果他们进行重大更改，他们应该将其升级到 2.0.0。他们没有进行语义版本控制。并非所有项目都使用 X.Y.Z。样式版本正在进行语义版本控制。
尝试在您的测试和暂存环境中以自动化方式了解这 "boom" 的进展情况。不能害怕前进，它必须在某个时候完成，我宁愿更频繁地逐步移动，而不是像完全手动过程那样突然升级许多版本。