什么时候应该在Gitlab flow中将git标记为发布之前还是发布之后？

我们使用Gitlab和Gitlab流作为我们的分支策略。我们拥有

master

、

production

和一系列功能分支。我们的

master

分支机构正在管理暂存环境，当

master

与

production

合并时，可以在生产中部署一些东西。以下是开发人员如何开始工作：

从

master

从功能创建WIP合并请求到

master

开始实施一些东西。同事们可以随时看到变化，并帮助尽早进行审查

我们的代码质量门也在MR运行时验证提交

当开发完成并在本地验证时，删除WIP前缀

当审查完成且MR获得批准后，它将合并到master中

将启动CI/CD发布管道以运行不同的测试，并在最后将映像部署到暂存中

---

问题是，如果我将标记release设置为在发布管道的开始应用，那么一些作业可能无法部署到登台，并且它可能会在git上创建一个最终不会部署到登台环境中的发布标记。在这种情况下，将跳过某些版本。但是，如果我将标记发布设置得尽可能晚，比如在登台环境（甚至是生产环境）上部署发布之后，那么CI/CD作业将不会像预期的那样工作，因为如果启动新的发布（检测版本文件上的任何更改），将触发CI/CD作业

---

我想知道有很多发布标签是不是很不寻常，但是只有少数最终被部署到

staging

或

production

？我能看到的唯一一件事是，这种方法在涉及git标记时会产生一些噪音。我在这里遗漏了什么吗？

您能澄清一下如何跳过某些版本吗？你是否考虑过使用Git标签来做分支？你也可以考虑使用这个用例。@ ArihantGodha，如果我在7号开始设置Git标签，那么如果CICD作业失败，这个版本就不会被部署到分级环境中。现在，开发人员查看管道，发现测试失败。然后，他/她应该使用修复程序创建一个新版本（补丁），并创建一个新的MR。现在，如果CICD管道成功，新版本将只部署到暂存中，而以前的版本将不会部署到任何地方，也不会被跳过。关于唯一/例外的场景，这就是版本文件上用来触发管道的内容。“但是，如果我将标记发布设置为尽可能晚，就像在登台环境（甚至生产环境）上部署发布之后一样，那么CI/CD作业将不会像启动新发布时触发CI/CD作业那样正常工作（检测版本文件上的任何更改）“-我不明白这一点。如果CI/CD失败，则开发人员需要进行修补。此修补版本是新版本，因此不包括对版本的更改以指示新版本已准备就绪吗？@Vlad274是的，没错。我的意思是，我们有一个无用的版本（v1.1.0）并且不会有任何用例（因为该版本已损坏，无法通过管道）。该修复程序应作为新版本（v1.1.1）提供。