如何改进我们的分支模式？

Question

我在一家拥有15名内部开发人员和10名外部开发人员的公司担任发布经理。

设置

• 代码库是一个经过大量修改的Magento (PHP)
• 测试套件几乎不存在，但是每天都在改进。
• 开发是在每个开发人员的笔记本上使用Docker容器完成的
• 我们有3个环境
  • 预生产
  • 暂存
  • 生产

• 我们每天做两次制作前的发行
• 我们每周发行一次。

分支模型/代码评审过程

• 所有功能/修复分支都是从主服务器创建的。
• 当开发准备就绪或有新的提交时，它们将被推送到原始特性分支。
• 向预生产分支发出合并请求。
• 负责评审的人员处理MR，解决冲突等。
• 一个自动化的过程每天向我们的产品前环境交付2次。
• 开发在预生产中可供来自业务团队的人员使用，以验证
• 验证/反馈过程可能需要6个月的时间。
• 一旦验证了某个特性，就会向主分支发出合并请求，我将在其中处理合并(开发人员现在应该将他们的特性分支重新定位到执行MR的主框架上)。
• 所有的合并都是由master完成的，然后在生产交付前2天将master交付到我们的分阶段环境。

主要问题

• 随着时间的推移，预生产部门离师父很远很远，也就是说，6'000有差异。
• 业务团队在代码库上验证工作，而代码库根本不是要部署到生产中的代码。
• 验证过程非常缓慢，因此我们必须在很长时间内保持WIP的开发。
• 我们有许多回归，WIP开发破坏了正在测试的另一个特性。
• 冲突被不同的人解决了很多次(在前期合并时，主要的评审者，在做MR on主之前重新立足于主时)。

我正在寻求帮助，以改善整个过程和每个人的生活。

任何洞察力都将不胜感激！

Answer 1

我感觉到你的痛苦。

尽量不要分支和合并。而不是分支和合并，尝试改变你的代码库，使它是模块化的。然后，通过选择构成最终构建的模块，依赖于构建工具来生成部署到任何预期环境中的正确构件。

因此，项目x还没有运行，但它与BAU被签入相同的代码库，项目X团队正在对其进行工作。BAU构建不会将项目X模块添加到最终工件中。但X项目的构建确实如此。

如果您需要两个团队同时处理完全相同的模块，那么要么将工作推迟到单个团队，让他们管理复杂性，要么创建该模块的副本，让管理该模块的团队处理重基，或者使用功能开关。但在实践中，您会发现，实际上非常罕见的是，两个团队经常使用相同的代码。大多数不是BAU的工作都是关于新功能的。

使用SCM来驱动构建的内容，而不是使用构建工具，这是我们多年来一直处于的陷阱。

Answer 2

“业务团队在代码基础上验证工作，而代码库根本不是要部署到生产中的代码”

这实际上是你的全部问题，解决它和其他问题就会消失。任何拥有半个大脑和一点it经验的人都会告诉你，这是非常糟糕的，因为它带来了不必要的增加风险。通常情况下，一些糟糕的生产事件就足以使人们对企业产生误解。(注:我不是在建议你做不道德的事)

如果我是你，我会非常努力地游说一个单行，单一的包代码推广路径，支持一些成本预测，如果它是正确的，如果它走错了。

公司喜欢你描述的爱的过程，并将购买几乎所有的过程改进。如果您的产品部署出现了问题，并影响到了一群用户，那么在不断改进流程的框架下纠正代码提升路径应该会得到一些结果，如果您能够得到它们，就不要让这种势头消失。

另一种观点认为，当前的方法是将每个可部署的构建或包按顺序进行版本化，并使用构成prod部署的最大preprod特性为每个prod部署分配一个版本。然后创建或发布一个时间表，说明哪些版本被交付给preprod，哪些版本被传递给prod，并确保它传递到每个进行测试的组。看到版本号在各处跳跃，可能会帮助你得到一些积极的改变。

您还可以发布一份“特性等待测试”报告，报告的日期(和版本)是准备好的，谁负责测试，它等待了多少天，也许还可以对部署特性的业务进行一些粗略的度量。有些人可能会更早地进行测试，以免成为名单上最糟糕的人。颜色编码最慢或最长的等待项目，并把它们放在顶部可能作为额外的“动机”。