Python 紧急热修复的变更管理

热修复不必绕过ci/cd但通常应绕过，因其追求快速可控；需基于线上tag、显式指定requirements路径、禁改版本字段；cherry-pick要审计冲突并最小验证；pip安装须强制重装防缓存；验证需日志标识+指标归零。

热修复必须绕过常规 CI/CD 流水线？

不是必须，但绝大多数情况下应该绕过。CI/CD 流水线通常包含耗时的测试套件、镜像构建、灰度发布检查，而热修复的核心诉求是「快且可控」——git revert 或 git cherry-pick 后直接部署到生产环境补丁分支，比等完整流水线跑完更可靠。

常见错误现象：ModuleNotFoundError: No module named 'xxx' 在热修复后突然出现，其实是 CI 流水线里隐式安装了 dev 依赖（如 pip install -e .[dev]），而热修复用的部署脚本只运行 pip install -r requirements.txt，漏掉了修复所需的临时依赖。

• 热修复分支应基于线上 tag（如 v2.4.1）而非 main 或 develop
• 部署命令必须显式指定 requirements.txt 路径，避免读取错版本（例如 pip install -r ./prod-requirements.txt）
• 禁止在热修复中修改 setup.py 或 pyproject.toml 的版本字段——这会污染版本号语义，后续正式发布会冲突

如何安全地 cherry-pick 单个 commit 到 hotfix 分支？

关键是避免引入无关变更和依赖冲突。cherry-pick 不是复制代码，而是重放 commit 的「差异逻辑」，一旦目标分支缺少前置依赖（比如某个函数定义或配置项），就会失败或静默出错。

使用场景：线上 OrderService.process() 抛 KeyError，本地已定位并修复，对应 commit hash 是 a1b2c3d。

立即学习“Python免费学习笔记（深入）”；

• 先确认目标分支干净：git checkout hotfix/v2.4.1-urgent && git status --porcelain（非空则需处理）
• 执行 git cherry-pick -x a1b2c3d（-x 自动加注原始 commit 引用，便于审计）
• 如果冲突，只解决与修复直接相关的文件（如 order_service.py），绝不要合并 tests/ 或 migrations/ 下的内容
• 完成后立刻运行最小验证集：pytest tests/test_order_service.py::test_process_valid_order -xvs，不跑全量测试

pip install 热修复包时为什么总装错版本？

根本原因是 python 包安装器默认启用 --upgrade-strategy=only-if-needed，而热修复包往往版本号不变（比如仍是 myapp==2.4.1），pip 认为「已满足」就跳过安装，实际却没更新代码。

性能影响：强制重装看似慢，但比因缓存导致旧代码残留引发二次故障代价小得多。

• 部署脚本中必须加 --force-reinstall --no-deps（禁用依赖重装可避免意外升级其他组件）
• 如果用 pip install /path/to/myapp-2.4.1-py3-none-any.whl，确保 wheel 文件名中的 build tag 唯一（例如加 +hotfix.1），否则 pip 会跳过
• 线上环境禁用 pip cache：pip config set global.cache-dir /dev/NULL，防止从旧缓存加载

日志和监控怎么快速确认热修复生效？

不能只看服务是否启动，要验证「修复逻辑是否真实进入执行路径」。很多团队只查 http 200，结果掩盖了异常被静默吞掉的问题。

容易被忽略的地方：热修复引入的 Logging.info() 如果级别高于当前 logger 配置（比如生产是 WARNING），那条日志根本不会输出。

• 在修复代码附近加一行带唯一标识的 debug 日志：logger.debug("[HOTFIX-v2.4.1-order-keyerror] now using fallback key")
• 立刻查日志系统，过滤该字符串 + 时间窗口（5 分钟内），确认有输出；没有就说明代码根本没运行
• 同时检查 metrics：比如修复前每分钟 order_process_error_total{type="KeyError"} 是 120，修复后应趋近于 0，且 order_process_duration_seconds_count 不应突增（否则可能是 fallback 路径太慢）

热修复最危险的环节不是改代码，而是改完之后没验证「它到底有没有跑起来」——所有日志、指标、手动触发路径都得对得上那一行新代码。