设计GitLab工作流程

时间:2019-12-24 03:37:08

标签: gitlab gitlab-ci

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

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

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

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

2 个答案:

答案 0 :(得分:0)

您所描述的看起来不错。我在应该适应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. ...

答案 1 :(得分:0)

假设:

  

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

     

默认分支-主机限制推送

  • 管道:*
    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