📚 课程目录第2章 CI环境搭建

2. CI 环境搭建：版本控制系统与 CI 服务器的选择与安装

说到 CI 环境搭建，很多团队第一步就摔跟头。版本控制选错了，服务器架错了，后面全白干。我的经验是——先把地基夯实在说别的。

2.1 版本控制系统：为什么非 Git 不可？

其实可选的不多。SVN、Hg、Git……但你看现在业内，Git 几乎是唯一答案。我不否认其他工具在某些场景仍有价值，但你要是做 CI/CD，就别纠结了。

Git 强在哪？

分布式：每个开发者本地有完整仓库，不怕服务器挂。
分支轻量：创建、切换、合并几乎无成本。这在 CI 流水线中太重要了——你想想看，每次提交触发打包、测试、部署，分支就是流水线的入口。
生态成熟：GitHub、GitLab、Bitbucket 全是基于 Git 的。Jenkins 也好、GitLab CI 也罢，原生支持 Git。

核心建议：采用 Git Flow 或 GitHub Flow。我个人偏向 GitHub Flow —— master 分支永远可部署，所有开发在 feature 分支上进行，PR 合并后自动触发 CI。对中小团队来说，简单、清晰、够用。

我记得有次帮一个团队从 SVN 切换到 Git。他们之前 CI 基于 SVN 钩子，每次提交后等脚本拉取、构建、测试，光全量检出就要好几分钟。切到 Git 后，增量拉取 + 分支策略，CI 首次执行时间缩短到 30 秒。差别就是这么大。

安装 Git 很简单，直接官网下或者用包管理器：

# Ubuntu/Debian
sudo apt install git

# macOS
brew install git

# 验证
git --version

嗯，这里要注意：配好全局用户名和邮箱，否则后面 PR 提交、代码审查会乱套。

git config --global user.name "你的名字"
git config --global user.email "your-email@example.com"

2.2 CI 服务器选型：Jenkins、GitLab CI、GitHub Actions 怎么挑？

很多新同学问：哪个 CI 工具最好？我的回答是：没有最好，只有最合适。下面这张表是我这些年做咨询总结的血泪对比——

工具	安装方式	优势	劣势	适合场景
Jenkins	自托管（Java + 插件）	高度可定制，插件生态丰富，支持任意语言	插件兼容问题多，维护成本高，UI 老旧	大型企业、复杂流水线、需要深度定制的团队
GitLab CI	自带（GitLab 集成）	与仓库深度集成，Runner 架构灵活，YAML 配置清晰	高级功能需付费，自托管 GitLab 资源占用较高	使用 GitLab 的中大型项目、对自有代码安全要求高的团队
GitHub Actions	云原生（无需安装）	零运维，市场丰富，社区活跃，免费额度慷慨	私有化部署困难，对非 GitHub 仓库配合度差	开源项目、中小团队、GitHub 深度用户

说白了，如果你在 GitHub 上做开源，别犹豫，直接用 Actions。如果你公司已经有自建的 GitLab 实例，GitLab CI 是自然之选。Jenkins？除非你团队有专职运维且需要控制每一个细节，否则我建议慎重——我在项目中遇到过 Jenkins 插件升级后流水线全部红掉的情况，那叫一个酸爽。

2.3 安装实操：三分钟上手

下面给出最典型的安装命令，你可以根据自家环境直接复制。

Jenkins 安装（基于 Docker，推荐）

docker run -d --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts

运行后访问 http://your-server:8080，第一次会要求你输入初始密码。密码可以在容器日志中看到：

docker logs jenkins 2>&1 | grep -A 5 "Please use the following"

避坑指南：我曾经因为忘了持久化 jenkins_home 卷，升级后所有作业和配置全部丢失。所以一定、一定、一定要挂载宿主目录或持久化卷。另外，如果你在 K8s 里跑 Jenkins，别忘了给 Agent 分配足够的临时存储。

GitLab CI 集成（几乎无需单独安装）

GitLab CI 的核心是 Runner。只需要注册 Runner 即可：

# 安装 Runner
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner

# 注册（ 从 GitLab 项目 Settings → CI/CD → Runners 获取）
sudo gitlab-runner register \
  --url https://gitlab.com/ \
  --registration- YOUR_ \
  --executor docker \
  --description "my-runner" \
  --docker-image alpine:latest \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock

注册成功后，在项目根目录创建 .gitlab-ci.yml，写你的流水线任务。比如最简单的：

stages:
  - build
  - test

build-job:
  stage: build
  script: echo "编译中..."

test-job:
  stage: test
  script: echo "运行测试..."

GitHub Actions（零安装）

完全不需要安装任何服务。在仓库根目录创建 .github/workflows/ 目录，里面放 YAML 文件即可。比如 ci.yml：

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: echo "代码已检出"
      - run: npm install && npm test

提交后自动触发。是不是超简单？我个人习惯是，小项目直接上 Actions，省心省力；大项目或对安全敏感的，会选 GitLab CI 或 Jenkins。

2.4 知识体系总览

下面这张图把本章的核心脉络串起来了。你可以看到版本控制、CI 服务器、触发机制三者之间的关系。

我的小技巧： 无论选哪个 CI 服务器，都保持 .gitignore 统一，README.md 规范。很多团队在搭建环境时只顾着装工具，却忘了定义代码结构规范。没有规范，CI 流水线再强也是白搭。

2.5 踩过的坑，写出来让你少走弯路

密钥管理：我曾经直接把 SSH 密钥写在 Jenkins 构建脚本里，后来仓库被 fork 出去……教训惨重。所有凭据走凭据管理工具（Jenkins Credentials / GitLab CI Variables / GitHub Secrets）。
并发限制：GitLab CI 默认并发数很小，如果你团队比较大，记得调整 Runner 的 concurrent 参数。否则一个任务占着 runner，后面的全部排队。
环境隔离：千万、千万、千万别在同一个 Agent 上混跑不同项目的构建。依赖冲突、文件残留够你折腾一周。我用 Docker 执行器已经四年了，从来没出过环境问题。

嗯，CI 环境搭建说深不深，说浅不浅。版本控制选 Git 不用讨论，CI 服务器按场景挑就行。安装也就几行命令。但真正容易出问题的地方，往往是那些“你以为没问题”的细节——凭据、磁盘、网络。希望能帮大家避掉几个大坑。