Gitlab概览

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

软件开发阶段

gitlab-flow

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的版本管理对于创建分支和合并变得更加容易,也方便项目的管理。

gitlab-flow

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

gitlab-feature-branch

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

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

gitlab-flow-branch

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

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

gitlab-stable-branch

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

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

Issue

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

gitlab-issue

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

Labels

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

gitlab-label

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

Boards

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

gitlab-board

Milestones

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

gitlab-milestones

Merge Request

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

gitlab-mergerequest

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

gitlab-checkout-branch

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

gitlab-protect-branches

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

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

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

gitlab-markdown

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

gitlab-review

WIP MR

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

gitlab-wip-mr

Code Review

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

gitlab-code-review

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

Memebers

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

gitlab-memeber

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

CI/CD

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

gitlab-cicd

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

周期分析

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

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

gitlab-analysis

Markdown Tips

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

## 增加一个新页面
这个 MR 将会为这个项目创建一个包含该 app 概览的 `readme.md`。
Closes #1,#2 and https://gitlab.wenqy.com/group/project/issues/
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/<username>/<projectname>/issues/<xxx>

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

任务列表

在描述里添加 – [] 子任务,划分子任务

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

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

gitlab-md-task

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

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

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

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

总结

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

参考

https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/

https://about.gitlab.com/blog/2014/09/29/gitlab-flow/

https://docs.gitlab.com/ee/topics/gitlab_flow.html

https://docs.gitlab.com/ee/user/markdown.html

https://gitlab.com/gitlab-org/omnibus-gitlab/-/labels

发表评论

电子邮件地址不会被公开。 必填项已用*标注

20 + 8 = ?