多存储库环境中的打包和版本策略

我们是一家小型公司，拥有多个团队管理自己的git存储库。这是一个Web平台，每个团队的工件都在一天结束时部署以进行夜间测试。我们正在尝试使围绕版本控制和打包的过程正式化。

每个团队都有一个主分支，负责日常开发。每个团队的质量保证成员都希望将他们团队变更中的工件部署到测试台中，由厨师将所有组件组合在一起。工件是压缩包，但我想将其转换为RPM，以便我们可以正确思考和推理版本。

发布过程涉及从每个git存储库的开发分支（在大多数情况下为master）切断发布分支。然后将其提供给质量保证，由质量保证对一组工件进行测试和签核。

例如，这是一个典型的git存储库及其相关的发行分支：

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

我一直在试图找出一种方案来执行来自开发分支的软件包的版本控制。我们不想过多地标记每个仓库的主分支，并限制标签仅释放分支。但是我们应该能够使用标准的yum / rpm语义查询测试机器中已部署的软件包。当master分支没有标签时，开发版本会是什么样？我知道这git describe可以为我提供构建版本的有用表示，但是当标记分支上的各个发行点时，它可以很好地工作。

编辑1：响应@ Urban48的答案

我认为我应该多解释一下发布过程。为了便于讨论，我们假设master在所有存储库中都有分支。该master分支被视为开发分支，并且已部署到支持CI-CD的自动化QA环境。这是每晚测试的子集，用于确保主服务器的稳定性。在削减发行分支之前，我们先看一下这一系列工作。我们的发行分支是短暂的。假设（从稳定的主服务器上）剪切了一个发布分支之后，将运行完全回归，进行修复并将其部署到生产中。这大约需要一周的时间。我们几乎每两周发布一次产品。

我们的功能分支总是从母版中剪切下来的，并在与母版合并之前经过一定量的开发人员测试，然后对它们进行CI-CD稳定性检查。

修补程序是在修补程序分支（从发行版分支切下的）上进行的，并以最小的影响测试将其部署到生产环境中。

以下是我们针对发行版和修补程序分支的版本控制策略。在质量检查周期中，发行分支会经历的版本v2.0.0-rc1，v2.0.0-rc2最后在质量检查批准后变为v2.0.0。

有时，我们会针对一些小功能进行点发布，这些小功能会合并到版本变为的版本分支（然后合并到母版）中v2.1.0。修补程序采用该v2.1.1模式。

但是，问题不在于对这些分支进行版本控制。我不希望完全更改此版本控制方案。唯一的变化来自开发部门。主。如何在CI-CD环境中可靠地指示在生产中的先前发行版中存在哪个版本。理想情况下，这可以通过智能git标记完成，但最好不要过度标记master分支。

嗯，我有一个.net示例，可能与技术无关。

我将做一个简短的总结。

• 每个组件都有gitflow分支策略的git repo

• 一切致力于发展触发团队城市建设

• teamcity构建使用手动主要次要版本+ AssemblyInfo.cs中的内部版本号（即1.1.hotfix.build）修改版本

• teamcity使用与nuget发布的库相同的版本号触发nuget打包

• 章鱼将完成的构建部署到qa进行手动测试（假设所有测试均通过）

• 如果一切正常，请通过章鱼手动将版本部署到生产中。

现在，这确实意味着您可以获得大量的版本化软件包。我们确实使用-prerelease标志进行了实验，但这需要将软件包从prelease进一步手动移动到“正常”步骤，并且需要重建依赖于它们的组件。

关键是通过某个中央过程对每个版本进行唯一的版本控制。

然后您处于“嗯，我想要什么版本”而不是“哎呀，我有什么版本？”的情况。

编辑：重新评论。

只是为了强调这一关键事实。确定哪个分支构成完整的软件，以及ALL提交给其的版本。仅从此分支部署版本控制的软件。

我的观点是，您需要解决分支策略。

• 不要版本化功能（或任何开发人员）分支。
• 做版本大师
• 只使用主人的包裹

让我提供替代的工作流程，它可以解决您的版本控制问题，或者只是帮助您思考解决方案的更多方法。

首先要讲一点哲学。
（我对您的工作流程没有几个假设，如果我做错了，请纠正我）

1. 测试是追溯运行的：

   分支maser到功能分支，然后将其变成工件以进行质量检查。
   问题是：如果测试失败，那该怎么办呢master！

   副作用：

   • 它使开发人员不信任 master

   • 由于您是从master分支到发布分支，因此如果先前的发布被破坏会怎样？它将停止新功能集成，直到再次修复master。

   • 在发布分支中修复错误后，合并回master可能会产生合并冲突。（而且我们不喜欢冲突）

2. 小代码合并和修复：

   很难跟踪合并到的所有代码master，例如小的修订或不属于某个功能的更改。

   副作用：

   • 开发人员不确定是现在还是以后再修复此小问题。

   • 我是否也应该版本此新的小补丁？

   • 在任何时候都不清楚master分支的状态是什么，什么代码在其中浮动

   • 某些东西破坏了构建，但这不是新功能的一部分。而且真的很难追踪它的来源

我对git工作流程的想法如下：

分支出来的master新功能开发像你这样做了。但是现在，与其从这个新创建的分支中释放出来，不如将其精选并合并到release分支中。

现在，您可以更好地控制特定版本的内容。
现在，将开发版本和稳定版本隔离起来确实非常容易。

您可以继续从那些功能分支构建工件以进行质量检查。
如果一切正常，请将该功能合并回master，然后将该功能/错误修复/热修复精选到release分支中。

版本控制
功能分支版本可以使用一些名称约定，例如1.2.3-rc.12345

release分支中的版本将仅使用1.2.3 （1.2.3> 1.2.3-rc.12345还有一件少了的事要担心）

此工作流程解决了上述问题以及更多问题。
它还提出了合理的版本控制策略，并且此发行周期的大部分内容可以自动化。

我希望它会以某种方式对您有所帮助，我将很乐意讨论您可以提出的任何极端情况。

ps：
我为我的英语（不是我的主要语言）道歉。

您的过程似乎非常复杂，并且不可避免地会获得一些标签。

我想到两个想法：

1. 您将“ master”分支视为我们通常在“ develop”分支中所拥有的。这会严重污染邮件分支。

2. 质量检查完成工作后，您可以让build / CI服务器使用所有使用中的仓库的标签来创建报告（例如，文本文件）。现在，您将拥有一个文件，该文件的版本可以发布到仓库中。然后，您仅用发行版本标记分支，如果要检查各个组件的版本，则可以检查报告。