使用git流发布未经测试的特性

Question

不太清楚如何把它放在标题中，因为这个问题有点具体。

基本上，我们在应用程序中使用的是gitflow (它的细微变化)。因此，这意味着我们有以下分支

• 船长(PROD)
• uat (分期)
• 发展(测试/质量保证)

我们从dev创建我们的所有特性。开发人员为他们的特性分支feature/1234与dev创建一个PR。一旦它合并到dev中，这些更改就会被部署到TEST/QA中

在每个sprint结束时，我们从dev部署到uat，将更改放到staging服务器上。许多人都对staging服务器进行了积极的测试，这就是为什么我们有一天的时间来部署预期的维护工作。

现在的问题如下。假设在sprint结束前一天--我们完成了部署--一个特性已经合并到dev中，因为代码检查和本地测试都很好。

然而，QA发现了一个小问题，或者可能还没有时间进行测试。

当我们现在通过在uat上创建release-branch部署到dev时，我们还会将那些尚未完成QA的更改推到UAT上。这当然是个问题。

我在想我们怎么才能抵消这个问题？我有多种想法

• 在sprint的前一天锁定dev，这样当我们看到所有的票都完成QA时，就没有人可以合并任何东西来开发了。然而，我们将失去一天的发展，因为如果在那一天，我们将完成某事。如果不被部署
• 恢复那些不应该部署的合并提交，但这感觉像是一个解决办法。
• 在uat上创建发布分支，然后选择合并提交，但是tbh，我不喜欢在这种情况下使用，因为它只是再次应用diff而不是提交本身。
• 只有在QA以前批准任务时才部署到dev。这样，dev上只有一个特性，只有在QA完成的情况下，我们才会合并另一个特性，但是，只有在我们有一个qa员工的情况下，这才能工作。如果有2，那另一个测试是什么？此外，我们将得到一堆打开的拉请求，这些请求基本上已经准备好，但没有合并，然后我们必须始终牢记这一点，而且可能仍然会发生这样的情况:在发布开始之前，合并的最后一个功能将无法完成QA状态。
• 最后一个选项是基于特性分支的发布。而且，只有在特性分支发布成功的情况下，我们才能将其合并到dev中，然后才能从dev -> uat中真正创建pr，并且只有必须在其中进行的更改才会被部署。然而，我们有一个微服务体系结构，有5-6个团队.如果我们为这种情况创建额外的基础设施，如果我们想同时部署多个基础设施，那将是非常昂贵的。

所以我不知道最好的方法。我只知道我们每个发布日都有问题，我们不确定我们是否能够部署，QA是否会完成，QA是否会有发现，而且部署日总是非常紧张

Answer 1

这感觉就像一个主要的问题，一个小问题引起了复杂。

1. 不要将任何东西合并到dev中，除非它可以在sprint结束之前进行适当的测试。如果不能完全测试，请阻止合并。决定推迟某件事需要与QA协商。
2. 在这种情况下，您绝对不能避免将未经测试的代码合并到dev中，请在dev上创建最后一个很好的提交的发布分支。您并不总是需要盲目地做git branch releaseX dev。指定一个提交Id或标记，表示在未测试的代码签入之前在dev上最后一个好的提交：git branch releaseX asdf7683tg7

当在sprint之后修复一些东西时，根据发布分支修复它。然后将发布分支合并到dev和其他相关的发布分支中。不要选择提交，因为这会创建没有共享历史记录的新提交对象。合并冲突需要多次解决，这可能导致冲突解决不一致。

Answer 2

当在任何环境中发现问题时，我建议从该环境的分支中创建您的“特性”分支。这实际上是修补程序的分支。您不一定要引入新功能，而是提供补丁，以确保预期的功能正常工作，或者在发布计划中无法按预期工作时删除功能。

这将确保从事未来工作的团队不会被阻止集成他们的工作，也不会像恢复一样混乱历史(也许还会恢复)。

很难说你所拥有的相位门是否合适。假设他们是，你可能想要考虑如何使他们更难。也就是说，如果要在提升到阶段之前完成QA，就不要推广那些还没有通过QA过程的东西。当然，可能有比硬相位门更好的工作方式，但这将是工作方式上的一些重大转变，需要投资才能实施。

Answer 3

考虑到您的部署过程是如何工作的，在您的团队能够更频繁地部署之前，您很可能无法充分解决这个场景。总会有最后一分钟的问题--有时甚至是在表面上已经过了UAT之后。

如果QA在部署前一天发现其中一个更改的问题，会发生什么？您打算部署所有其他更改吗？你怎么知道你的应用程序的版本，除了一个改变之外，实际上是有效的，因为没有人测试过它。

应该解决的是，一旦改变被标记为生产准备，就无法立即部署这一系统性问题。等待部署的变更越少，痛苦就越少。