在现代化的软件开发生命周期中，手动部署不仅效率低下，且极易引入人为错误。GitLab CI/CD 作为内置于 GitLab 平台的强大工具，能够自动执行代码测试、构建和部署任务。本文将通过一个具体的实战案例，指导你如何配置 .gitlab-ci.yml 文件，实现从代码提交到服务器自动部署的完整闭环。无论你是刚接触 DevOps 的新手，还是希望优化现有流程的开发人员，这份步骤清单都能帮助你快速上手。
第一步：初始化项目与创建 Runner
一切始于你的 GitLab 仓库。首先，确保你的项目已托管在 GitLab 上，并且拥有相应的读写权限。接下来，最关键的一步是注册并配置 GitLab Runner。Runner 是实际执行 CI/CD 任务的代理程序。你可以选择共享 Runner（由 GitLab 管理员提供）或自建专用 Runner。对于独立开发者或小团队，推荐使用 Docker-in-Docker (DinD) 方式自建 Runner，以确保环境隔离和灵活性。
安装 Runner 后，你需要将其注册到你的项目中。在 GitLab 项目的 “Settings” > “CI/CD” > “Runners” 页面获取 Registration Token。运行 sudo gitlab-runner register 命令，输入 Token，选择 Executor 为 Docker，并指定默认镜像（如 node:latest 或 python:3.9）。这一步确保了当代码推送时，有一个可用的计算资源来执行后续脚本。
第二步：编写 .gitlab-ci.yml 配置文件
.gitlab-ci.yml 是 GitLab CI/CD 的核心，它定义了流水线的结构、阶段和具体指令。我们需要创建一个清晰的阶段划分，通常包括 lint（代码检查）、test（单元测试）、build（构建）和 deploy（部署）。
以下是一个典型的 YAML 配置示例：
stages:
- lint
- test
- build
- deploy
lint_job:
stage: lint
script:
- npm run lint
test_job:
stage: test
script:
- npm install
- npm test
build_job:
stage: build
script:
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 week
deploy_job:
stage: deploy
only:
- main
script:
- echo "Deploying to production..."
- scp -r dist/* user@server:/var/www/html/
在上述配置中，我们定义了四个阶段。Lint 和 Test 阶段用于保证代码质量；Build 阶段生成产物并通过 artifacts 上传，以便后续阶段使用；Deploy 阶段则仅在 main 分支合并时触发，通过 SSH 将构建好的文件传输到目标服务器。请注意，实际生产中建议使用更安全的密钥管理方案（如 GitLab Variables）来处理 SSH 密码或私钥。
第三步：验证流水线与故障排除
保存 .gitlab-ci.yml 并提交到仓库后，GitLab 会自动触发一次流水线。前往项目的 “CI/CD” > “Pipelines” 页面，观察各个 Job 的状态。如果某个阶段失败，点击该 Job 查看日志。常见的错误包括依赖安装失败、测试用例未通过或 SSH 连接超时。
若遇到 Runner 无法调度任务的问题，请检查 Runner 的标签（Tags）是否与 YAML 中的 tags 字段匹配，以及 Docker 服务是否正常运行。此外，确保服务器的防火墙开放了必要的端口，并正确配置了 SSH 免密登录或密钥认证，以避免部署时的交互阻塞。通过反复调试和优化，你将建立起稳定、高效的自动化部署流程，显著提升交付速度与代码可靠性。