这篇文章是站在Architect立场，把基本的开发流程走完。
为什么
为什么要用GitLab？
当前方式：Git + Gerrit + Jekins，编写代码和自动化测试是分开的，为什么要分开？因为developer 和 tester 都是有门槛的，全栈工程师毕竟是少数，即使都懂，相关配置也要知道，意味着需要处理的信息量变大了。
GitLab默认把原始功能代码和自动化测试的代码集成在一起，对于开发人员来说，不需要单独学习怎么去完成自动化测试，只需要把自己手工测试的步骤写进一个script就可以了，大幅度降低了学习成本。
是什么
GitLab 是一个基于 git 的仓库管理程序，也是一个方便软件开发的强大完整应用。
简单的理解：它是GitHub 的企业版。GitLab = Git repo + Git Web UI + Gerrit review + Jenkins + Jira + Confluence。
它具备竞争优势的功能是 Code review + GitLab CI。
因为它是单一软件完成了许多软件的工作，所以集成度更高，一些接口不用考虑（如 Gerrit Trigger），同时工作模式也有改变(never push to master branch)，原来的一些概念（change, patch set）也没有了，有了新概念（Fork/Merge Request）。GitLab CI 不是Jenkins 也没有插件，build 代码跟源代码集成在一起，开发人员可以直接修改，不用单独学习怎么使用Jenkins，降低了学习成本。
GitLab 中的一些概念
Fork: GitLab, GitLab 中引入的概念，获取一个独立版本的repo
Group - folder，相当于目录，里边有一些projects
Project： 跟Gerrit 中的Project 概念一致，git 里面叫 repo
Issue：Jira 中的ticket
Plan：Jira 中的 dashboard，对应 GitLab 中的 Issue Board
Milestone：Jira 中的 sprint
GitLab flow
GitLab flow是GitLab官方推荐的分支管理策略，Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
image
分支约定
临时分支：在开发完成会被删除
- 功能分支
feature- 用于新功能的开发，建议以issue-feature-name命名 - 修复分支
fix- 用户bug的修复，建议以issue-fix-name命名
固定分支
- 开发分支
master- 用于发布到测试环境，上游分支为feature和fix，该分支为受保护分支 - 预发分支
pre-production- 用于发布到预发环境，上游分支为master - 正式分支
production- 用于发布到正式环境，上游分支为pre-production
Fork repo
fork 是Github，GitLab特有的概念，是把主repo 拉一个到自己的空间里，开发人员想怎么改都行，不会影响原有的repo。实践中，更多的是用Fork 方式，这样会减少branch，降低维护成本。
测试流程
软件开发阶段一般如下图表示，具体的过程在此之上做了简化。
img
1 网页上开 issue，会得到一个编号
真实环境使用Jira，它更好用，通过配置，可以跟GitLab集成。
在这里为了简化，使用自带的Issue。
以root 身份创建issue。
image-20200107154925278.png
2 Fork repo
以被分配issue 的账户登陆。
image-20200109140515273.png
页面右上角，发现了新 issue 的提醒，点击进去，查看具体信息。
切换到repo页面，fork 它到自己的 namespace。（实践中用 fork 而不是 branch，避免分支太多难以维护。）
3 clone repo
$ git clone git@roy-gitlabce.eastasia.cloudapp.azure.com:royzeng/demo.git
作为测试，随意修改一些文件
$ echo "process test" >> fork.txt
$ git add .
$ git commit -m "fix #5"
commit message 中的 fix是关键字，#5 是 issue 的编号，它们组合起来就能与 issue 关联起来。
4 提交并push到GitLab仓库
$ git push origin master
5 运行GitLab CI
如果之前写好了.gitlab-ci.yml 文件，autobuild 就开始了。
image-20200109143904141.png
6 在GitLab上创建一个Merge Request
Pipeline build 成功后，就可以找人来review 代码了，在 GitLab，这叫做 Merge Request。
image-20200109144423716.png
下个页面提供一些具体信息，让谁来review 代码。
image-20200109144603631.png
7 项目管理者进行代码审查
切换用户，作为代码审查的人，会在自己页面右上角看到 merge request 的图标，点击它。
image-20200106153727426.png
Merge Request 页面包含了许多信息，具体如下
image-20200109150019915.png
接下来看具体的代码，这一部分跟Gerrit review 相似。
image-20200109150556411.png
8 合并到master
image-20200109151519407.png
Merge 之后，回头去看那个issue 已经是 closed 状态了。
9 在master branch 运行第二次GitLab CI
image-20200109151643345.png
网友评论