GitLab CI

1. 1

   什么是 CI/CD

   设想一个团队，还在用老办法发布一个 Web 应用。有人做完一个功能，在自己的笔记本电脑上跑一遍测试（也可能干脆跳过，因为那天是周五），手工把几个文件拷到服务器上，然后指望别的地方没被弄坏。多数时候还真没事。可总有一周会出事：一个谁都没跑过的测试在生产环境上炸了，或者两个人的部署互相覆盖，团队花掉一整...

   Continuous integrationContinuous deliveryContinuous deploymentPipelinesStagesJobs+2
   20 分钟
2. 2

   你的第一个流水线 (pipeline)

   词汇你现在都有了：流水线、阶段、作业、运行器。可有词汇不等于有把握。此刻，「GitLab 会在你每次推送时自动运行你的脚本」还只是别人下的一个论断，是你读来的，不是你亲眼看着发生的。读一段关于自动化的描述，和自己动手把它触发一次，这中间的差距比听上去要大。在你还没推过一个提交、没亲眼看着一台不归你管...

   .gitlab-ci.yml locationMinimal pipelineSingle jobScript keywordPipeline UIJob logs
   25 分钟
3. 3

   任务 (jobs) 与阶段 (stages)

   上一课里你的流水线只有一个作业 (job)。真实项目从来不会一直这么小。一个真实的项目要编译代码、跑单元测试、跑代码检查，可能还要跑集成测试，最后部署，而这里的每一件事都是一个独立的作业。一旦有了好几个作业，就冒出一个单个作业从来不会引出的新问题：它们按什么顺序跑，哪些可以同时进行？

   Default stagesStage keywordParallel jobs in same stageStages keywordNeeds for DAGJob ordering
   30 分钟
4. 4

   变量和密钥

   一条不管谁推送、推到哪个分支都表现得一模一样的流水线, 分不清预发布环境和生产环境, 也分不清一把真正的部署密钥和一个占位符。任何正经的流水线都需要在运行的那一刻知道一些事情: 自己在构建哪个提交, 是哪个分支触发的, 以及怎么向数据库或者云 API 完成认证, 而又不能把那个密码打印到某个地方,...

   Variables blockPredefined CI variablesCI_COMMIT_SHACI_PROJECT_DIRMasked variablesProtected variables+1
   30 分钟
5. 5

   工件 (artifacts) 和缓存 (caches)

   流水线里的每个作业都从仓库的一次干净检出开始，跑在一个用完即弃的环境里，作业一结束这个环境就被扔掉。这是有意为之的设计，正是它保证了一个作业不会悄悄依赖另一个作业留下的残余状态。但它也带出一个明摆着的问题：如果某个作业编译出了一个二进制文件，或者产出了一份测试报告，或者下载了一个花两分钟才拉完的依赖...

   Artifacts pathsArtifacts expire_inDownloading artifactsCache keyCache pathsArtifacts vs caches
   30 分钟
6. 6

   规则 (rules) 和条件任务 (jobs)

   到目前为止你写的每一个作业 (job)，不管提交落在哪个分支上、也不管流水线 (pipeline) 是因为什么启动的，每次推送都会照跑不误。你一个人做实验时这没什么害处，可一旦有真实的团队在往真实的项目里推代码，害处马上就来了。谁也不希望有人改了 README...

   Rules keywordIf conditionsCI_COMMIT_BRANCHCI_PIPELINE_SOURCEWhen manualChanges paths+1
   30 分钟
7. 7

   Docker 任务 (jobs) 和服务 (services)

   流水线的运行器就是一台空白机器,默认情况下它根本不知道你的项目需要 Python 3.12、某个特定版本的 Node,或者任何别的工具。放着不管,它就把手头那个普通的通用环境丢给你的作业,而真实的测试套件很少能靠这种环境跑起来。更麻烦的是,大多数真实的测试套件要的不只是一个语言运行时,它们需要一个数...

   Image keywordServices keywordPostgres serviceRedis serviceDocker-in-dockerService networking
   35 分钟
8. 8

   环境与部署

   部署作业跑通了。它执行 scp、kubectl apply 或者一个 Ansible 剧本，结果变绿，新版本上线了。接着有人问了一个从流水线页面上答不出来的问题：预发布环境现在到底跑的是什么？是谁放上去的？在周二那次改动之前还是之后？而当答案变成"放错东西了"的时候，凌晨两点，你要怎么快速把上一个版...

   Environment keywordEnvironment nameEnvironment urlDeployment trackingManual production deployDynamic environments+1
   30 分钟
9. 9

   包含 (includes) 和模板 (templates)

   写到第三个项目的时候，.gitlab-ci.yml 就开始互相押韵了。同一个静态检查作业。同一套测试环境，连缓存键都一样。同一段 docker-in-docker 的咒语，从上一个仓库直接抄过来，因为你知道它在那边能跑。头两次复制粘贴确实是对的选择。它不再正确，是在你发现那段共用的 docker...

   Include localInclude projectInclude remoteInclude templateExtends keywordYAML anchors+1
   30 分钟
10. 10

    运行器 (runners)

    这门课到目前为止讲的都是对工作的描述。你写下 script: 里的几行，GitLab 读到它们，然后不知怎么就冒出一个容器，跑完你的测试，再把结果报回来。这个"不知怎么"一直是免费而且看不见的，拿来入门很好，可一旦碰上作业永远卡在 pending、团队的 CI 分钟数每月 12...

    Shared runnersGroup runnersProject runnersDocker executorShell executorKubernetes executor+2
    30 分钟
11. 11

    综合项目. 构建、测试、部署

    这门课的每一课都拿一个玩具作业教一个关键字。学关键字是这么学的，但真正遇到它们时不是这个样子。真实的流水线是所有这些东西一起上，而难点从来不在某一个关键字身上，而在于怎么把它们接起来:...

    Multi-stage pipelineBuild artifactPostgres service testDocker image build and pushManual production deployRules on main
    60 分钟

每一节课、测验和导师回复都以你的语言显示。AI 导师会用你提问的语言来回答。

See how hiring teams interview engineers on GitLab CI, in production-like environments.