需要针对单个产品同时发布多个版本的流程/体系结构提出建议

如果您担心正在进行的合并相关活动的数量，那么我们需要减少合并活动的数量。这不是一件容易改变的事情，因为你的组织内的文化和期望目前正在调整以产生这种结果。

您需要向单行或单分支模型移动。如果你正在使用Git，那么你仍然可以使用GitFlow中规定的许多短期活动分支来进行修补程序或发布，但你添加所有新代码（DEV、MASTER、TRUNK、Main等）的源代码行应该是一行。一旦你有了功能或版本分支，你就进入了合并的世界。

有许多工程活动和实践可以用来支持你现在在新模型中所做的大部分工作：

1. 功能切换-这是用于合并的主要工程解决方案。如果你在一个代码行上工作，并且总是让程序员签入工作代码，那么功能切换可以让你交付完成一半的功能，你不想让人们看到。你把它们藏起来。。。。现在，你要抛出的第一件事是"但我们做数据库工作，而你不能在那里做"，那你就错了。许多组织实践功能切换，并包括数据库工作。你需要有一个坚实而一致的"仅添加"实践，这样你就不会破坏现有的工作，而是真正做工作来确保新功能和旧功能可以共存。这方面有一些工作，但没有合并那么多（根据我的经验），也没有容易出错或出错的地方。需要记住的一个关键是将它们视为Feature切换，而不是代码切换。如果添加了新功能，则将其隐藏，直到其就绪。如果您正在逐步改进现有功能，那么只需提供新功能即可。实现这一目标将是困难的，需要勇气在您的组织中实施重大的文化变革，从程序员和测试人员，一直到销售和管理。

2. 完成的定义-这就引出了一个问题，即我们如何在这个功能切换的新世界中保持质量？想一想：如果你有三个功能团队都在研究不同的功能，其中一个团队决定降低他们的质量，但他们的产品有缺陷，但足够好，会有什么影响？在分支模型中，你会受到保护，直到你做出各种妥协，让每个人的平庸（或者只是平面垃圾）代码协同工作。现在，我们必须在每次入住和每次发布时都有这个。那么你需要什么呢？您需要一个共享且一致同意的"完成"定义，该定义代表发货必须满足的质量标准。没有它，你将陷入混乱。这里的文化问题是，你需要每个人，每个编码员，每个测试人员，都参与国防部神圣不可侵犯的性质。不，你不能只妥协一次，因为这会产生连锁反应。

3. 缩短周期-这将导致我们的船舶周期。你需要更定期地"发货"。或者更具体地说，您需要定期创建工作软件的潜在可交付增量。这在很多方面支持了上述内容，但最重要的是，它减少了正在进行的工作量。这将有助于降低复杂性并帮助团队集中精力。通过缩短批量，我们可以更经常地遵守"完成"的定义，并拥有"工作软件，无需进一步工作即可发货"的接触点。这里的副优势是，你可以提高你的业务更改能力，因为它们在每个周期结束时都可能发生更改——因为你知道未完成的功能实际上不会带来复杂性。您还可以更频繁地进行检查和调整。大多数公司在收集证据时发现，他们60%以上的软件很少使用。让我们使用减少的周期时间让用户站在软件前面，只专注于构建他们关心的40%。（哇！我们刚刚在那里获得了60%的效率提升吗？）

还有许多其他的支持实践对你来说是很有意义的，我可能建议你阅读Scrum指南(http://www.scrumguides.org/)并思考如何开始朝着上述目标前进。