将落后master的PR部署到Prod后出现非预期特性的问题排查与方案咨询

可能的原因 #

• 镜像拉取/使用错误：部署脚本未指定唯一的镜像tag（比如误用了latest），导致实际运行的是master分支构建的镜像，而非目标PR的镜像。即使目标镜像已构建成功，若tag被覆盖或拉取逻辑错误，就会出现这种情况。
• Docker构建缓存污染：构建镜像时依赖了旧的缓存层，比如COPY代码前的层未失效，或者使用了--cache-from拉取了master分支的缓存镜像，导致最终镜像包含了未预期的特性代码。
• 环境配置触发特性：该特性是通过配置而非代码控制的，比如配置文件中开启了特性开关，即使分支代码不含该特性，生产环境的配置仍会触发特性生效。
• 部署目标未完全替换：旧的包含该特性的实例未被彻底终止或流量未完全切到新实例，比如滚动部署时旧实例仍在处理请求，或者部署到了错误的集群节点。
• Datadog记录与实际部署不一致：CI/CD流程触发了Datadog的部署记录上报，但实际部署步骤（如容器启动、流量切换）未成功执行，生产环境仍运行旧版本。
• 版本控制隐藏问题：虽然提交记录看起来正确，但可能存在未发现的submodule依赖（submodule指向了master分支），或者cherry-pick时的冲突未彻底解决，导致代码隐含了目标特性。

核心方案 #

• 使用唯一镜像tag：为每个PR或提交生成唯一的tag（如commit hash、pr-xxx-v1），部署时明确指定该tag，绝对避免使用latest这类易被覆盖的tag。
• 特性开关（Feature Flag）：将所有新特性用开关包裹，代码合并到master后通过配置控制特性是否生效。这种方式无需特意维护落后于master的分支，直接从master部署，通过开关灵活控制上线范围，是当前最常用的方案。
• 专用Release分支：若需部署特定变更，从master中cherry-pick需要的提交到专门的release分支，仅合并经过验证的必要变更，再部署该release分支。避免直接部署落后于master的长期分支，减少冲突和维护成本。
• 蓝绿/金丝雀部署：部署新版本时先启动独立的实例组（蓝环境），验证通过后再将流量切到蓝环境，绿环境保留至确认无误后销毁。这种方式能快速回滚，且确保流量只流向正确版本。
• CI/CD全流程校验：
  • 构建阶段：增加代码静态检查，确认分支不含禁止的特性代码；构建镜像后，扫描镜像内容与目标分支代码一致性。
  • 预部署阶段：在staging环境运行自动化测试，验证禁止的特性未生效。
  • 部署后：自动执行冒烟测试，检查生产环境的特性状态，同时监控日志和指标确认版本正确性。
• 严格的实例生命周期管理：部署时确保旧实例被彻底终止，流量100%切换到新实例；使用编排工具（如Kubernetes）的滚动更新策略，配置合理的健康检查，避免旧实例继续处理请求。

内容的提问来源于stack exchange，提问作者Ishita