源代码管理发布管理:具有不同配置的同时发布

Question

这是应用程序发布管理的最佳实践问题。但这种情况与我所能找到的有些不同。

本质上，我的公司维护自己的应用程序的叉子。有两个版本的应用程序，将有不同的错误修复/功能配置。这些修复程序和特性来自于一个共同的已完成内容池。这两种配置的原因是有两个主要的测试环境有不同的目标。

让我再用一个场景来解释一下：

1. 我们有功能1，2，&3和错误修复1，3，和3同时由不同的开发人员。
2. 为了向QC发布最新版本，应用程序的Config-1希望包括功能1，bug修复程序1和2，而Config-2希望包含功能2和4。
3. 对于随后向QC发布的版本，某些特性可能会被拒绝，因为它们是不完整的、有缺陷的、不再需要的等等。

#3是很重要的，因为并不是所有的特性都被删除或同步在两个配置之间。这意味着，随着时间的推移，这两种配置略有不同。但只有在短期内，在积极的发展。从长远来看，代码库与生产中的代码是同步的。

因此，作为一个图表，随着时间的推移，构建可能会像这样(上面的项目符号场景中添加了一些特性/bug)：

基本上是一个正常的开发生命周期，但有两个时间线。这是一个主要的应用程序，以及它的分叉，它仅仅是由不同的可用补丁组合而来的。补丁队列可以正常工作，但我们使用构建服务器来生成构建，这要求我们将公开提交的更改(据我所知)推送到远程回购。

我的问题是，在实际的源代码管理级别上，最简单的管理方法是什么。我们过去所做的是(使用Mercurial)维护两个存储库(每个配置一个)，所有的特性/bug都会根据需要作为补丁导入。删除项目需要使用多种方法，最常见的可能是取消。问题是，这两个回购结果大不相同，不同的项目在不同的时间应用。所以整个变更集堆栈将是一个不同的顺序。

我们想要做的仍然是维护两个独立的repos，但是每一次的努力(特性、but )都会被开发成一个分支，这个分支会被推到它所需要的回购中。在给定的回购中，如果在即将进行的构建中需要分支，则将其合并到由我们的Jenkins服务器监视的构建分支中，并生成构建。

有更好的办法吗？一个解决的最佳实践，防止混乱的构建分支，因为备份项目，甚至可能其他问题，我们还不知道？

Answer 1

通过更改源代码来删除特性的问题是，您无法保证您没有因为某些共享代码而破坏其他特性。

如果您需要打开和关闭功能，那么我建议“功能标志”，即。您的应用程序读取并使用了一些配置，以了解是否应该向用户公开仍将在代码库中的特性。

您可以使用各种工具来帮助使用特性标志，如https://launchdarkly.com/。

不过，总的来说，我建议您更改工作实践，以便拒绝QA中的某个功能并不是经常发生的事情，因此您需要担心它。

开发和测试之间的任何来回都是一个时间接收器，拒绝发行版中的“完成”功能将意味着大量的工作将它与下一组更改合并在一起。只是效率低下而已。

• 您的特性和发行版是否在分支中而不是在分叉中？
• 有一个更好的“完成的定义”
• 在dev中进行更多测试
• 更好的特性规范
• 自动回归试验
• 测试人员和开发人员一起开发功能，不要“抛墙”。

Answer 2

短答案

为任意数量的“配置”使用汞队列的单次回购

更长的答案

如果所有的特性只是普通干净代码基础上的补丁，MQ是您最好的朋友:您可以在单独的MQ-修补程序中拥有每个特性(即使是WIP)，并在需要时应用不应用。因为MQ补丁不是存储库的一部分(FIXME!)而且，如果功能可以使用多个开发人员开发，那么您也可以对MQCollab扩展感兴趣，以便在不同的位置之间以简单和自然的方式共享MQ补丁。

更长的答案

如果所有未来的MQ-修补程序都独立于其他MQ-修补程序(根据设计和概念- by代码是最终开发人员的责任)，那么在应用到代码之前，您可以使用单个队列，只需更改修补程序的顺序。

如果你的补丁会有内部的依赖(不好的主意，但是.)，您可以在每个队列中使用自己的补丁堆栈(main+dependent)将依赖修补程序分离成单独的队列，并应用补丁，而不是“按补丁”，而是“按完整队列”应用补丁。

我们想要做的仍然是维护两个独立的repos，但是每一次的努力(特性、but )都会被开发成一个分支，这个分支会被推到它所需要的回购中。

恭喜，你在2019年重新发现了“发布分支”战略。是的，它在很多情况下都有效，也可以为你工作。

1. 您可以在“每个任务的分支”工作流中使用单个repo。
2. 发布分支是永久分支，仅在其中提交合并(按策略)-没有备份，也没有修补程序。