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

Question

我们是一家小型公司，拥有多个管理自己的git存储库的团队。这是一个web平台，每个团队的工件最终都会被部署到夜间测试中。我们正试图将版本控制和打包的过程正规化。

每个团队都有一个主要的分支，他们在那里进行日常开发。每个团队的质量保证成员都希望将其团队变更中的工件部署到一个由主厨组合所有组件的测试床中。工件是tarball，但是我想将它们转换为RPM，这样我们就可以正确地思考和推理版本了。

发布过程涉及从每个git存储库的开发分支(在大多数情况下是主)中切断一个发布分支。然后给质量保证谁运行测试和签署一组工件。

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

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

我正试图想出一个方案来执行来自开发分支的包的版本控制。我们不想过分地标记每个回购的主分支，并且限制标记只释放分支。但是我们应该能够使用标准的yum/rpm语义来查询测试机器中部署的包。当主分支没有标记时，开发版本会是什么样子？我知道git describe可以为我提供一个构建版本的有用的表示，但是当对分支上的各个发布点进行标记时，它会很好地工作。

EDIT1:对@Urban48's的回答

我想我应该再解释一下我们的释放过程。出于本讨论的目的，让我们假设在所有存储库中都有分支master。master分支被认为是开发分支，并被部署到一个支持自动CI-CD的QA环境中。这是夜间测试的子集运行的地方，以确保主测试的稳定性。我们在裁掉一个发布分支之前，先看一看这段工作流程。我们的发布分支是短暂的。比方说，在切割了一个发布分支(从一个稳定的母版)之后，运行了一个完整的回归，并进行了修复并将其部署到生产中。这大约需要一周的时间。我们几乎每两周发行一次。

我们的特性分支总是从master中分离出来，并在与master合并之前进行一定数量的开发人员测试，并在其上进行CI-CD稳定性检查。

修补程序是在hotfix分支(从发布分支中分离出来)上进行的，并且以最小的影响测试部署到生产中。

我们发布和修复分支的版本控制策略如下所示。在QA周期中发布分支通过像v2.0.0-rc1、v2.0.0-rc2这样的版本，最后在QA注册后成为v2.0.0。

有时，我们会为一些小的特性做点的发布，这些特性被合并到发布分支(然后是主版本)中，从而使版本成为v2.1.0。修补程序采用v2.1.1模式。

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

Answer 1

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

我来做个简短的总结。

• 基于gitflow分支策略的组件gitflow
• 所有提交开发触发团队城市建设
• teamcity build用手动小调+ AssemblyInfo.cs ie 1.1.hotfix.build中的版本号修改版本
• teamcity为nuget发布的库使用相同的版本号触发nuget打包
• 章鱼将完成的构建部署到qa进行手动测试(假设所有测试都通过)
• 如果一切正常，通过章鱼手动部署版本到生产。

现在，这确实意味着会有很多版本化的包四处浮动。我们试验了使用-prerelease标志，但这需要一个进一步的手动移动包从预租赁到‘正常’步骤，并要求重建组件依赖于他们。

的关键是通过一些中心过程对每个构建进行唯一的版本。

那么你的处境是‘嗯，我想要什么版本’而不是'omg，我有什么版本？‘

编辑:关于评论。

只是为了强调这个关键的事情。决定哪个部门构成完整的软件和版本都提交给它。只从这个分支部署版本化的软件。

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

• 不要对特性(或任何dev)分支进行版本化。
• 做版本母版
• 只使用来自母版的包

Answer 2

让我提供可供选择的工作流，它可能解决您的版本控制问题，或者只是帮助您想出更多的解决方案的方法。

先讲点哲学..。

(我对你的工作流程做了一些假设，如果我错了，请纠正我)

1. 测试是追溯运行的:从maser分支到特性分支，然后将其转化为由QA进行测试的工件。问题是:如果测试失败了，那么master可能会被破坏！副作用：
   • 这使得开发人员不信任master。
   • 既然您已经从母版扩展到发布分支，那么如果以前的版本被破坏了会发生什么呢？它停止您的新功能集成，直到主人再次修复。
   • 当错误在发布分支中修复时，合并回master可能会创建合并冲突。(我们不喜欢冲突)

2. 小代码合并和修复:很难跟踪所有合并到master中的代码，就像不属于某个特性的小修复或更改一样。副作用：
   • 开发人员不确定他现在或以后是否应该修改这个小补丁。
   • 我也应该修改这个新的小补丁吗？
   • 在任何时候，都不清楚master分支的状态是什么，以及在其中浮动的代码是什么。
   • 有些东西破坏了构建，这不是新特性的一部分。很难追踪它从哪里来

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

像您已经做的那样，从master中分离出来进行新的特性开发。但是现在不是从这个新创建的分支发布，而是选择这个特性并将其合并到release分支中。

现在，您可以更好地控制某个版本中的内容。

现在，分离开发版本和稳定版本是非常容易的。

您可以继续从这些特性分支为QA构建工件。

如果一切正常，将该特性合并回master，然后选择此特性/bug修复/热修复到发布分支中。

版本化

特性分支版本可以使用一些名称约定，比如1.2.3-rc.12345。

release分支中的版本将只使用1.2.3 (1.2.3 > 1.2.3-rc.12345也可以少担心一件事)

这个工作流解决了上面提到的问题以及更多的问题。

它还提出了合理的版本控制策略，并且这个发布周期的大部分都可以自动化。

我希望它能在某种程度上对你有所帮助，我很乐意讨论任何你能想到的边缘问题。

p.s：

我为我的英语道歉，它不是我的主要语言。

Answer 3

您的过程似乎非常复杂，得到一些标签似乎是不可避免的。

我想到了两个想法：

1. 您将“主”分支视为我们通常拥有的“开发”分支。这对消息分支造成很大的污染。
2. 当QA完成他们的工作时，您可以让build/CI服务器创建一个报告(例如。一个文本文件)，带有所有正在使用的repos的标记。现在，您将有一个文件与版本，可以张贴到回购。然后，只使用发布版本标记分支，如果要检查它们的各个组件的版本，则可以检查报表。