基础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/workflows/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 报错——这些细节比选什么工具重要十倍。
