Feature freeze và code freeze trong phát triển ứng dụng: bản chất, sự khác biệt và vai trò

Feature freeze là gì?

Feature freeze là lệnh cấm tạm thời việc thêm chức năng mới vào cơ sở mã, được áp dụng trước một bản phát hành đã lên kế hoạch. Nhóm ngừng hợp nhất các tính năng và chuyển sang sửa lỗi, tối ưu hóa và hoàn thiện mã hiện có. Các nhà phát triển hoàn thiện các tính năng chưa hoàn chỉnh chỉ trong phạm vi sửa lỗi, không mở rộng phạm vi.

Feature freeze giải quyết vấn đề các tính năng đang triển khai (work-in-progress) không kịp phát hành nhưng đã được hợp nhất một phần vào nhánh chính. Nếu các tính năng mới tiếp tục được hợp nhất, nguy cơ hồi quy tăng lên: mỗi tích hợp mới đòi hỏi phải kiểm tra lại các mô-đun đã hoàn thành. Feature freeze cố định phạm vi phát hành, biến nó từ mục tiêu di động thành một tập hợp chức năng ổn định.

Một làm rõ quan trọng: feature freeze ≠ code freeze. Trong thời gian feature freeze, sửa lỗi, tái cấu trúc, cập nhật phụ thuộc và tài liệu đều được phép. Chỉ các tính năng mới hướng đến người dùng mới bị cấm — bất kỳ mã nào thay đổi hành vi ứng dụng từ góc nhìn của người dùng. Kiểm tra trong code review: nếu PR thêm màn hình mới, nút hoặc phương thức API — nó bị từ chối cho đến khi dỡ bỏ đóng băng.

Code freeze là gì và khác feature freeze như thế nào

Code freeze là thực hành nghiêm ngặt hơn trong đó mọi thay đổi trong mã đều bị cấm hoàn toàn. Ngay cả sửa lỗi cũng không được phép trừ khi chúng là nghiêm trọng. Code freeze được áp dụng trong thời gian ngắn (thường 24-48 giờ) và đảm bảo rằng bản build phát hành được tạo từ một tập hợp commit cố định.

Sự khác biệt giữa feature freeze và code freeze nằm ở mức độ kiểm soát. Feature freeze quản lý phạm vi: chính xác những gì sẽ được đưa vào bản phát hành. Code freeze quản lý chất lượng: loại bỏ nguy cơ đưa lỗi mới vào một ngày trước khi phát hành. Trong thực tế, nhiều nhóm sử dụng mô hình hai giai đoạn: 1-2 tuần trước khi phát hành — feature freeze, 24-48 giờ trước — code freeze. Code freeze đặc biệt quan trọng đối với ứng dụng di động, nơi bản build cần được tải lên cửa hàng vài ngày trước ngày phát hành dự kiến.

Ngoại lệ của code freeze là sửa lỗi bảo mật cho các lỗ hổng nghiêm trọng (CVE điểm 9+). Những thay đổi như vậy trải qua quy trình khẩn cấp với code review nhanh bắt buộc và thông báo cho nhóm. Tất cả các thay đổi khác được hoãn lại đến chu kỳ phát hành tiếp theo.

Feature freeze vs code freeze: so sánh

Lựa chọn giữa feature freeze và code freeze phụ thuộc vào độ chín của nhóm và tần suất phát hành. Các nhóm có CI/CD và feature flags có thể chỉ cần code freeze 24 giờ, trong khi các nhóm phát hành hàng tháng thường sử dụng cả hai hình thức đóng băng tuần tự.

Các loại đóng băng: toàn phần, một phần và BAU-freeze

Ngoài feature freeze toàn phần và code freeze, còn có các tùy chọn linh hoạt hơn. Đóng băng một phần chặn chức năng mới chỉ trong một số mô-đun nhất định — ví dụ, trong mô-đun thanh toán hoặc mô-đun xác thực, để các thành phần khác mở cho thay đổi.

BAU-freeze (business as usual freeze) là tùy chọn thỏa hiệp trong đó chỉ các tính năng lớn có khối lượng thay đổi vượt quá ngưỡng nhất định (ví dụ: 500 dòng mã) mới bị cấm. Các cải tiến nhỏ, điều chỉnh UI và sửa lỗi tiếp tục được hợp nhất. BAU-freeze thuận tiện cho các dự án có phân phối liên tục, nơi việc dừng phát triển hoàn toàn trong một tuần là không khả thi về mặt kinh tế.

Cũng có khái niệm deployment freeze (đóng băng triển khai) — dừng hoàn toàn việc triển khai lên sản phẩm, điển hình cho mùa lễ (kỳ nghỉ Giáng sinh, Black Friday). Trong giai đoạn này, ngay cả hotfix cũng bị chặn trừ khi liên quan đến bảo mật. Deployment freeze thường kéo dài 1-2 tuần và được phối hợp ở cấp công ty.

Khi nào áp dụng đóng băng và kéo dài bao lâu

