如何避免在源代码中保留版本号？

Question

到目前为止，我们在setup.py中保留了python源代码的版本号。

每次成功运行ci后，此版本都会增加。

这意味着中央库的版本每天都会增加几次。

由于版本号存储在git仓库中的文件中，因此版本号的每次增加都是新的提交。

这意味着大约50％的提交不是由人类提出的，而是由CI提出的。

我有种感觉，我们走错了路。也许在ci中保留版本号并不是一个好方法。

我们怎样才能避免仅增加版本号的“无用”CI提交？

如何避免在源代码中保留版本号？

Update

几年以来，我们没有手动释放。我们没有像MAJOR.MINOR这样的版本控制方案。我们过去并没有错过这个。我知道这不适用于所有环境。但它适用于我目前的环境。

我们有一个版本号，如下所示：YEAR.MONTH.X

这意味着每次通过CI的提交都是新版本。

读完答案后，我意识到：我需要问自己：我有版本号吗？我想不是。我有一个内部版本号。在这种情况下不需要更多。

（谢谢你的选票。在提出这个问题之前，我确信这个问题会被关闭，因为人们会认为它“不清楚”或“过于宽泛”）

Answer 1

物业：

我认为这些是讨论解决方案的前提。

1. 目前版本号保存在git跟踪的源文件中，但您可以将其删除。
2. 没有人手动管理版本号，也没有触发发布过程，其中包括：（a）增加版本号，（b）从源构建和（c）将构建的结果存储在某处。这些都是由CI照顾的，应该保持这种状态。

解：

1. CI只是标记通过CI检查的特定提交，而不是写入源文件并创建新提交，然后将标记推送到远程仓库。
2. 构建脚本应该读取当前HEAD提交的标记，并将其用作发布版本的版本号。
3. 或者，您可能希望使用git filter-branch重写现有的git repo历史记录，标记先前版本提交的一致性，删除并停止跟踪版本号源cile，然后删除那些CI提交。

Answer 2

在源代码中保留版本号是一种常见做法，没有任何错误。

您需要将CI过程分离为常规构建，发布发布和发布部署。

常规构建：每天运行或甚至在每次提交后运行，可以包括静态代码分析和自动测试，检查代码是否可以构建。常规版本不应更改版本号。

发布发布：只能由发布经理明确的手动操作触发。 触发操作可以是使用新版本号标记提交，将新合并标记到发布分支中，或者只是更改保存在特殊文件（例如pom.xml）中的版本号的提交。例如，请参阅git flow。 发布发布分配新版本号（自动或手动），必要时将其提交到源代码中，构建具有新版本的二进制包并将其上载到二进制包存储库（例如Nexus，devpi，本地APT存储库，Docker注册表等）。

发布部署：另一个手动触发的操作，从包存储库中获取现成的二进制包，并将其安装到目标环境（dev，QA / UAT / staging，部分生产用于canary部署或整个生产环境）。

Answer 3

我认为你应该使用git flow。并创建一个主分支和一个开发分支。 CI每次检查开发时版本号都保持不变。每次创建发布时，例如合并开发成主，您可以通过CI增加版本号。

或者我错过了什么，但在我的意见中没有理由每次ci运行时版本号都会增加。

所以最重要的是你应该考虑何时“发布”新版本的更改!!

Answer 4

如果项目保存在git仓库中供生产使用，只需使用git describe的任何变体浮动您的船，无需将其存储在跟踪文件中，因为结果可以识别特定的历史记录，并且您已经拥有了那个历史记录。

如果源是单独发货的，您可以通过use git archive and the export-subst attribute在导出的源中嵌入您想要的任何内容。

Answer 5

PS：作为新用户无法添加评论。

支持并扩展this回答@VibrantVivek。

对于持续集成，对存储库的标记非常重要，无论是将其保存在代码中还是仅通过任何其他git方式，在每次成功的CI之后都必须有相应的标记/版本。

如果你有CI标签/版本不反对提交，那么真正错误的是在这里工作。

并为Martin Fowler +1，这里是另一个更详细的文章链接（或多或少由同一个人）https://www.thoughtworks.com/continuous-integration（建议请阅读）

Answer 6

关于你的第一个问题：

我们怎样才能避免仅增加版本号的“无用”CI提交？

请继续集成（CI）是一种开发实践，它通过自动构建验证每个check-in，允许团队尽早发现问题。

话虽如此，想在此明确表达：

• 从实践中：每个提交应该建立在集成机器上
• 根据如何操作：CI服务器监视存储库并在发生更改时检出更改

简单来说，CI服务器应该只增强版本，并且只有在有新的提交时才会增强，从而确保每个代码提交都是可释放的。

看起来像OP，你所在地区有更多（如你所说）来自commits的“无用”CI server。

根据您的CI机制，我希望您应该/必须能够控制它，几乎有办法处理我们使用的每个工具。 （例如：bitbucket中的webhooks，版本插件等）。

因此，只有在新提交之后我们才能确定新版本。

现在，如果您正在考虑那些常规的夜间集成构建，请阅读以下内容：

许多组织按照定时计划定期构建，例如每晚。这与连续构建不同，并不足以进行持续集成。持续整合的重点是尽快发现问题。每夜构建意味着在任何人发现它们之前一整天都没有发现错误。一旦他们在系统中长时间，找到并删除它们需要很长时间。

你也提到过：每次通过CI的提交都是一个新版本，因此你已经在真正的CI上。

尽管如此，如果您仍然无法弄清楚如何避免版本号的"useless" commits，那么我建议添加另一个问题，详细说明您的CI mecahnism如何工作以及为什么在给定条件下很难。我打赌必须有一个解决方案。还看看GithubFlowVsGitFlow。

来源：Martin fowler's white paper on CI

如何避免在源代码中保留版本号？

在此，想扩展@void答案，因为它在那里说：

It is a common practice to keep a version number in the source code, there is nothing wrong in that.

有些项目必须知道部署的确切version（出于一些重要的xy原因），在这种情况下，他们将源代码和HTTP GET API保存以从部署的代码中获取（一种方式）来了解当前部署在X服务器上的版本。

然而，更多的是要求，假设另一个项目没有这样的情况，然后建议的方式来保持version使用commit哈希/ tagging每个成功的CI构建。

你可以有更多细节here：

希望这可以帮助。