设计GitLab工作流程

Question

我们正在评估迁移的GitLab，目前我们正在使用git（内部）和Gerrit代码审查工具。 在评估GitLab IAM的过程中，将工作流程设计为我们的团队采用具有挑战性。

以下是我的工作流程用例：

1. 从母版创建分支
2. git commit并推送到分支
3. 同行开发人员对提交的代码进行审查
4. 如有任何评论意见，请修改并推送
5. 第3步（同行开发者的审查）
6. 在分支上运行测试
7. 合并由Lead（维护者）转移到分支的提交
8. 使用分支代码部署我们的开发环境
9. 由维护者将分支合并到母版

需要建议是一种理想的方法，我遇到了诸如无法修改任何更改的挑战，GitLab是否支持修改？

Answer 1

您所描述的看起来不错。我在应该适应gitlab的步骤中添加了注释。

您的工作流程可能如下：

1. ...
2. ...
3. 准备好审查功能时，只需创建Merge Request即可将开发分支合并到master（或任何其他分支）中。请注意，默认情况下，开发分支在Gitlab上不受保护，但您可以在项目设置中对其进行更改。
4. ...
5. ...

6. 测试可以自动化，例如.gitlab-ci.yml和gitlab赛跑者。如果您具有自动化的单元/功能/回归测试，则gitlab会在每次提交后运行它们。然后，在创建“合并请求”审阅者之后，功能开发人员将获得清晰的视图，此外，如果所有测试均通过，则在开发分支上需要进行哪些更改。 Gitlab可以阻止Merge Requst（在项目配置中进行适当设置），并要求所有测试作业均通过。因此，我建议测试不仅要在此步骤中运行，还要在任何提交之后自动运行。

7. 无需执行此步骤。当开发人员创建分支并在其上工作时。我知道gerrit会创建refs / for / yourDevelopmentBranch，因此只有在补丁集获得批准后，分支才会创建。 Gitlab和Gerrit之间存在差异，因此您应明确了解它们的含义，例如，两者的行为不同。 here。

8. 您还可以使用manual触发器在.gitlab-ci.yml中将其定义为作业，或者在分支上的每次提交后仅将更改部署到开发环境中。

9. ...

Answer 2

假设：

  

仅一种版本的代码已部署到所有环境

     

默认分支-主机限制推送

• 管道：*
  1. 推送到功能分支开始->构建->运行单元测试。
  2. 将请求从功能合并到主--Build-> BuildDocker映像->单元测试->发布版本并将代码标记为v1.0-> DeployDev
  3. 标记代码（v1.0）--->获取版本（从previousJob）-> DeployQA ---> DeployUAT-> DeployProd（要部署的手动选项）

如果管道成功，则所有环境都将使用版本1的相同Docker映像运行版本1的代码。只有一个主分支是最新的一个，并且将根据作业状态（成功/失败）进行标记。

PIPELINE

stages:
  - buildJar
  - buildImage
  - unittest
  - releaseVersion
  - deployDev
  - deployQa
  - deployUat
  - deployProd
  - cleanup