自动化部署遇上测试，问题出在哪
上线前跑一遍自动化测试，再自动部署到预发环境，听起来很顺。可实际操作中，经常遇到测试通过了，部署却卡住，或者部署成功了，服务一访问就报错。这类问题往往不是单一环节出错，而是流程衔接出了毛病。
测试环境和部署环境不一致
最常见的坑是测试用的数据库配置、接口地址和部署时用的根本不一样。比如本地测试连的是开发数据库，部署脚本却指向了正式库的备份，字段少了一个，服务启动直接抛异常。这种问题在CI/CD流水线里尤其隐蔽，因为日志里只显示“连接失败”，得一层层往回查YAML配置文件。
解决办法是统一环境变量来源。用配置中心管理不同环境的参数，测试和部署都从同一个地方取值。比如Kubernetes部署时通过ConfigMap注入，测试阶段也读取同一份快照。
测试通过不代表部署就安全
有个项目曾出现这样的情况：单元测试全绿，集成测试也跑通，但部署后API批量返回500。排查发现，打包脚本把依赖版本写死了，而测试用的是动态拉取最新版。两个环境依赖的SDK差了两个小版本，恰好有个接口行为变了。
这种情况需要在流水线中加入“构建一次，多处运行”原则。测试用的制品包必须和部署的一模一样，不能重新打包。Jenkins或GitLab CI里可以设置缓存产物，测试阶段直接下载构建好的Docker镜像来运行，而不是现场build。
健康检查太简单，误判服务状态
自动化部署常依赖健康检查判断服务是否启动成功。但很多团队写的健康检查只是返回200，不验证数据库连接、缓存连通性等关键依赖。结果部署系统以为服务OK，切了流量，用户一操作就炸。
建议把健康检查分成liveness和readiness。readiness用于判断是否接入流量，必须包含核心依赖检测。例如：
GET /health/readiness
Response:
{
"status": "healthy",
"checks": {
"database": "connected",
"redis": "ok",
"kafka": "reachable"
}
}部署工具如Argo Rollouts可以根据这个接口决定是否继续发布。
回滚机制失效
自动化部署强调快速上线，但很多人忽略了快速回退。曾经有团队在晚上八点上线，测试通过后自动部署生产，结果半小时后发现数据写错表。想回滚却发现历史镜像被清理策略删了，只能手动修数据。
部署策略要配合版本保留规则。Docker镜像打标签时加上时间戳和commit hash，仓库设置保留最近10个版本。同时在CI脚本中加入一键回滚指令，比如kubectl rollout undo deployment/myapp，避免紧急情况下手忙脚乱。
测试数据污染部署环境
有些自动化测试会写入大量模拟数据，如果清理不干净，可能影响下一轮部署或真实用户。比如测试订单功能，生成了几千条测试订单，没清理，上线后运营看报表吓一跳。
解决方案是在测试结束阶段加入清除逻辑，使用独立的测试数据库，并在流水线最后一步执行DROP或TRUNCATE。也可以用事务包裹测试用例，运行完直接回滚。
权限不足导致部署中断
CI/CD工具账号权限设置太严，也会导致部署失败。比如测试能读配置，但部署时无法修改K8s的Deployment副本数。错误信息往往是“Forbidden”，看不出具体缺哪个权限。
建议用最小必要权限原则配置服务账号。先在测试环境模拟部署流程，逐步添加RBAC规则，直到所有操作都能完成。把最终的权限清单固化下来，避免每次换环境重新调试。