基于GitLab的工作流程设计

举报
SUNSKY 发表于 2019/09/02 20:51:17 2019/09/02
【摘要】 GitLab 是一个基于 git 的仓库管理程序,也是一个方便软件开发的强大完整应用。GitLab 拥有一个“用户新人友好”的界面,通过图形界面和命令行界面,使你的工作更加具有效率。GitLab 不仅仅对开发者是一个有用的工具,它甚至可以被集成到你的整个团队中,使得每一个人获得一个独自唯一的平台。GitLab 工作流逻辑符合使用者思维,使得整个平台变得更加易用。相信我,使用一次,你就离不开

2.1.png

GitLab 是一个基于 git 的仓库管理程序,也是一个方便软件开发的强大完整应用。

GitLab 拥有一个“用户新人友好”的界面,通过图形界面和命令行界面,使你的工作更加具有效率。GitLab 不仅仅对开发者是一个有用的工具,它甚至可以被集成到你的整个团队中,使得每一个人获得一个独自唯一的平台。

GitLab 工作流逻辑符合使用者思维,使得整个平台变得更加易用。相信我,使用一次,你就离不开它了!

GitLab 工作流

GitLab 工作流是在软件开发过程中,在使用 GitLab 作为代码托管平台时,可以采取的动作的一个逻辑序列。

GitLab 工作流遵循了提升团队的工作效率以及凝聚力。这种提升,从引入一个新的项目开始,一直到发布这个项目,成为一个产品都有所体现。这就是我们所说的“如何通过最快的速度把一个点子在 10 步之内变成一个产品”。

2.2.png

一般情况下,软件开发经过 10 个主要阶段;GitLab 为这 10 个阶段依次提供了解决方案:

  • IDEA: 每一个从点子开始的项目,通常来源于一次闲聊。在这个阶段,GitLab 集成了Mattermost

  • ISSUE: 最有效的讨论一个点子的方法,就是为这个点子建立一个工单讨论。你的团队和你的合作伙伴可以在工单追踪器issue tracker中帮助你去提升这个点子

  • PLAN: 一旦讨论得到一致的同意,就是开始编码的时候了。但是等等!首先,我们需要优先考虑组织我们的工作流。对于此,我们可以使用工单看板Issue Board。

  • CODE: 现在,当一切准备就绪,我们可以开始写代码了。

  • COMMIT: 当我们为我们的初步成果欢呼的时候,我们就可以在版本控制下,提交代码到功能分支了。

  • TEST: 通过GitLab CI,我们可以运行脚本来构建和测试我们的应用。

  • REVIEW: 一旦脚本成功运行,我们测试和构建成功,我们就可以进行代码复审code review以及批准。

  • STAGING:: 现在是时候将我们的代码部署到演示环境来检查一下,看看是否一切就像我们预估的那样顺畅——或者我们可能仍然需要修改。

  • PRODUCTION: 当一切都如预期,就是部署到生产环境的时候了!

  • FEEDBACK: 现在是时候返回去看我们项目中需要提升的部分了。我们使用周期分析 Cycle Analytics来对当前项目中关键的部分进行的反馈。

简单浏览这些步骤,我们可以发现,提供强大的工具来支持这些步骤是十分重要的。在接下来的部分,我们为 GitLab 的可用工具提供一个简单的概览。

GitLab flow

GitLab flow是GitLab官方推荐的分支管理策略,Gitlab flow 的最大原则叫做”上游优先”(upsteam first),即只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。

2.3.png

持续发布

2.4.png

持续发布适用于web等可以无缝更新的项目。

分支约定

临时分支:在开发完成会被删除

2.b1.png

2.b.png

版本发布

2.5.png

版本发布适用于APP、小程序等有版本规划的项目。

分支约定

临时分支:在开发完成会被删除

2.b2.png

2.b3.png

2.b4.png

2.b5.png

你可以分配这个 MR 给你自己,直到你完成你的工作,然后把它分配给其他人来做一次代码复审。如果有必要的话,这个 MR 可以被重新分配多次,直到你覆盖你所需要的所有复审。

开发完成后,在提交说明里面,可以写上”closes #67″。,只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。

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

WIP MR

2.b6.png

2.14.png

2.b7.png

Code Review 代码审核

一旦你创建一个合并请求,就是你开始从你的团队以及合作方收取反馈的时候了。使用图形界面中的差异比较功能,你可以简单的添加行内注释,以及回复或者解决它们。

你也可以通过点击行号获取每一行代码的链接。

在图形界面中可以看到提交历史,通过提交历史,你可以追踪文件的每一次改变。你可以以行内差异或左右对比的方式浏览它们。

2.6.png

