CI 如何影响语义版本控制？

Question

在Countinous Delivery book 中，建议将所有内容（包括 CI 脚本）保留在版本控制中。实际上，像gitlab CI这样的当前 CI 系统已经遵循这个经验法则并在相同的代码库中搜索 CI 脚本。
另一方面，我们在代码库（及其构建的工件）发生变化时对其进行版本控制。我们遵循语义版本控制；为错误修正增加补丁字段，为非破坏性功能增加小，等等......
我们通过在 CI 中检查它来确保版本在提交之间增加。
但是，有些提交只会更改 CI 脚本；即添加分析作业，优化另一个等。
在这个冗长乏味的前言之后，我的问题是，对 CI 进行此类更改的版本控制的最佳实践是什么？因为它可能会影响最终构建的工件（例如，更改 CI 作业中的构建标志以进行优化或...）。
在这种情况下可以增加版本吗？

Answer 1

Git 是一个版本控制系统。每次向 git 存储库提交内容时，它都会使用表示该存储库版本的内容哈希值标记存储库的内容。git repo 内容的语义版本控制是多余且毫无意义的。SemVer 的全部意义在于为生产者提供一种向消费者传达风险的方法。换句话说，语义版本控制用于构建产品标签，而不是用于生成构建的位。

如果您尝试将SemVer语义应用于存储库，您是在标记产品输入，而不是产品本身。在执行完所有单元/回归/验收测试之前，您不应应用 SemVer 字符串。您还能如何确定代码/构建脚本更改是否破坏了任何内容？

预构建标签无法工作。能够连续两次再现完全相同输出的构建过程极为罕见，如果存在的话。世界上有多个 API/包并附加相同的 SemVer 字符串是违反最佳实践的。如果您标记 repo 内容，然后将该标签转发到构建输出，则每次运行构建时，都会生成具有不同内容的包。总会有一些风险，其中不止一种产出将被释放到野外。许多具有安全意识的消费者密切关注他们消费的包裹的内容哈希。检测到一个特定的生产者在没有改变版本号的情况下发布了多个包哈希，将引发危险信号并导致对该生产者内部流程的不信任。

这是一个非常深刻的话题，在这里无法完全涵盖。其他需要考虑的问题是操作系统/编译器/工具链更新。您还会将整个构建工具链提交到同一个仓库吗？这是一种站不住脚的方法，充满了我无法完全列举的危险，除非花几个月的时间来记录它们。

最佳实践：

• 使用明确说明开发人员意图的语义提交消息。
• 在包装/贴标签之前验证构建输出。
• 对于非预发布的出版物，始终让人类参与其中。

为了清楚起见，让我补充一点，在 repo 中维护构建脚本和工具清单被认为是最佳实践。它将您的脚本和工具的版本与您正在构建的代码的版本联系起来。通过创建一个包含整个存储库状态的提交哈希（如果我没记错的话，减去标签），Git 可以很好地完成这项工作。但最终会出现问题，旧版本的工具从文件共享/提要中撤回，尤其是当发现它们会造成安全漏洞时。

有时会出现这样的情况，即您的产品的旧版本无法使用较早的构建过程进行复制。检查二进制文件通常被宣传为解决此问题的方法，但我认为这是一种反模式。您将来可能永远不会想要或需要的二进制文件不应存储在您的存储库中。它只会堵塞一切。

考虑使用备用存档系统。维护旧工具的单独存档并不是一个坏主意，但您经常会发现，如果不对构建机器进行重大重新配置并重新引入众所周知的安全风险，您根本无法在当前硬件和操作系统上运行它们. 您应该经常修剪这样的档案，根据最新的已知风险并权衡必须做一些额外工作的成本，如果/当那一天到来时，您需要从一个非常旧的提交哈希构建。

最好维护一个最新的构建系统，它可以构建您所有的代码库，回到其历史上的某个合理点。这一点通常是您愿意通过错误修复积极支持的最旧的位。