这家伙... 快速、可靠的交付往往决定了产品能否抢占市场先机。很多团队在尝试把手动构建、测试、部署的流程搬上自动化跑道时总会遇到「到底该怎么下手？」的困惑。今天 我把亲身实战经验浓缩成一篇完整的指南，帮助你在 Linux 上用 GitLab 打通 CI和 CD的闭环，让代码从提交到上线只需几分钟。

一、 前置准备：GitLab 与 Runner 的安装

先说说需要有一个可以访问的 GitLab 实例，以及一台或多台可以施行任务的服务器来部署 GitLab Runner。

1. 安装 GitLab

   curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
   sudo apt-get install gitlab-ce
   # 完成后访问 http://your-ip/ 初始化管理员账号
   

2. 安装 GitLab Runner

   # 添加 Runner 软件源
   curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
   # 安装
   sudo apt-get install gitlab-runner
   # 注册
   sudo gitlab-runner register
   # 按提示填写 URL、 Token、描述、标签等信息
   

如果你是大企业，建议使用自托管的 Specific Runner； 谨记... 如果是小团队或个人项目，Shared Runner 已经足够。

Runner 类型对比表

二、编写 .gitlab-ci.yml —— 流水线蓝图出现！

.gitlab-ci.yml 是 CI/CD 的“指挥棒”。它放在项目根目录，一旦代码 push，就会被 GitLab 自动读取并触发相应阶段，造起来。。

# .gitlab-ci.yml 示例
stages:
  - build      # 编译打包
  - test       # 单元/集成测试
  - image      # 构建 Docker 镜像
  - deploy     # 部署到生产/预发布
variables:
  MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"
cache:
  paths:
    - .m2/repository
build_job:
  stage: build
  script:
    - echo "🔧 正在构建 Maven 项目..."
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 hour
test_job:
  stage: test
  script:
    - echo "✅ 开始运行单元测试"
    - mvn test
  dependencies:
    - build_job
docker_image_job:
  stage: image
  image: docker:latest
  services:
    - docker:dind
  script:
    - echo "🐳 构建 Docker 镜像"
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
deploy_job:
  stage: deploy
  environment:
    name: production
    url: https://app.example.com
  script:
    - echo "🚀 部署到生产环境"
    - kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA --record
  only:
    - master   # 主分支合并才会触发部署
# 手动触发平安审计任务
security_scan:
  stage: test
  when: manual   # 在 UI 上点一下就能跑平安扫描啦~
  script:
    - echo "🔍 正在施行平安扫描..."
上面这段脚本已经覆盖了从源码编译到容器化再到 K8s 滚动升级的完整链路。看着每一步都有 emoji 小标记，整个流水线不再枯燥，而是充满仪式感，精辟。。
三、 流水线触发方式——自动 VS 手动 VS Webhook 🎯

自动触发：默认情况下每次 push 到任意分支都会启动对应的 Pipeline；只要把关键 Job 设置为 only/except，即可精细控制。
手动触发：Pipelines 页面点 “Run pipeline”，选择分支或 Tag；也可以在 .gitlab-ci.yml 中使用 when: manual 为特定 Job 加上按钮。
Webhook：If you have external systems  that need to start a build, configure Project → Settings → Webhooks and send a POST request to /api/v4/projects/:id/trigger/pipeline.
 有时候， 你会发现同事忘记推代码导致卡住这时候手动点一下「重跑」按钮，所有人都松了一口气。

四、 进阶技巧：让 CI/CD 更快、更稳、更平安 🚀🚀🚀 
#1 Artifacts 与 Cache 的巧妙配合 
Maven 项目每次都要下载依赖，如果不缓存，每次构建都要花上十几分钟。上文已经演示了将 .m2/repository 放入 cache， 站在你的角度想...  一边把打好的 JAR 用 artifacts 输出给后续阶段，这样即使跑完测试后
部署，也不必重新编译。
#2 多环境部署 & 环境变量管理 
.gitlab-ci.yml 支持 environment 块， 你可以为 dev、staging、production 分别定义不同的 URL 与凭证。配合 secret variables，敏感信息永远不会写进代码库，最终的最终。。
#3 Docker‑Executor 与 BuildKit 加速镜像构建 
PPT你。 A typical improvement is to enable BuildKit and use layer caching:
# 在 runner 配置文件 /etc/gitlab-runner/config.toml 中加入：
]
  ...
    privileged = true                # 必须开启特权模式才能运行 Docker-in-Docker
    disable_entrypoint_overwrite = false 
    shm_size = 0 
    extra_hosts = 
                          # 启用 BuildKit 缓存层 
      enabled = true 
这样即使镜像体积超过几百 MB，也能在几分钟内完成构建。
#4 与 Kubernetes 的深度融合 
K8s 已经成为云原生部署标准。GitLab 提供了 Auto DevOps 模式， 只要你的项目里有 Dockerfile 和 k8s 配置文件，就能“一键”完成滚动更新。下面是一段简洁的 Helm 部署脚本：
- helm upgrade --install myapp ./helm \
    --set image.tag=$CI_COMMIT_SHORT_SHA \
    --namespace prod \
    --wait --timeout=300s 
配合 environment 块，你可以轻松实现灰度发布或蓝绿切换。
#5 通知渠道 & 报告生成 
站在你的角度想... .gitlab-ci.yml 一边支持 Slack、 Microsoft Teams、邮件等通知方式。比方说：
alert_job:
  stage: test
  script: echo "📊 Generating coverage report..."
  artifacts:
    reports:
      junit: reports/junit.xml   # 自动渲染至 Merge Request 页面 
after_script_successful_notification:
   after_script:
       – curl –X POST –H 'Content-type: application/json' –d '{"text":"✅ Pipeline 成功"}' $SLACK_WEBHOOK_URL 
当流水线成功或失败时 团队成员马上收到提醒，再也不用盯着页面刷屏幕。
五、 监控与优化——别让瓶颈悄悄吞噬效率 🔍📈 

Pipelines Overview：Pipelines 页面提供整体耗时柱状图，一眼就能看到哪个阶段最慢；点击具体 Job 可查看实时日志。
CICD Metrics：If you have Premium/Ultimate license, go to Settings → Metrics → CI/CD; re you can see average job duration, success rate, queue time 等关键指标。
 有时候， 我会把日志导出，用 ELK 堆栈做聚合分析——这一步虽稍显繁琐，却让我们对异常有前瞻性的预警能力。
 "优化不是一次性工程， 而是循环迭代". 每次回顾完一次 Sprint，就把发现的慢 Job 拆分或加缓存，让流水线变得越来越轻盈。

六、 ：从“手工”到“自动”，从“慢”到“快” 🚀💡 
回首过去，那些曾经需要花费数小时甚至整天才能完成的编译‑测试‑部署过程，如今只需一次 push 即可结束。借助 Linux 上强大的 GitLab + Runner + Docker/K8s 链条， 别犹豫...  你不仅获得了"快速反馈", 更收获了"质量保障". 项目交付速度提升背后是每一次自动化成功后的那份欣慰——团队成员看见自己的代码瞬间上线，心里涌起说不出的自豪感。
如果你已经按照本文步骤搭建完毕， 不妨给自己的流水线起一个酷炫名字，比方说「闪电侠」或「火箭筒」；让它们成为团队文化的一部分，让每一次 CI/CD 都像是一场小型庆典！祝大家玩得开心，代码飞起来 🚀🚀🚀 。

©2026 技术分享站点 | 作者：小白技术笔记
如有疑问，请关注我们的公众号获取最新实践案例。