Linux CI/CD实践核心是建立可预测、可验证、可回滚的交付节奏，关键环节包括：单一源码仓库+PR/Code Review、编译/扫描/测试三件套准入准出、带唯一标识的构建产物、容器化CI环境、Ansible/Terraform管理配置与基础设施、部署后健康检查与自动回滚、Trivy扫描/Syft漏洞阻断及GPG签名等安全嵌入。
Linux 环境下的 CI/CD 实践，核心不是堆工具，而是让代码从提交到上线的每一步都可预测、可验证、可回滚。关键在于用自动化堵住人工操作带来的不确定性，尤其在配置管理、环境一致性、安全卡点这些容易出问题的环节。
构建稳定可靠的流水线基础
流水线不是越长越好，而是每个阶段都要有明确的准入和准出标准：
- 使用单一源码仓库（如 Git），所有变更必须走 Pull Request + Code Review 流程，禁止直接向 main 分支推送
- 每次提交触发的构建任务，必须包含编译（如 make / mvn）、静态扫描（如 shellcheck、bandit）、单元测试三件套，任一失败即中断后续流程
- 构建产物（二进制、Docker 镜像、RPM 包）需带唯一标识（如 git commit hash + timestamp），禁止使用 latest 标签用于部署
- CI 运行环境统一基于容器（如 Ubuntu 22.04 LTS 镜像），避免“在我机器上能跑”的问题
环境管理与配置自动注入
Linux 服务部署最常踩的坑，往往来自环境差异。不能靠文档或口头约定，要靠代码和脚本固化：
- 用 Ansible 或 SaltStack 管理服务器初始化，包括用户、防火墙、时区、NTP、日志轮转等共性配置，所有 Playbook 存入版本库
- 敏感配置（数据库密码、API Key）不写进代码，改用 HashiCorp Vault 或 Kubernetes Secret + external-secrets 同步；非敏感配置（端口、超时时间）通过 CI 变量或 configmap 模板动态生成
- 预发（staging）和生产（prod）环境的基础设施差异，用 Terraform 的 workspace 或 environment 变量区分，但底层模块完全复用，杜绝“两套模板”
部署与健康验证闭环
部署完成≠服务可用。真正的 CD 要求系统自己证明它已就绪：
- 部署后立即执行轻量级冒烟检查：curl -f http://localhost:8080/health，返回 200 且含 "status":"up" 才算通过
- 对 systemd 服务，用 systemctl is-active --quiet your-app && systemctl is-failed --quiet your-app 双重校验状态
- Kubernetes 场景下，kubectl wait --for=condition=Ready pod -l app=myapp --timeout=120s 是标配；再加一条 kubectl get endpoints myapp -o jsonpath='{.subsets[*].addresses[*].ip}' 验证服务发现是否生效
- 任何一步验证失败，自动回滚至上一可用版本（如 systemctl rollback your-app.service 或 helm rollback）并通知负责人
安全与合规嵌入交付链路
安全不是发布前最后一道闸门，而是贯穿每次构建和部署的默认行为：
- CI 阶段集成 Trivy 或 Syft 扫描 Docker 镜像，阻断 CVE-2023 及以上严重漏洞的镜像进入制品库
- 对部署到生产环境的 RPM/DEB 包，强制签名（rpm --addsign）并验证 GPG 签名后再安装
- 所有运维操作（如 ansible-playbook 执行、kubectl apply）必须记录操作人、时间、commit ID，日志推送到集中审计系统（如 ELK 或 Loki）
- 定期用 OpenSCAP 扫描线上主机基线合规性，结果作为 CD 流水线的可选质量门禁（例如：关键项不合规则禁止新版本上线）
