质量检查阶段的新提交

Question

当前使用Dev管道（Jenkins）部署和测试了应用程序

源代码位于GitLab的develop分支中，紧跟Gitflow workflow

在创建develop分支之前，QA管道将在标记release分支中的特定提交之后触发构建，测试和部署，如下所示：

按照Git流程，理想情况下，质量检查管道应在工件（${release_num}-${JenkinsBuildNum}-SNAPSHOT.jar）上触发，而不是在develop分支中的git commit上触发。

将应用程序移至质量检查空间进行质量检查小组的测试后，

1）开发团队是否不应该在develop分支中创建任何新的提交？除非质量检查小组发现任何错误

2）QA管道生成的工件的命名约定应该是什么？开发管道会生成名称为${release_num}-${JenkinsBuildNum}-SNAPSHOT.jar

的工件

Answer 1

我不确定我是否正确理解了您的问题的说明，因此我尝试重新措辞：

• 您正在使用某种持续集成和部署服务器。
• 您的源代码在GitLab上。
• 在您的develop分支上标记一个提交将触发质量检查管道/构建，该管道/构建将从该提交构建您的应用并将其部署到质量检查空间，以便测试人员可以安装和测试它。

现在，您的问题似乎是：

开发团队是否必须等待（“代码冻结”）提交到develop分支，直到测试人员完成测试？

---

如果您问我上面的描述，我的答案将是：

将来尝试将git flow工作流程用作git分支模型。

对于您当前的问题，只需根据您在develop分支上标记的提交创建另一个分支，并将分支命名为release。

现在，开发人员可以继续正常处理新功能，并将更改提交到您的develop分支。

如果测试人员发现任何需要修复的错误，则可以在release分支上进行此操作。修复所有问题后，您可以从发行分支构建经过测试的应用程序版本。

完成操作后，请不要忘记将您在release分支上所做的错误修复合并回develop分支。

---

在澄清问题后进行编辑：

正如我所看到的：如果正确应用Gitflow，它应该可以确实解决您在问题1中提出的问题。

您的日常开发人员工作所添加到的分支是develop。当您实现所需的所有功能并认为已准备好发布某些内容（从开发人员的角度来看）时，您将创建release分支，以将当前版本（您的发布候选版本）保存在某个位置，然后让测试人员验证此版本。作为开发人员，您可以继续研究下一个功能，并将更改提交到develop分支。

当测试人员发现错误时，可以在release分支上修复该错误。修复所有问题后，您可以从release分支创建应用程序版本并将其发布给客户。实际发布后，您可以将release分支推送到master分支，还可以将release分支上的更改合并回到develop。

据我所知，release分支的存在完全是为了避免您的问题1）。 您的流程以这种方式工作的原因很可能是某些原因，但是为什么要在测试人员测试之后 之后创建release分支？