我有一些关于持续交付版本控制的具体问题。我想我了解全球工作流程或多或少是这样的：
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 工作流程。
一般来说，你应该有：
如果您关心 semver 或者您必须为其他工具/库提供兼容性信息，那么第一点至关重要。只有你才能判断一个新的“版本”是否会破坏任何东西——最流行的指示系统是遵循 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 服务公开的内部版本号。
版本控制呢？如何管理构建版本？
与其他方式相同；在生成要分发的工件（到云或通过软盘）时，工件和组件应标有唯一且可追溯的版本号。这个数字应该与创建它的源代码直接相关。我们这样做是因为它可以帮助我们正确解决生产系统中的问题、跟踪程序行为变化以及其他一些支持/维护/设计方面的事情。无论交付机制如何，我们都应该这样做，因为它很容易做到，并且在您无法将源代码与执行程序连接的情况下，它可以为您节省很多麻烦，您将做出艰难的假设并且猜测（与您的工作和/或声誉有关）。
因此，请忽略另一个答案中关于不标记您的回购的建议 -始终标记您的回购。
此外，只要有可能，请尝试确保为要使用的构建生成的版本号在正在构建的程序可执行文件或库上设置。
当开发人员向 VCS 提交更改并且 CI 服务器执行构建时，CI 服务器是否应该增加构建版本并在 VCS 中创建标签？
大多数构建系统都具有版本控制或编号功能，包括 Maven。但是，只有生成要部署的工件的构建才应该分配版本编号和标记存储库。通常这将排除持续集成/门控签入构建，因为它们仅用于将传入的开发人员更改与主分支集成。