基础DevOps环境核心是git push自动触发可追溯的构建、测试、部署；工具选型应依代码托管平台而定，GitLab用.gitlab-ci.yml，GitHub用GitHub Actions；CI必须执行lint、test、build三步且顺序不可颠倒；Docker镜像推荐本地registry:2快速验证，生产需配认证；环境细节比工具选择更重要。

基础 DevOps 环境不是“装一堆工具就完事”，核心是让 git push 能自动触发构建、测试、部署，且每一步可追溯、失败能快速定位。没这根主线，工具堆得再全也是摆设。

用 GitLab CI 还是 GitHub Actions？看你的代码托管在哪

别纠结“哪个更好”，先看代码仓库位置——迁移成本远高于学习成本。

• 代码在 GitLab：直接用 .gitlab-ci.yml，内置 Runner 配置简单，gitlab-runner register 后基本开箱即用
• 代码在 GitHub：选 GitHub Actions，.github/wor

  

  kflows/ci.yml 语法更直观，但自建 Runner 需手动维护 actions-runner 服务
• 混合使用（比如 GitLab 托管代码 + GitHub Actions）会引入权限同步、Webhook 冲突等隐性问题，不建议新手尝试

CI 流水线里必须跑的三件事：lint、test、build

跳过任意一项，后续环节都在放大风险。尤其 lint 和 test 必须在 build 前执行，否则无效镜像可能被推到仓库。

• lint 阶段用 eslint（前端）或 gofmt（Go）这类快反馈工具，超时应设为 60s 内，避免阻塞流水线
• test 阶段优先跑单元测试（npm test 或 go test -short），集成测试放单独 job，用 needs 或 if: always() 控制依赖
• build 阶段生成制品（如 Docker 镜像），务必带 git commit SHA 作为镜像 tag，例如 docker build -t myapp:${CI_COMMIT_SHORT_SHA} .

Docker 镜像推到哪？本地 Registry 就够用，别一上来就搞 Harbor

Harbor 功能强，但配置 TLS、LDAP、项目权限要花半天，而本地 registry:2 容器 3 条命令就能跑起来，适合验证流程。

• 启动命令：docker run -d -p 5000:5000 --restart=always --name registry registry:2
• 推送前加 docker login -u foo -p bar http://localhost:5000（默认无认证，生产必须关掉 REGISTRY_HTTP_ADDR 并配 Nginx 反代加 Basic Auth）
• 镜像名必须含地址，例如 localhost:5000/myapp:${CI_COMMIT_SHORT_SHA}，否则 docker push 默认走 Docker Hub

真正卡住人的往往不是工具安装，而是环境变量没透传、Docker daemon 权限没放开、或者 .gitignore 误删了 node_modules 导致本地能跑 CI 报错——这些细节比选什么工具重要十倍。