为什么要对CI / CD项目完全使用版本控制?

时间:2020-02-17 17:31:33

标签: continuous-integration versioning

我听说(工作中)有人声称完全CI / CD的项目不需要版本控制。我想提出一些反对意见(或可能同意)。

一些澄清和假设:

  • 对于“完全CI / CD”,我认为有一条管道可以自动运行测试,构建和部署项目;
  • 该项目经历了从TEST到PROD的多种环境,并从一个环境手动升级到另一个环境;
  • 该项目由几个微服务组成;
  • 公司中的其他团队使用这些微服务提供的公共API(在公司外部不可用);
  • 其他团队可以编写微服务以与主项目进行交互;

反对使用版本控制的要点是“在任何给定的点上,只有一个可用的版本”,这是不正确的,因为存在多个环境,因此潜在的版本与环境一样多(因为并非在所有环境中都同时发布)。

建议的解决方案是仅将git hash用作“版本”,但是我知道这会损害按时间顺序轻松地排序版本的能力(我知道实际上可以去git并检查哈希,但也许不是每个人都有访问它,或者可能是在紧急情况下,我们只想查看STAGE上的版本是否比PROD中的版本真正新即可。

有人建议我们使用日期作为版本号,但是我知道这会引起其他类型的问题:我们要使用什么级别的准确性?如果同时有两个构建,该怎么办?我们用毫秒吗? UNIX时间?这会使版本号变得难以理解,而且我敢肯定QA会讨厌我们。

我已经搜索了这种讨论,但是我只能找到有关如何对CI / CD项目进行版本化的文章,而对于WHY或为什么不对CI / CD项目进行版本化则没有讨论。

非常感谢您的投入!

0 个答案:

没有答案