Gitlab概览 | 小温之家—行走在猿类世界

DevOps Gitlab

Gitlab是开源的基于Git的仓库管理系统，也可以管理软件开发的整个生命周期，是项目管理和代码托管平台，支撑着整个DevOps的生命周期。Gitlab很容易选为GitHub\码云\gogs\gitea的替代品，作为公司私有库管理的工具。我们可以用Gitlab Workflow来协同整个团队的软件开发管理过程。

软件开发阶段

wps1

Gitlab工作流将软件开发定义为10个阶段，并提供相应的解决方案，帮助团队高效协作，完成项目开发。

IDEA	项目的通常来自一个idea的诞生，idea可能来自某次闲聊。Gitlab集成Mattermost，提供内部通讯工具。（默认未开启）
ISSUE	为IDEA建个ISSUE讨论，团队成员追踪、讨论、提升
PLAN	讨论达成一致，需要优化和组织工作流，可以利用ISSUE Board
CODE	准备就绪，进入编码阶段
COMMIT	利用版本控制，提交代码到功能分支
TEST	利用GitLab CI，可以运行脚本来构建和测试应用
REVIEW	构建和测试成功后，可以进行代码复审
STAGING	部署代码到演示环境，检查是否符合期望，以便及时调整
PRODUCTION	如预期顺畅，部署应用到生产环境
FEEDBACK	回顾项目，利用Cycle Analytics对关键部分反馈，总结和提升

Gitlab flow

区别于SVN等版本控制系统，基于Git的版本管理对于创建分支和合并变得更加容易，也方便项目的管理。

wps1-1597111300349

利用工单追踪，将功能特征驱动开发和功能特征分支有机结合在一起。受保护的分支对于权限较低开发者等角色需要通过发起合并请求，复核评审通过后最终才能合并到保护分支。GitLab flow是GitLab官方推荐的分支管理策略。我们可以在原则上约定：分支分为永久分支和临时分支，都是在master分支以外建立。永久分支不会被删除，包括主分支master，准生产分支pre-production，生产分支production。临时分支分为Feature特征分支和Fix修复分支，在开发完成会被删除。一种简单的方案，通常可以基于最新的master主分支，创建特征分支，进行特征开发，最后合并请求到master分支。

wps2

只有一个master主分支，这样的好处在于，可以代码及时合并，可以是本地代码库存量最小，也可以更快的持续交付。当然，与此同时，部署、环境、集成等相关问题也没得到很好的解决。

对于每一次分支合并，我们总是期望可以部署一个稳定的版本。我们可以考虑多环境分支的情况。

wps3

Gitlab flow 的最大原则叫做"上游优先"（upsteam first）。代码的变化，必须由“上游”向“下游”发展。Feature和Fix是master的“上游”，master是pre-production的上游，pre-production是production的“上游”。比如，生产环境出现了bug 或者要开发新的feature，这时就要建一个临时Hotfix或Feature分支，开发完成把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。Feature和Fix在开发人员在开发环境部署测试，master在测试环境中部署测试，pre-production在演示环境中部署测试，production在生产环境发布，一条流水线下来，可以持续完成项目的部署交付。

此外，我们可以有多稳定版本的分支策略，用于将软件发布给外界。

wps4

版本发布适用于APP、小程序等有版本规划的项目。稳定分支以master为起点，并尽可能晚地创建。通过尽可能晚的分支，可以最大程度地减少将错误修正应用于多个分支的时间。在master上打出稳定的分支版本。如果稳定分支发行后，出现bug，可以先将错误修复到master，然后cherry-picked到稳定分支，我们可以通过设置Tag来提高补丁版本，可以维护一个稳定分支专门指向最新版本发布的分支提交。

此外，我们可以对分支名称做个约定，在Gitlab上基于issue创建的分支默认是issue编号+issue标题等等。

Issue

GitLab 有一个强大的工单追溯系统，在使用过程中，允许你和你的团队，以及你的合作者分享和讨论建议。所有的开发工作都应该以工单任务为导向。

我们可以填写是否私密、受托人、截止日期、标签 、里程碑等信息，利用这些信息可以更加方便地组织活动和安排优先级。

Labels

GitLab 标签也是Gitlab flow的重要组成部分，可以对issue工单进行分类和定位。也可以通过定义优先级标签组织它们。通常和Boards一起，来组织计划和工作流程。

我们可以根据需要设计一些常用标签，如待办类，Bug类，功能改进类等进行定位、统计和跟踪。

Boards

Gitlab 工单面板是一个用于计划以及组织工单，使之符合项目工作流的工具。Boards包含了与其相关的对应标签，每一个列表包含了相关的被标记的issue工单，并且以卡片的形式展示出来。这些issue卡片可以在列表之间推拽移动，被移动的卡片，其标签将会依据你移动的位置更新到相应列表上。

Milestones

Milestones 是GitLab 中基于共同目标、时间进度追踪团队工作的最好工具。它定义了目标阶段对应的工单集合和合并请求。通常是团队协作在截止日期完成某个目标。例如，发布一个新的版本，启动一个新的产品，在某个日期前完成，或者按季度收尾一些项目。

Merge Request

我们可以根据issue创建branch和发起Merge Requests(MR)合并到目标分支。

开发者检出特征分支开发，提交后并推送到远程。功能分支和修复分支合并进master分支，必须通过Merge Requests。审核员可以对这些提交和变化进行评审，可以反复这个过程，直到符合代码规范，才合并到目标分支。

master分支应该受到保护，不是每个人都可以直接修改这个分支，以及拥有审批 Merge Request的权力。

上图展示了保护分支的权限设置，规定了哪些角色具有Branch的MR和push的权限。否则，推送无权限的分支时可能会出现以下错误：

you are not allowed to push code to protected branches on this project

