同步错配- CI/CD管道

Question

我们正在我们的公司实施CI/CD，我们有一个监管项目，需要很长时间来测试。由于该项目包含大约300个规则，因此无法对其进行分解，每个规则都需要每次测试。其他项目的测试时间要短得多，而且它们与主线检查的频率要高得多。对于监管项目，我们从主线中提取并进行集成测试，但是当我们签入时，有来自其他项目的10s签入，这些都必须再次进行测试。任何和所有的帮助都将不胜感激！

在所附的图表中，项目B表示管理项目，在项目B的测试期间，项目A已签入两次并与主线同步。

Answer 1

优化您的测试可能是您应该首先考虑的事情。尽管如此，这可能还不够。很少有你可以研究的策略，每个策略都有自己的缺点，所以这将不可避免地成为一种妥协。

将项目隔离开来，将两个项目分离到各自的回购/构建管道中，并将它们作为外部依赖进行集成。这样，它们的提交周期就不会相互干扰。将项目A视为它自己的产品/库，并使用它自己的版本控制方案发布它。然后，项目B可以自由地集成它所选择的版本并与之进行测试。这种方法的缺点是项目B总是落后于项目A的发展。如果另一个项目同时依赖于A和B，它将落后于B并从B获得它的依赖性。这意味着对A所做的任何更改都必须以慢得多的速度传播到最终产品，因为它必须创建一个版本，等待B在依赖项下发布该版本，然后等待B完成测试并发布它自己的版本。注意，这并不意味着开发速度较慢，只是从A进行的更改将需要更长的时间才能到达最终产品。尽管如此，这将使它更加可预测。

在B的测试过程中冻结主分支，直到它被集成为止，A的开发将继续在它自己的分支中进行，但是在B的测试完成之前，它将无法合并到主分支中，并且已经合并到主分支中。

你只有这两个项目，那就没那么糟了。如果有与A相似的提交频率的其他分支，那么它们都应该位于同一个分支上(例如B获取其内容的一个主分支，并致力于一个开发分支，在这个分支中，所有其他东西都往返于主分支，并且它本身往返于主分支)。

再一次，在这里，你正在放慢到最慢的速度。这里的关键是不要完全停止一切，这样A的dev就可以继续，但是只能在特定的时间与main同步。

Answer 2

您可能会发现不同的源代码管理工作流可能会有所帮助。这页是亚特兰西安写的很好地比较了不同的流。

尤其是，git流可以帮助解决这个问题。这个概念与纽托邦人所描述的相似。如果您在develop和master分支之间有一个单独的分支来进行监管测试，开发人员可以定期(一夜之间)检查开发。合并、构建和测试可以从监管测试分支运行。Git-flow谈论“道路规则”，以最大限度地减少整合问题。