我们正在评估迁移的GitLab,目前我们正在使用git(内部)和Gerrit代码审查工具。 在评估GitLab IAM的过程中,将工作流程设计为我们的团队采用具有挑战性。
以下是我的工作流程用例:
需要建议是一种理想的方法,我遇到了诸如无法修改任何更改的挑战,GitLab是否支持修改?
答案 0 :(得分:0)
您所描述的看起来不错。我在应该适应gitlab的步骤中添加了注释。
您的工作流程可能如下:
Merge Request
即可将开发分支合并到master(或任何其他分支)中。请注意,默认情况下,开发分支在Gitlab上不受保护,但您可以在项目设置中对其进行更改。测试可以自动化,例如.gitlab-ci.yml
和gitlab赛跑者。如果您具有自动化的单元/功能/回归测试,则gitlab会在每次提交后运行它们。然后,在创建“合并请求”审阅者之后,功能开发人员将获得清晰的视图,此外,如果所有测试均通过,则在开发分支上需要进行哪些更改。 Gitlab可以阻止Merge Requst(在项目配置中进行适当设置),并要求所有测试作业均通过。因此,我建议测试不仅要在此步骤中运行,还要在任何提交之后自动运行。
无需执行此步骤。当开发人员创建分支并在其上工作时。我知道gerrit会创建refs / for / yourDevelopmentBranch,因此只有在补丁集获得批准后,分支才会创建。 Gitlab和Gerrit之间存在差异,因此您应明确了解它们的含义,例如,两者的行为不同。 here。
您还可以使用manual
触发器在.gitlab-ci.yml中将其定义为作业,或者在分支上的每次提交后仅将更改部署到开发环境中。
...
答案 1 :(得分:0)
假设:
仅一种版本的代码已部署到所有环境
默认分支-主机限制推送
如果管道成功,则所有环境都将使用版本1的相同Docker映像运行版本1的代码。只有一个主分支是最新的一个,并且将根据作业状态(成功/失败)进行标记。
PIPELINE
stages:
- buildJar
- buildImage
- unittest
- releaseVersion
- deployDev
- deployQa
- deployUat
- deployProd
- cleanup