LinuxCD持续部署核心是“自动发布+可控回滚”闭环，强调版本标识、软链接原子切换、秒级回滚、健康检查熔断及配置与代码分离。
LinuxCD 持续部署不是简单跑个脚本，核心在于“自动发布 + 可控回滚”闭环。关键不在于工具堆砌，而在于流程设计是否让每次上线可预期、可验证、可退守。
发布流程必须带版本标识与原子切换
每次构建产物（如 tar 包、Docker 镜像）必须附带唯一标识：Git commit hash、语义化版本或时间戳+构建号。线上服务不能直接覆盖文件，应采用软链接切换方式：
- 部署目录结构示例：
/opt/app/{v1.2.0, v1.2.1, current} - 新版本解压到独立目录（如
v1.2.1），执行健康检查（HTTP 探针、DB 连通性等） - 检查通过后，
ln -sf v1.2.1 current原子切换，旧版本保留至少 2 个历史版本 - 避免 in-place 修改，防止发布中断导致服务异常
回滚必须是秒级且无需人工干预
回滚不是重新走一遍发布流程，而是快速切回已验证的旧版本链接：
- 回滚命令本质就是
ln -sf v1.2.0 current && systemctl reload app - 所有历史版本目录需保留完整运行时依赖（如 config、log、tmp 子目录可挂载为独立卷或符号链接）
- 建议在 CI 流水线中预置一键回滚 Job，触发时自动读取上一成功版本号并执行切换
- 禁止回滚时重新编译或下载——那已不是回滚，是重发布
健康检查与自动熔断是发布安全阀
发布后若服务不可用，系统应主动中止并触发回滚，而非等待告警响应：
- 部署后立即调用
/healthz或自定义检测脚本（超时 ≤10s，失败重试 ≤2 次） - 检测失败时，自动执行预设回滚逻辑，并记录原因（如 “/healthz 返回 502”）
- 可集成 Prometheus + Alertmanager，在 CPU/错误率突增时联动触发回滚（需提前配置策略）
- 所有检查结果写入日志并推送至钉钉/企业微信，确保可观测
配置与代码必须分离，且配置变更也走同一发布通道
环境配置（数据库地址、密钥、开关）不能硬编码或随代码发布，但也不能绕过 CD 流程单独更新：
- 使用统一配置中心（如 Consul、Nacos）或加密配置文件（SOPS + Age/KMS）存于独立 Git 仓库
- 配置变更提交后，触发专用 Config-Pipeline，校验格式、加密、权限，再推送到目标环境
- 应用启动时从配置中心拉取，或部署时将解密后配置挂载进容器 / 目录
- 配置发布也支持版本化与回滚——改错一个 Redis 地址，也能 3 秒切回去
自动发布和回滚不是功能开关，而是整套协作习惯与基础设施约束的体现。从第一次提交开始就固化版本、隔离配置、定义健康标准，后面才谈得上稳定交付。
