应用开发中的功能冻结与代码冻结：本质、区别及运作方式

什么是功能冻结？

Feature freeze — 在计划发布前临时禁止向代码库添加新功能。团队停止合并功能，转而修复错误、优化和打磨现有代码。开发人员仅在错误修复框架内完成未完成的功能，不扩大范围。

功能冻结解决了未完成功能（work-in-progress）的问题，这些功能未能及时完成发布但已部分合并到主分支。如果继续添加新功能，回归风险会增加：每次新集成都需要重新测试已完成的模块。Feature freeze 固定了发布范围，将其从移动目标转变为稳定的功能集。

重要说明：feature freeze ≠ code freeze。在功能冻结期间，允许错误修复、重构、更新依赖项和文档。仅禁止新的用户面向功能（user-facing features），即任何从用户角度改变应用程序行为的代码。代码审查检查：如果 PR 添加新屏幕、按钮或 API 方法 —— 将被拒绝，直到冻结解除。

什么是代码冻结？与功能冻结有何不同

Code freeze（代码冻结）——更严格的实践，代码中的任何变更都被完全禁止。即使错误修复也不允许，除非是关键的。代码冻结在短期内（通常 24-48 小时）实施，并确保发布版本从固定的提交集构建。

功能冻结和代码冻结之间的区别在于控制级别。功能冻结管理范围：什么将进入发布。代码冻结管理质量：排除发布前一天引入新错误的风险。实际上，许多团队使用两阶段模型：发布前 1-2 周 —— 功能冻结，24-48 小时 —— 代码冻结。Code freeze 对于移动应用尤其重要，因为构建需要在计划发布日期前几天上传到商店。

代码冻结的例外 —— 关键漏洞（CVE 评分 9+）的安全修复。此类变更通过紧急流程进行，包括快速代码审查和团队通知。所有其他变更推迟到下一个发布周期。

功能冻结 vs 代码冻结：比较

选择功能冻结还是代码冻结取决于团队的成熟度和发布频率。使用 CI/CD 和功能标志的团队可以仅限 24 小时的代码冻结，而每月发布的团队通常依次使用两种冻结。

冻结类型：完全、部分和 BAU 冻结

除了完全功能冻结和代码冻结之外，还有更灵活的变体。Partial feature freeze（部分冻结）仅在某些模块中阻止新功能 —— 例如，在支付模块或认证模块中，而其他组件保持开放以便变更。

BAU-freeze（常规业务冻结）——折衷方案，仅禁止变更量超过特定阈值（例如 500 行代码）的大型功能。小型改进、UI 调整和错误修复继续进行。BAU-freeze 适用于持续交付的项目，完全停止开发一周在经济上不可行。

还存在 deployment freeze（部署冻结）的概念 —— 完全停止向生产环境部署，通常针对假期季节（圣诞节假期、黑色星期五）。在此期间，即使热修复也被阻止，除非与安全相关。部署冻结通常持续 1-2 周，并在公司层面协调。

何时引入冻结以及持续多长时间

引入功能冻结的最佳时机 —— 在代码完成（code complete）之后，当所有计划功能已合并并正在进行 QA。具体期限取决于发布周期：对于两周的 sprint，功能冻结在发布日期前 3-4 天引入，对于月度发布 —— 提前 7-10 天。Code freeze 在计划构建发布版本的 24-48 小时前引入。

冻结持续时间应足够以稳定代码。过长的冻结（超过 2 周）会打击团队士气，并导致未合并功能的积累，每个功能在冻结解除后都会增加冲突风险。过短的冻结（功能冻结少于 24 小时）没有足够时间进行全面测试和修复。

推荐实践 —— 不根据日历日期设置冻结，而根据代码库状态。功能冻结在发布的开放错误数量超过阈值（例如 10 个关键错误）时引入。代码冻结 —— 当构建成功通过冒烟测试和回归测试套件时。Time-based freeze（固定日期）仍然是受监管行业（金融科技、医疗科技）的标准，其中发布日期已由监管机构批准。

通过 CI/CD 和 Git 自动化冻结

手动控制冻结是错误来源：开发人员可能意外合并本应等待冻结解除的 PR。自动化通过 Git 分支保护规则和 CI/CD 管道解决了这个问题。在 Git 提供商（GitHub、GitLab、Bitbucket）中设置规则，阻止在发布分支上进行合并，除非有特殊标签或发布经理的批准。

CI/CD 管道 在构建之前检查冻结状态。在 Jenkins、GitLab CI 或 GitHub Actions 中添加一个步骤，读取带有冻结日程的配置文件，如果当前日期落在冻结期间，则拒绝构建。替代方案 —— 管理面板中的功能标志，阻止部署到生产环境。

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "功能冻结已激活。PR 已被阻止。" && exit 1

示例脚本 freeze-check.js 从仓库根目录读取带有冻结日程的 JSON。如果当前日期落在指定分支的 start_date 和 end_date 之间的间隔内 —— 管道失败并显示冻结状态消息。Git 分支保护 添加了第二道屏障：即使管道未运行，规则也不允许未经批准合并 PR。

实施冻结时的典型错误

第一个错误 —— 冻结没有明确的解除标准。团队冻结代码，但未确定解冻必须满足的条件：零关键错误、通过回归测试套件、产品经理批准。没有标准，冻结可能持续数周。完成定义（Definition of done）对于冻结必须记录在案，并让每位开发人员知晓。

第二个错误 —— 冻结的例外过多。每个例外（"这个 PR 不是功能，而是技术债务"）模糊了冻结的边界。如果例外超过正常 PR 流的 20% —— 冻结不起作用。团队简单地将功能重命名为错误修复以绕过封锁。

第三个错误 —— 忽略发布候选版本。如果团队不构建发布候选版本，并在代码冻结后立即部署到生产环境，冻结的意义就丧失了：错误由用户发现。Release candidate 应在代码冻结前构建，由 QA 和暂存环境测试，只有在质量确认后才实施代码冻结。

第四个错误 —— 手动控制中的人为因素。开发人员可能忘记在合并前检查冻结状态，发布经理可能错过通知。唯一可靠的解决方案 —— 在 Git 提供商或 CI/CD 级别自动封锁，排除人为错误。