CI 如何影响语义版本控制? [英] How does CI affect semantic versioning?

问题描述

在 Countinous Delivery 书中，推荐将所有内容(包括 CI 脚本)保存在版本控制中.实际上，像 gitlab CI 这样的当前 CI 系统已经遵循这个经验法则，并在同一代码库中搜索 CI 脚本.
另一方面，只要代码库发生变化，我们就会对其进行版本控制(它是构建的工件).我们为此遵循语义版本控制；增加 patch 字段用于错误修复，minor 用于非破坏性功能，等等...
我们通过在 CI 中检查版本来确保版本在提交之间递增.
但是，有些提交只会更改 CI 脚本；即添加分析作业、优化另一个作业等.
在这个冗长无聊的序言之后，我的问题是，对 CI 的此类更改进行版本控制的最佳实践是什么?因为它可能会影响最终构建的工件(例如，更改 CI 作业中的构建标志以进行优化或...).
在这种情况下可以增加版本吗?

In Countinous Delivery book, it's recommended to keep everything - including CI scripts - in the version control. Actually, current CI systems like gitlab CI already follow this rule of thumb and search for CI scripts in the same codebase.
On the other hand, we are versioning our codebase (and it's built artifacts) whenever it changes. And we follow semantic versioning for that; incrementing patch field for bugfixes, minor for non-breaking features, and so on...
And we make sure the version is incremented between commits by checking it in the CI.
But, there are commits that only change the CI scripts; i.e. adding an analysis job, optimizing another, etc.
My question, after this long boring preface, is that what is the best practice to versioning such changes to the CI? Since it possibly can affect the final built artifact (e.g. changing a build flag in the CI job for optimization or ...).
Is it ok to increment the version in this case?

推荐答案

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

Git is a revision control system. Every time you commit something to a git repo, it labels the content of the repo with a content hash value that represents that version of the repo. Semantic versioning of a git repo's content is redundant and pointless. The whole point of SemVer is to provide a means for producers to communicate risk to consumers. In other words, semantic versioning is intended for build product labeling, not the bits that go into producing the build.

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

If you attempt to apply SemVer semantics to the repo, you are labeling the product inputs, not the product itself. You should not apply a SemVer string until after all unit/regression/acceptance tests have been performed. How else can you have any certainty whether the code/build-script changes have broken anything?

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

Pre-build labeling cannot work. Build processes that are capable of reproducing the exact same output twice in a row, are extremely rare, if any exist at all. It is a violation of best practice to have multiple API's/packages in the world with the same SemVer string attached to them. If you label the repo content and then forward that label to the build output, every time you run the build, you produce a package with different content. There will always be some risk that more than one of those outputs will be released into the wild. Many security conscious consumers pay close attention to the content hash of packages they consume. Detecting that a particular producer has released multiple package hashes without bumping the version number, will raise red flags and lead to mistrust of that producers internal processes.

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

This is a very deep topic that can't be fully covered here. Other issues to consider are OS/Compiler/Tool chain updates. Will you also be committing the entire build tool chain to the same repo? This is an untenable approach, full of hazards I cannot fully enumerate, without taking a few months off work to document them.

最佳实践:

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

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

Just for clarity, let me add that maintaining build scripts and tool manifests in the repo is considered a best practice. It ties the versions of your scripts and tools, to the versions of the code you are building. Git does do this job quite well, by creating a commit hash that encompasses the state of the entire repo (minus the tags if I recall correctly). But there will be issues eventually, with older versions of tools, being withdrawn from file shares/feeds, particularly when they are found to create security vulnerabilities.

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

It will sometimes be the case, that older versions of your products, cannot be reproduced using the earlier build process. Checking in the binaries is often promoted as a fix for this issue, but I would argue that it's an anti-pattern. Binaries you are likely never going to want or need in the future, should not be stored in your repo. It just clogs everything up.

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

Consider using an alternate archival system. Maintaining a separate archive of older tools isn't a bad idea, but you will often find that you simply can't run them on current hardware and OS's, without significant reconfiguration of build machine(s) and re-introducing well known security risks. You should frequently prune such an archive, based on the latest known risks and weighing the cost of having to do some additional work, if/when the day ever comes, that you need to build from a really old commit hash.

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

It is better to maintain an up-to-date build system, that can build all of your code base, back to some reasonable point in its history. That point is usually the oldest bits that you are willing to actively support with bug fixes.

这篇关于CI 如何影响语义版本控制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！