Thời điểm tối ưu để áp dụng feature freeze là sau khi hoàn thành mã, khi tất cả các tính năng đã lên kế hoạch được hợp nhất và đang qua QA. Thời gian chính xác phụ thuộc vào chu kỳ phát hành: cho sprint hai tuần, feature freeze được áp dụng 3-4 ngày trước ngày phát hành; cho phát hành hàng tháng, 7-10 ngày trước. Code freeze được áp dụng 24-48 giờ trước thời gian xây dựng bản build phát hành dự kiến.

Thời gian đóng băng phải là tối thiểu đủ để ổn định mã. Đóng băng quá dài (hơn 2 tuần) làm giảm động lực của nhóm và tạo ra sự tích tụ các tính năng chưa được hợp nhất, mỗi tính năng làm tăng nguy cơ xung đột sau khi dỡ bỏ đóng băng. Đóng băng quá ngắn (dưới 24 giờ cho feature freeze) không cho đủ thời gian để kiểm tra và sửa lỗi kỹ lưỡng.

Thực hành được khuyến nghị là thiết lập đóng băng không theo ngày lịch mà theo trạng thái cơ sở mã. Feature freeze được áp dụng khi số lượng lỗi mở cho bản phát hành vượt quá ngưỡng (ví dụ: 10 lỗi nghiêm trọng). Code freeze — khi bản build vượt qua kiểm tra smoke test và bộ hồi quy thành công. Đóng băng theo thời gian (ngày cố định) vẫn là tiêu chuẩn cho các ngành được quản lý (fintech, medtech) nơi ngày phát hành được cơ quan quản lý phê duyệt.

Tự động hóa đóng băng qua CI/CD và Git

Kiểm soát đóng băng thủ công là nguồn gốc của lỗi: nhà phát triển có thể vô tình hợp nhất một PR đáng lẽ phải chờ đến khi dỡ bỏ đóng băng. Tự động hóa giải quyết vấn đề này qua các quy tắc bảo vệ nhánh Git và đường ống CI/CD. Trong nhà cung cấp Git (GitHub, GitLab, Bitbucket), các quy tắc được cấu hình để chặn hợp nhất vào nhánh phát hành mà không có thẻ đặc biệt hoặc phê duyệt từ người quản lý phát hành.

Đường ống CI/CD kiểm tra trạng thái đóng băng trước khi xây dựng bản build. Trong Jenkins, GitLab CI hoặc GitHub Actions, một bước được thêm vào để đọc tệp cấu hình với lịch trình đóng băng và từ chối build nếu ngày hiện tại rơi vào giai đoạn đóng băng. Một giải pháp thay thế là feature flag trong bảng quản trị chặn triển khai lên sản phẩm.

# .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 "Feature freeze is active. PR blocked." && exit 1

Tập lệnh mẫu freeze-check.js đọc JSON với lịch trình đóng băng từ thư mục gốc của kho lưu trữ. Nếu ngày hiện tại rơi vào khoảng giữa start_date và end_date cho nhánh được chỉ định, đường ống thất bại với thông báo trạng thái đóng băng. Bảo vệ nhánh Git thêm rào cản thứ hai: ngay cả khi đường ống không được kích hoạt, quy tắc sẽ không cho phép hợp nhất PR mà không có phê duyệt.

Những sai lầm phổ biến khi triển khai đóng băng

Sai lầm đầu tiên là đóng băng không có tiêu chí dỡ bỏ rõ ràng. Nhóm đóng băng mã nhưng không xác định điều kiện nào phải được đáp ứng để dỡ bỏ: không lỗi nghiêm trọng, bộ hồi quy vượt qua, phê duyệt từ quản lý sản phẩm. Không có tiêu chí, đóng băng có thể kéo dài hàng tuần. Định nghĩa hoàn thành cho đóng băng phải được ghi lại và mọi nhà phát triển đều biết.

Sai lầm thứ hai là quá nhiều ngoại lệ khỏi đóng băng. Mỗi ngoại lệ (“PR này không phải là tính năng, mà là nợ kỹ thuật”) làm mờ ranh giới đóng băng. Nếu ngoại lệ vượt quá 20% luồng PR bình thường, đóng băng không hoạt động. Nhóm chỉ đơn giản đổi tên tính năng thành sửa lỗi để vượt qua chặn.

Sai lầm thứ ba là bỏ qua các bản phát hành thử nghiệm. Nếu nhóm không xây dựng bản build phát hành thử nghiệm và triển khai trực tiếp lên sản phẩm sau code freeze, mục đích của đóng băng bị mất: lỗi được người dùng phát hiện. Bản phát hành thử nghiệm nên được xây dựng trước code freeze, được QA kiểm tra và trên môi trường thử nghiệm, và chỉ sau khi xác nhận chất lượng mới áp dụng code freeze.

Sai lầm thứ tư là yếu tố con người trong kiểm soát thủ công. Nhà phát triển có thể quên kiểm tra trạng thái đóng băng trước khi hợp nhất, người quản lý phát hành có thể bỏ lỡ thông báo. Giải pháp đáng tin cậy duy nhất là chặn tự động ở cấp nhà cung cấp Git hoặc CI/CD, loại bỏ lỗi con người.