使用 GitLab 持续交付 InterSystems 解决方案 – 第 1 部分：Git

大家都搭建了测试环境。

有些人很幸运，可以在完全独立的环境中运行生产。

-- 佚名

.

在这一系列文章中，我想向大家介绍并探讨使用 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 流程非常简单。 具体如下：

1. 从仓库创建一个分支。
2. 将更改提交到新分支
3. 从您的分支发送一个拉取请求，其中包含您提议的更改，以发起讨论。
4. 根据需要在您的分支上提交更多更改。 您的拉取请求将自动更新。
5. 在分支准备好合并后，立即合并拉取请求。

我们需要遵守几条规则：

• master 分支始终可部署（并且可正常运行！）
• 不直接在 master 分支中进行开发
• 在功能分支中进行开发
• master 分支 == 生产* 环境**
• 需要尽可能频繁地部署到生产环境

* 不要与“Ensemble 生产”混淆，这里的“生产”是指正式。

** 环境是配置好的代码运行位置，可以是服务器、虚拟机，甚至可以是容器。

如下图所示：

有关 GitHub 流程的更多信息，请参阅此处。 我们还提供了图解指南。

GitHub 流程非常适合小型项目，如果您刚开始使用 Git 流程，可以尝试一下。 不过，GitHub 也会使用 GitHub 流程，因此也可以在大型项目中使用 GitHub 流程。

GitLab 流程

如果您还没有准备好立即部署到生产环境，GitLab 流程提供 GitHub 流程 + 环境。 具体做法是：在功能分支中进行开发（与上例相同），合并到 master 分支中（与上例相同），但这里有一个不同之处： master 分支仅等同于测试环境。 除此之外，还有链接到可能存在的各种其他环境的“环境分支”。

通常存在三个环境（可以根据需要创建更多环境）：

• 测试环境 == master 分支
• 预生产环境 == preprod 分支
• 生产环境 == prod 分支

进入其中一个环境分支的代码应立即移至相应的环境中，此流程可通过以下方式完成：

• 自动（我们将在第 2 部分和第 3 部分探讨）
• 半自动（与自动方式相同，唯一的区别是应按下按钮授权部署）
• 手动

完整的流程是：

1. 在功能分支中开发功能。
2. 对功能分支进行审查并将其合并到 master 分支中。
3. 一段时间（合并了多个功能）后，将 master 分支合并到 preprod 分支中
4. 一段时间（用户测试等）后，将 preprod 分支合并到 prod 分支中
5. 在我们进行合并和测试时，多个新功能已开发完毕并合并到 master 分支中，因此转到  3。

具体如下图所示：

有关 GitLab 流程的更多信息，请参阅此处。

结论

• Git 是一个非线性的分布式版本控制系统。
• Git 流程可用作软件开发周期的准则，有多种 Git 流程可供选择。

链接

• Git 书籍
• GitHub 流程
• GitLab 流程
• Driessen 流程（更全面的流程，用于比较）
• 本文的代码

讨论问题

• 您使用 Git 流程吗？ 使用哪一种？
• 您为普通项目使用多少个环境？

后续内容

在接下来的部分中，我们将：

• 安装 GitLab。
• 探讨一些建议的调整。
• 讨论 GitLab 工作流（不要与 GitLab 流程混淆）。

敬请关注。