大家都搭建了测试环境。
有些人很幸运,可以在完全独立的环境中运行生产。
-- 佚名
.
在这一系列文章中,我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题:
- Git 101
- Git 流程(开发流程)
- GitLab 安装
- GitLab 工作流
- GitLab CI/CD
- 包含容器的 CI/CD
第一部分将介绍现代软件开发的基础 – Git 版本控制系统和各种 Git 流程。
Git 101
虽然我们将主要探讨软件开发的概况以及 GitLab 如何帮助我们实现这一目标,但 Git,或者说 Git 设计中的几个基础的高级概念对于更好地理解后面的概念非常重要。
也就是说,Git 是基于这些概念的版本控制系统(还有更多概念,但这几个概念最为重要):
- 非线性开发意味着,虽然我们的软件是从版本 1 到版本 2、再到版本 3 相继发布的,但实际上从版本 1 到版本 2 的升级是并行完成的 – 多名开发者会同时开发许多功能/错误修复。
- 分布式开发意味着开发者独立于一个中央服务器或其他开发者,可以轻松地在自己的环境中进行开发。
- 合并 – 基于前面提到的两个概念,我们会发现很多不同的版本同时存在,我们需要将它们统一成一个完整的状态。
我的意思不是说 Git 发明了这些概念。 Git 并没有发明这些概念, 而是使这些概念变得简单、流行,并加入了多个相关创新概念,也就是说,架构即代码/容器化改变了软件开发。
核心 git 术语
仓库是存储数据以及关于数据的元信息的项目。
- “从物理层面来讲”,仓库是磁盘上的目录。
- 仓库用于存储文件和目录。
- 仓库还会存储每个文件的完整变更历史。
仓库可以:
- 存储在您自己的计算机本地
- 远程存储在远程服务器上
但从 git 的角度来看,本地仓库与远程仓库之间没有特殊的区别。
提交是仓库的固定状态。 很显然,如果每次提交都存储仓库的完整状态,我们的仓库很快就会变得非常大。 因此,提交会存储差异,也就是当前提交与其父提交之间的差异。
不同的提交可以具有不同数量的父提交:
- 0 个 – 仓库中的第一个提交没有父提交。
- 1 个 – 一切如常 - 我们的提交改变了仓库中的某些内容,就像在父提交期间一样
- 2 个 – 当我们有两个不同的仓库状态时,我们可以将它们合并成一个新状态。 该状态和该提交就会有 2 个父提交。
- >2 个 – 当我们将 2 个以上的不同仓库状态合并为一个新状态时,就会有 2 个以上的父提交。 这一概念与我们的讨论并没有特别大的关系,但它确实存在。
现在,对于父提交,每个与之不同的提交都被称为子提交。 每个父提交可以有任意数量的子提交。
分支是对提交的引用(或指针),如下图所示:
该图像显示的仓库具有两个提交(灰色圆圈),第二个圆圈是 master 分支的头部。 在我们添加更多提交后,仓库开始变成下图所示的状态:
这是最简单的情况。 我们的开发者一次负责处理一个更改。 但通常会有很多开发者同时负责处理不同的功能,我们需要使用提交树显示仓库中的变化。
提交树
我们从相同的起始状态开始。 仓库具有两个提交:
但现在,两名开发者在同时工作,为了避免相互干扰,他们在单独的分支中工作:
一段时间后,他们需要合并所做的更改,为此,他们创建了合并请求(也叫拉取请求), 顾名思义,该请求可将两个不同的仓库状态(本例中,我们要将 develop 分支合并到 master 分支中)合并为一个新状态。 接受相应审查并获得批准后,仓库状态如下图所示:
开发继续进行:
Git 101 - 总结
主要概念:
- Git 是一个非线性的分布式版本控制系统。
- 仓库用于存储数据以及关于数据的元信息。
- 提交是仓库的固定状态。
- 分支是对提交的引用。
- 合并请求(也叫拉取请求)是将两个不同的仓库状态合并为一个新状态的请求。
如果您想了解更多关于 Git 的信息,可以阅读相关书籍。
Git 流程
现在,读者已熟悉基本的 Git 术语和概念,我们来探讨一下如何使用 Git 管理软件生命周期的开发部分。很多实践(称为流程)介绍了使用 Git 的开发流程,但我们只会探讨其中两个:
- GitHub 流程
- GitLab 流程
GitHub 流程
GitHub 流程非常简单。 具体如下:
- 从仓库创建一个分支。
- 将更改提交到新分支
- 从您的分支发送一个拉取请求,其中包含您提议的更改,以发起讨论。
- 根据需要在您的分支上提交更多更改。 您的拉取请求将自动更新。
- 在分支准备好合并后,立即合并拉取请求。
我们需要遵守几条规则:
- master 分支始终可部署(并且可正常运行!)
- 不直接在 master 分支中进行开发
- 在功能分支中进行开发
- master 分支 == 生产* 环境**
- 需要尽可能频繁地部署到生产环境
* 不要与“Ensemble 生产”混淆,这里的“生产”是指正式。
** 环境是配置好的代码运行位置,可以是服务器、虚拟机,甚至可以是容器。
如下图所示:
有关 GitHub 流程的更多信息,请参阅此处。 我们还提供了图解指南。
GitHub 流程非常适合小型项目,如果您刚开始使用 Git 流程,可以尝试一下。 不过,GitHub 也会使用 GitHub 流程,因此也可以在大型项目中使用 GitHub 流程。
GitLab 流程
如果您还没有准备好立即部署到生产环境,GitLab 流程提供 GitHub 流程 + 环境。 具体做法是:在功能分支中进行开发(与上例相同),合并到 master 分支中(与上例相同),但这里有一个不同之处: master 分支仅等同于测试环境。 除此之外,还有链接到可能存在的各种其他环境的“环境分支”。
通常存在三个环境(可以根据需要创建更多环境):
- 测试环境 == master 分支
- 预生产环境 == preprod 分支
- 生产环境 == prod 分支
进入其中一个环境分支的代码应立即移至相应的环境中,此流程可通过以下方式完成:
- 自动(我们将在第 2 部分和第 3 部分探讨)
- 半自动(与自动方式相同,唯一的区别是应按下按钮授权部署)
- 手动
完整的流程是:
- 在功能分支中开发功能。
- 对功能分支进行审查并将其合并到 master 分支中。
- 一段时间(合并了多个功能)后,将 master 分支合并到 preprod 分支中
- 一段时间(用户测试等)后,将 preprod 分支合并到 prod 分支中
- 在我们进行合并和测试时,多个新功能已开发完毕并合并到 master 分支中,因此转到 3。
具体如下图所示:
有关 GitLab 流程的更多信息,请参阅此处。
结论
- Git 是一个非线性的分布式版本控制系统。
- Git 流程可用作软件开发周期的准则,有多种 Git 流程可供选择。
链接
- Git 书籍
- GitHub 流程
- GitLab 流程
- Driessen 流程(更全面的流程,用于比较)
- 本文的代码
讨论问题
- 您使用 Git 流程吗? 使用哪一种?
- 您为普通项目使用多少个环境?
后续内容
在接下来的部分中,我们将:
- 安装 GitLab。
- 探讨一些建议的调整。
- 讨论 GitLab 工作流(不要与 GitLab 流程混淆)。
敬请关注。