在持续交付中构建版本控制

Question

关于持续交付中的版本控制，我有一些具体的问题。我想我理解全球工作流程，或多或少是这样的：

1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment

那么版本控制呢？如何管理构建版本？

假设我们正在处理一个具有语义版本控制的基于Maven的项目：major.minor.build。

当开发人员提交对VCS的更改并且CI服务器执行构建时，CI服务器是否应该增加构建版本并在VCS中创建标记？

源代码中是否存在此构建版本？如果是这样的话，在每次推送到VCS之后，开发人员应该更新项目，因为CI服务器在项目上提交了更改(版本增量)。

我有点困惑，我想以一种实用的方式理解CD的工作流程。

Answer 1

一般情况下，您应该具备：

1. 手动管理的版本号。
2. 任意数量的“参考”号。

如果您关心semver，或者您必须为其他工具/库提供兼容性信息，第一点是至关重要的。只有你才能知道一个新的“版本”是否破坏了任何东西--最流行的指示系统是遵循版本控制规则。

第二点(“参考”数字)对你可能重要，也可能不重要。您通常不需要一个以上的CI/CD构建版本号(每个流行的CI/CD服务都有一个构建版本号ID，它表示特定的“构建”)。这个数字的意义在于，如果需要的话，您可以快速检查工件的相关CI/CD构建/日志。

如何合并这两个(或更多)部分？

有单独的“版本”和“内部版本”编号并不少见。事实上，默认情况下，每个iOS项目都有此功能。在这种情况下，您可以手动管理“版本”号，并自动管理一个单独的“内部版本”号。内部版本号可以在工件的名称中，也可以在用户检索二进制文件的--version信息时打印出来(例如：$ brew info -> 0.9.5 (git revision 18c48; last commit 2015-11-02)

或者，您可以向semver添加新组件(x.x.x.BUILDNUM)，使用semver的最后一个组件(x.x.BUILDNUM -如果您有严格的增量构建，我不建议这样做)，或者简单地在工件名称中包含“BUILDNUM”编号。

这些都是可能的，你必须为你的情况选择一个最好的。你必须定义这些数字的含义，并决定数字应该出现在哪里(例如，它应该是--version调用的一部分，还是应该只是文件名的一部分)。

编辑：思考您关于“CI服务器是否应该增加构建版本并在VCS中创建标记？”的问题--我永远不会推荐这样做。CI服务器也会有问题，您不应该修改CI进程中的代码。意外地覆盖(例如，强制推送)某些内容可能会非常危险。这就是为什么最好只使用CI/CD服务公开的内部版本号。

Answer 2

版本控制呢？如何管理构建版本？

与其他方法相同；当生产要分发的工件(无论是分发到云上还是通过软盘)时，工件和组件都应该标记上唯一且可跟踪的版本号。这个数字应该与创建它的源代码直接相关。我们这样做是因为它可以帮助我们正确地修复生产系统中的问题，跟踪程序行为的变化，以及其他一些支持/维护/设计方面的事情。我们应该这样做，而不考虑交付机制，因为它很容易做到，并且可以在以下情况下为您省去很多麻烦:如果您没有能力将源代码与正在执行的程序连接起来，您将做出艰难的假设和猜测(与您的工作和/或声誉处于危险之中)。

因此，请忽略另一个答案中关于不要标记您的存储库的建议- tag您的存储库。

此外，只要有可能，请尝试确保正在构建的程序可执行文件或库上设置了为要使用的构建生成的版本号。

当开发人员提交对VCS的更改，CI服务器执行构建时，CI服务器是否应该增加构建版本并在VCS中创建标记？

大多数构建系统都有用于版本控制或编号的工具，即Maven included。然而，只有产生被部署的工件的构建才应该分配版本编号和标记repos。通常，这将排除持续集成/门控签入构建，因为它们仅用于将传入的开发人员更改与主分支集成。

Answer 3

您可以在这里找到详细的解决方案

Single click code-versioning (Complimenting cloud-native Architecture)

我们的想法是使用maven插件jgit-flow插件，并使用Jenkins和这个插件，我们已经创建了整个管道来自动化这个过程。