每一次 MR 都会有一个标题（这个标题总结了这次的改动）并且一个用 Markdown 书写的描述。在描述中，你可以简单的描述该 MR 做了什么，涉及的任何工单和 MR（在它们之间创建联系），并且，你也可以添加个关闭工单模式，当该MR 被合并的时候，相关联的工单就会自动被关闭。在描述里添加 Closes #xxx，xxx为对应的issue编号。Merge成功后，自动关闭工单。

有权限角色在Merge RequestMerge 前，注意下Merge的内容，评审通过后，最好能确保每一次Merge后对应Master分支都是稳定的。

WIP MR

WIP (Work in Process) MR,避免 MR 在准备就绪前被合并。只需要添加 WIP: 在 MR 的标题开头，它将不会被合并，除非你把 WIP: 删除。当你改动已经准备好被合并，编辑工单来手动删除 WIP: 。或者使用快捷方式，只需要在评论或者 MR 描述中输入斜线命令**/wip**并提交即可快速添加到合并请求中。

Code Review

一旦你创建一个合并请求，审核方收到反馈，就可以决定是否合并这个请求了。审核者可以进行差异比较，回复或者解决它们。在图形界面中可以看到提交历史，通过提交历史，你可以追踪文件的每一次改变。你可以以行内差异或左右对比的方式浏览它们,甚至评论他们。

如果有合并冲突，甚至可以在线编辑解决。

Memebers

项目拥有者和维护者需要添加协作的团队成员，进行项目协同，可以选择已注册gitlab的有效成员进行邀请。

受邀人会受到电子邮件，同意后就可以加入团队了。低权限角色只能开发，甚至只能浏览，无权限维护。

CI/CD

GitLab CI/CD是构建项目持续集成、持续部署和持续交付的有效工具。首先需要在项目根目录下创建文件.gitlab-ci.yml。

wps1-1597128155459

例如，我们可以在项目中每一次Merge Request，都可以触发pipeline 去构建、测试和部署。而具体的构建规则可以根据编写不同的.gitlab-ci.yaml脚本实现。CI/CD pipelines的运行离不开Gitlab Runner。所以，还需要安装GitLab Runner，它可以在任何地方（能ping通Gitlab）运行，也可以是以Shell、docker、kubernetes等不同的形式运行。GitLab Runner向Gitlab注册，需要Gitlab授权。注册成功后，GitLab Runners负责从Gitlab拉取代码进行构建、测试和部署。区别于Jenkins，Gitlab-CI更加适合DevOps人员，开发与运维是同一个人，非常适合敏捷开发。Jenkins通过Hook可以使编译服务和代码仓库分离，耦合度低，适合多角色团队，职责分明。将另有篇幅概述，这一块暂不赘述。

周期分析

我们可以通过周期分析，可以查看各个阶段的统计，及时反馈项目的进展和改进项目的不足之处。

Issue	从创建一个工单，到分配这个工单给一个里程碑或者添加工单到你的工单看板的时间
Plan	从给工单分配一个里程碑或者把它添加到工单看板，到推送第一次提交的时间
Code	从第一次提交到提出该合并请求的时间
Test	CI 为了相关合并请求而运行整个过程的时间
Review	从创建一个合并请求到合并它的时间
Staging	从合并到发布成为产品的时间
Production（Total）	从创建工单到把代码发布成产品的时间

Markdown Tips

在Issue 或 Merge Request 等对应的markdown描述或者git commit -m ""注释信息中，可以添加特殊标识来实现一些特性。可以看下简单的例子：

## 增加一个新页面
这个 MR 将会为这个项目创建一个包含该 app 概览的 `readme.md`。
Closes #1,#2 and https://gitlab.wenqy.com/group/project/issues/<8>
related to #3
:smile:
/cc @wenqy @all

上面是MR的一段描述。合并时，会关闭编号为1,2的issue工单，以及url指向的项目工单。这还做了一个编号为3的issue工单关联，不会关闭。并邮件通知用户。还支持emoji表情。

添加关闭工单样式到你的 MR 以便可以使用【GitLab周期分析】追踪你的项目进展，是十分重要的。它将会追踪“CODE”阶段，衡量第一次提交及创建一个相关的合并请求所间隔的时间。

第一次提交

第一次提交时添加一个关联的Issue编号，利用Ref #关联

git commit -m "this is my commit message. Ref #xxx"

或者使用全称Related to关联

git commit -m "this is my commit message. Related to https://gitlab.com///issues/"

链接第一次提交与Issue，将有助于【GitLab周期分析】跟踪工作流程，它将度量计划该Issue的实现所用的时间，即从创建Issue到进行第一次提交之间的时间。

任务列表

在描述里添加 - [] 子任务，划分子任务

- [x] Completed task 
- [ ] Incomplete task 
	- [ ] Sub-task 1 
	- [x] Sub-task 2 
	- [ ] Sub-task

描述里面体现子任务的列表

wps2-1597131562201

此外，markdown描述里输入#，触发已有issue下拉；输入！，触发已有MR下拉；输入/，触发命令；输入:，触发emoji

在CI中还可以在git commit 注释里添加[ci skip]跳过CI等等。

此外，还可以对Issue和Merge Request等描述定义描述模板，规范描述。

Gitlab还有wiki和代码片段等知识库的管理和分享功能，方便团队规范行为。

总结

Gitlab开源免费，可以自建gitlab。它清晰且直观地划分了软件开发管理的各个阶段，可以无缝衔接过渡到每个阶段。它能预测和控制项目的生命周期，整个平台很容易上手和使用，以自己的工作流管理项目的整个生命周期非常方便，轻量而敏捷，甚至可以说是一体化管理，为敏捷而生，是一个值得推荐的协同开发项目管理工具。