Feature flag trong web/app: phát hành tính năng an toàn hơn mà không cần deploy liên tục

12 lượt xem · 1 trả lời

1. 06:33 06/08/2026
Trong phát triển web/app, không phải lúc nào “code đã lên production” cũng đồng nghĩa với “người dùng đã thấy tính năng mới”. Feature flag là một cách tách hai việc này ra: triển khai mã nguồn trước, nhưng bật/tắt tính năng bằng cấu hình. Nếu dùng đúng, feature flag giúp giảm rủi ro khi phát hành, thử nghiệm theo nhóm nhỏ và xử lý sự cố nhanh hơn. Ví dụ thực tế: bạn đang xây tính năng “thanh toán bằng ví điện tử” cho một ứng dụng bán hàng. Thay vì đợi mọi thứ hoàn hảo rồi deploy một lần lớn, đội phát triển có thể đưa code lên production nhưng để flag ở trạng thái tắt. Sau đó chỉ bật cho tài khoản nội bộ kiểm thử, tiếp theo là 5% người dùng, rồi tăng dần nếu không thấy lỗi nghiêm trọng. Một số kiểu feature flag thường gặp: - Release flag: dùng để bật/tắt tính năng mới khi phát hành. - Experiment flag: dùng cho A/B testing, ví dụ thử hai giao diện đăng ký khác nhau. - Permission flag: bật tính năng theo gói dịch vụ, vai trò hoặc nhóm khách hàng. - Ops flag: dùng như công tắc khẩn cấp, ví dụ tắt tạm tính năng xuất báo cáo nặng khi hệ thống quá tải. Điểm quan trọng là không nên xem feature flag như một biến if đơn giản rải khắp code. Nếu không quản lý cẩn thận, codebase sẽ nhanh chóng đầy các nhánh điều kiện cũ, khó đọc và dễ phát sinh lỗi. Mỗi flag nên có tên rõ ràng, mô tả mục đích, người phụ trách và thời điểm dự kiến gỡ bỏ. Một cách tổ chức dễ áp dụng là gom việc đọc flag vào một lớp hoặc service riêng. Ví dụ thay vì viết trực tiếp “if new_checkout_enabled” ở nhiều nơi, hãy tạo hàm như “canUseNewCheckout(user)”. Cách này giúp logic tập trung hơn, dễ thay đổi điều kiện từ bật toàn hệ thống sang bật theo nhóm người dùng mà không phải sửa nhiều chỗ. Khi dùng feature flag, cũng cần chú ý đến dữ liệu. Nếu tính năng mới ghi dữ liệu theo cấu trúc khác, việc tắt flag có thể không đủ để quay lại trạng thái cũ. Chẳng hạn quy trình thanh toán mới tạo thêm trạng thái đơn hàng “pending_wallet_confirmation”, trong khi giao diện cũ không hiểu trạng thái này. Vì vậy, trước khi bật flag, hãy kiểm tra cả luồng rollback: nếu tắt tính năng, dữ liệu đã sinh ra có còn được xử lý an toàn không? Một vài lời khuyên thực tế: - Đừng dùng feature flag để che giấu code chưa ổn định. Code đưa lên production vẫn phải đạt chất lượng tối thiểu. - Ghi log hoặc metric theo trạng thái flag để biết lỗi xảy ra ở nhóm dùng tính năng mới hay cũ. - Với flag quan trọng, nên có giao diện quản trị hoặc cơ chế cấu hình an toàn, tránh phải deploy chỉ để bật/tắt. - Đặt lịch dọn dẹp flag sau khi tính năng đã phát hành ổn định. Flag tồn tại quá lâu sẽ trở thành nợ kỹ thuật. - Cẩn thận với cache. Nếu nội dung phụ thuộc vào flag theo từng người dùng, cache sai khóa có thể làm người này thấy giao diện của nhóm khác. Feature flag không phải công cụ chỉ dành cho hệ thống lớn. Ngay cả một dự án nhỏ cũng có thể hưởng lợi nếu cần phát hành đều đặn và giảm rủi ro. Điều quan trọng là dùng có kỷ luật: mỗi flag phải có mục đích rõ, phạm vi rõ và kế hoạch kết thúc rõ. Khi đó, việc ra mắt tính năng mới sẽ bớt giống một lần “đánh cược” và giống một quá trình kiểm soát được hơn.
0 Facebook
2. 01:51 26/10/2026
Trả lời Quản Trị Viên Trong phát triển web/app, không phải lúc nào “code đã lên production” cũng đồng nghĩa với “người dùng đã thấy tính năng …
Bài viết khá sát thực tế, nhất là phần dữ liệu và rollback. Mình từng thấy flag thanh toán mới tạo thêm trạng thái đơn hàng, tắt flag xong giao diện cũ vẫn phải hiểu trạng thái đó, nếu không đơn dễ bị kẹt. Vì vậy trước khi bật nên test cả luồng tắt, không chỉ luồng bật. Với dự án nhỏ, mình thấy chỉ cần một bảng cấu hình flag và hàm kiểu canUseX(user) là đủ, tránh rải if khắp nơi. Nên ghi rõ owner, ngày dự kiến gỡ và metric theo nhóm bật/tắt để biết lỗi đến từ đâu. Cache cũng là điểm dễ b
0
Vui lòng đăng nhập để tham gia trả lời chủ đề này.
Điều hướng nhanh

Bạn muốn khám phá điều gì?

Tìm chủ đề, bài viết hoặc đi thẳng đến một khu vực của cộng đồng.

Esc để đóng Ctrl K để mở lại