GitLab

GitLab CI/CD

在 Jenkins 中，需要配置各种插件、管理节点（Nodes），并在 Jenkins UI 或 Jenkinsfile 中定义流水线。GitLab CI 将这些概念做了极大的简化，并且更倾向于云原生的思维。

下面这两者的核心概念映射表：

Jenkins 概念 🏗️	GitLab CI 概念 🦊	核心差异与说明
Jenkins Master	GitLab Server	GitLab 代码仓库自带 CI/CD 的调度能力，你不需要像 Jenkins 那样去额外搭建和维护一个独立的控制中心。
Agent / Node / Slave	GitLab Runner	Runner 是实际干活（执行代码构建、测试）的机器。它可以是你局域网里的一台物理机，也可以是云上的动态容器。
Jenkinsfile (Groovy)	`.gitlab-ci.yml` (YAML)	流水线配置文件。GitLab 要求它放在代码仓库的根目录，并使用更具可读性的 YAML 语法，而不是像 Jenkins 那样使用 Groovy 脚本。
Plugins (插件生态)	Docker Images (容器镜像)	这是最大的思维转变。 Jenkins 极度依赖插件（如 Maven 插件、NodeJS 插件），而 GitLab CI 提倡“一切皆容器”。你需要什么环境，就在代码里直接指定对应的 Docker 镜像。
Stage & Step	Stage & Job & Script	层级关系非常相似。一条 Pipeline 包含多个 Stage（阶段），Stage 包含多个平行运行的 Job（任务），Job 中包含具体执行的 Script（脚本命令）。

💡 核心思维转变：从“装插件”到“拉镜像”

核心逻辑：在代码合并到主干之前，如何通过机制来收敛风险。
具体内容：
- 分支策略（Branching Strategy）的本质。
- 分支保护（Protected Branches）：为什么不能让所有人直接 push 到 main。
- Merge Request (MR) 的核心工作流与代码审查（Code Review）。
- 实践：发起一次完整的 MR 流程。

核心逻辑：在代码合并到主干之前，如何通过机制来收敛风险。
具体内容：
- 分支策略（Branching Strategy）的本质。
- 分支保护（Protected Branches）：为什么不能让所有人直接 push 到 main。
- Merge Request (MR) 的核心工作流与代码审查（Code Review）。
- 实践：发起一次完整的 MR 流程。

从第一性原理出发，GitLab 的权限管理本质上是在解决一个经典的安全问题：在复杂的现实团队协作中，如何以最低的管理成本，实现细粒度的基于角色的访问控制（RBAC），并控制操作的“爆炸半径”。

如果把 GitLab 想象成一个文件系统：

GitLab 设计了一条铁律：权限向下继承，且（在开源版中）不可在子层级被削弱。

这意味着，如果你在一个 Group（父文件夹）中赋予了某人较高的权限，他将自动拥有该 Group 下所有 Project（子文件）的同等权限。你只能在具体的 Project 中叠加他的权限，而不能剥夺他从 Group 继承来的权限。

五种核心角色（Role）的本质区别如下：

Guest（访客）：只能看 Issue 和 Wiki，看不到代码（私有项目下）。
Reporter（报告者）：可以拉取（Pull）代码，但不能推送（Push）。适合 QA 查阅代码或非开发人员查看代码。
Developer（开发者）：主力干活的。可以提交代码，创建分支，发起 Merge Request。但不能直接推送到受保护的分支（如 main）。
Maintainer（维护者）：项目的管家。可以合并代码、修改项目设置、配置 CI/CD 变量。
Owner（所有者）：最高权限，通常只有在 Group 级别才有这个角色，可以管理账单、删除群组等。

实验目标：模拟一个真实公司的部门架构，验证成员如何通过加入不同的“组织层级”来自动获取“代码库”的访问权。

使用管理员账号（通常是 root）登录 GitLab。
点击左侧导航栏groups -> Create group。
- Group name 填入：infrastructure-team（基础设施团队）
- Visibility level 选择：Private（私有）
- 点击 Create group。

进入刚刚创建的 infrastructure-team 群组，点击 New project -> Create blank project。
- Project name 填入：k8s-manifests（K8s 部署清单）
- 取消勾选 “Initialize repository with a README”（先建个空库即可）。
回到首页，再建一个独立的项目（不放在任何 Group 下，直接属于 root 用户个人）：
- Project name 填入：hugo-blog-theme
- Visibility level 选择：Private。

进入 Admin Area（左下角扳手图标，或者顶部搜索栏搜索 Admin）。
进入 Users -> New user。
创建用户 A（代表核心骨干）：
- Name: Alice_DevOps
- Username: alice
- Email: alice@example.com
- （创建后点击 Edit 给她设置一个密码，方便一会登录）
同样的方法，创建用户 B（代表外包实习生）：
- Name: Bob_Intern
- Username: bob
- Email: bob@example.com
- （同样设置一个密码）

给 Alice 分配高层级权限：
- 进入刚才的 infrastructure-team 群组页面。
- 点击左侧的 Manage -> Members。
- 点击 Invite members，搜索并选中 Alice_DevOps。
- Role 选择 Maintainer，点击邀请。
给 Bob 分配底层级权限：
- 进入 k8s-manifests 项目页面（注意，不是群组页面）。
- 点击左侧的 Manage -> Members。
- 邀请 Bob_Intern，Role 选择 Reporter。

现在，我们要分别扮演 Alice 和 Bob 来验证结果。