在GitLab Merge Request进行代码审核

如果你遇到合并冲突,可以快速地通过图形界面来解决,或者依据你的需要修改文件来修复冲突。

2.7.png

Issue 工单

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

2.8.png

工单是 GitLab 工作流的第一个重要重要特性。以工单的讨论为开始; 跟踪新点子的改变是一个最好的方式。

这十分有利于:

  • 讨论点子

  • 提交功能建议

  • 提问题

  • 提交错误和故障

  • 获取支持

  • 精细化新代码的引入

每一个在 GitLab 上部署的项目都有一个工单追踪器。找到你的项目中的 Issues > New issue 来创建一个新的工单。建立一个标题来总结要被讨论的主题,并且使用 Markdown 来形容它。看看下面的“专业技巧”来加强你的工单描述。

GitLab 工单追踪器提供了一个额外的实用功能,使得步骤变得更佳易于管理和考虑。下面的部分仔细描述了它。

2.9.png

截止日期

每一个工单允许你填写一个截止日期。有些团队工作时间表安排紧凑,以某种方式去设置一个截止日期来解决问题,是有必要的。这些都可以通过截止日期这一功能实现。

当你对一个多任务项目有截止日期的时候——比如说,一个新的发布活动、项目的启动,或者按阶段追踪任务——你可以使用里程碑

受托者 Assignee

要让某人处理某个工单,可以将其分配给他。你可以任意修改被分配者,直到满足你的需求。这个功能的想法是,一个受托者本身对这个工单负责,直到其将这个工单重新赋予其他人。

这也可以用于按受托者筛选工单。

标签 Lable

GitLab 标签也是 GitLab 流的一个重要组成部分。你可以使用它们来分类你的工单,在工作流中定位,以及通过优先级标签来安装优先级组织它们。

标签使得你与工单看板协同工作,加快工程进度以及组织你的工作流。

常用 Label

对于大型项目, 每个 Issue 至少应该有两个 Label ,一个表示性质,另一个表示优先级。

表示性质的 Label,可以参考这篇文章的范例。

2.10.png

表示优先级的 Label,可以采用下面的级别。

  • 高优先级(High):对系统有重大影响,只有解决它之后,才能去完成其他任务。

  • 普通优先级(Medium):对系统的某个部分有影响,用户的一部分操作会达不到预期效果。

  • 低优先级(Low):对系统的某个部分有影响,用户几乎感知不到。

  • 微不足道(Trivial):对系统的功能没有影响,通常是视觉效果不理想,比如字体和颜色不满意。

看板 Board

在项目中,GitLab 工单看板是一个用于计划以及组织你的工单,使之符合你的项目工作流的工具。

看板包含了与其相关的相应标签,每一个列表包含了相关的被标记的工单,并且以卡片的形式展示出来。

这些卡片可以在列表之间移动,被移动的卡片,其标签将会依据你移动的位置相应更新到列表上。


2.11.gif

里程碑 Milestones

里程碑 是 GitLab 中基于共同的目标、详细的日期追踪你队伍工作的最好工具。

不同情况下的目的是不同的,但是大致是相同的:你有为了达到特定的目标的工单的集合以及正在编码的合并请求。

这个目标基本上可以是任何东西——用来结合团队的工作,在一个截止日期前完成一些事情。例如,发布一个新的版本,启动一个新的产品,在某个日期前完成,或者按季度收尾一些项目。

2.12.png

构建、测试以及发布

GitLab CI

GitLab CI 是一个强大的内建工具,其作用是持续集成、持续发布以及持续分发,它可以按照你希望的运行一些脚本。它的可能性是无止尽的:你可以把它看做是自己运行的命令行。

2.b8.png

2.13.png

使用案例

2.b9.png

反馈:周期分析

当你遵循 GitLab 工作流进行工作,你的团队从点子到产品,在每一个过程的关键部分,你将会在下列时间获得一个 GitLab 周期分析的反馈:

  • Issue: 从创建一个工单,到分配这个工单给一个里程碑或者添加工单到你的工单看板的时间。

  • Plan: 从给工单分配一个里程碑或者把它添加到工单看板,到推送第一次提交的时间。

  • Code: 从第一次提交到提出该合并请求的时间。

  • Test: CI 为了相关合并请求而运行整个过程的时间。

  • Review: 从创建一个合并请求到合并它的时间。

  • Staging: 从合并到发布成为产品的时间。

  • Production(Total): 从创建工单到把代码发布成产品的时间。

参考资料

本文转载自异步社区。

原文链接:https://www.epubit.com/articleDetails?id=NN25b6d9ef-9263-4647-bb26-dc998cc67a82



【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。