Posted inProgramming

Vượt xa việc Triển khai Code: Làm chủ Feature Flags và Canary Releases

Programming tutorial - IT technology blog
Programming tutorial - IT technology blog

Chấm dứt nỗi ác mộng triển khai vào thứ Sáu

Tôi từng coi việc triển khai code vào chiều thứ Sáu như một canh bạc đầy rủi ro. Một lỗi nhỏ cũng có thể làm hỏng kỳ nghỉ cuối tuần của cả đội. Áp lực đó đã biến mất khi tôi tách biệt giữa deployment (triển khai) và release (phát hành). Nhiều nhà phát triển sử dụng các thuật ngữ này thay thế cho nhau, nhưng chúng thực sự khác biệt. Deployment là hành động kỹ thuật đưa mã nguồn lên máy chủ. Release là quyết định về mặt kinh doanh để cho phép người dùng nhìn thấy nó. Feature flags cho phép bạn tách biệt hoàn toàn hai hành động này.

Hãy tưởng tượng một hệ thống nơi bạn có thể bật hoặc tắt các tính năng ngay lập tức. Bạn có thể triển khai luồng thanh toán mới cho đúng 500 người dùng cụ thể để theo dõi hiệu suất trước khi áp dụng cho toàn cầu. Bạn làm tất cả những điều này mà không cần chạm vào quy trình deployment.

Khái niệm cơ bản: Feature Toggle đầu tiên của bạn

Bỏ qua các thuật ngữ chuyên môn, feature flag thực chất chỉ là một câu lệnh điều kiện if. Giả sử bạn đang xây dựng tính năng “Dark Mode” cho ứng dụng. Thay vì đợi cho đến khi nó hoàn hảo, bạn có thể ẩn mã nguồn chưa hoàn thiện đằng sau một flag (cờ).

Dưới đây là một triển khai cơ bản bằng Python:

# config.py
FEATURES = {
    "new_ui_layout": False,
    "beta_payment_gateway": True
}

# app.py
from config import FEATURES

def render_homepage():
    if FEATURES.get("new_ui_layout"):
        return "Đang hiển thị giao diện UI mới lung linh!"
    return "Đang hiển thị giao diện UI cổ điển, ổn định."

print(render_homepage())

Nhưng vấn đề là: để thay đổi flag này, bạn vẫn phải commit code và triển khai lại. Để flag thực sự hữu ích, cấu hình cần được đặt bên ngoài mã nguồn của bạn.

Mở rộng: Flag động với Redis

Redis là một lựa chọn hàng đầu cho việc này vì nó cung cấp độ trễ dưới một mili giây. Nó có thể xử lý hàng nghìn yêu cầu đọc mỗi giây mà không gặp bất kỳ khó khăn nào.

Dưới đây là một cách đơn giản để cấu trúc một trình quản lý tính năng động:

import redis
import json

class FeatureManager:
    def __init__(self):
        self.client = redis.Redis(host='localhost', port=6379, db=0)

    def is_enabled(self, feature_name):
        value = self.client.get(f"feature:{feature_name}")
        if value is None:
            return False
        return value.decode('utf-8').lower() == 'true'

# Cách sử dụng
manager = FeatureManager()
if manager.is_enabled("new_checkout_flow"):
    print("Đang xử lý với luồng mới...")
else:
    print("Đang xử lý với luồng cũ...")

Cập nhật một flag trong Redis mất chưa đầy 1ms. Hãy so sánh điều đó với một quy trình CI/CD mất 15 phút. Nếu một cổng thanh toán mới bắt đầu gặp lỗi, bạn có thể chạy SET feature:new_checkout_flow false trong CLI của mình. Tính năng này sẽ biến mất đối với tất cả người dùng ngay lập tức.

Phát hành Canary xác định (Deterministic Canary Releases)

Điều kỳ diệu thực sự xảy ra khi bạn muốn thử nghiệm một tính năng rủi ro chỉ trên 10% lưu lượng truy cập. Đây được gọi là Canary Release. Bạn không thể chỉ chọn người dùng ngẫu nhiên; Người dùng A không nên thấy UI mới ở lần tải trang này và UI cũ ở lần tiếp theo. Điều đó dẫn đến trải nghiệm người dùng bị gián đoạn và gây bối rối.

Chúng ta giải quyết vấn đề này bằng deterministic hashing (băm xác định). Bằng cách băm ID người dùng và lấy modulo 100, chúng ta có được một nhóm (bucket) nhất quán từ 0 đến 99 cho người dùng cụ thể đó.

import hashlib

def should_show_feature(user_id, feature_name, percentage):
    # Salting đảm bảo Người dùng A không phải là "chuột bạch" cho mọi bản beta
    salt = f"{user_id}-{feature_name}"
    hash_val = int(hashlib.md5(salt.encode()).hexdigest(), 16)
    return (hash_val % 100) < percentage

# Ví dụ: Người dùng "12345" sẽ luôn nhận được cùng một kết quả
user_id = "user_12345"
if should_show_feature(user_id, "ai_recommendations", 10):
    print("Người dùng nằm trong nhóm 10%. Hiển thị tính năng AI.")
else:
    print("Người dùng nằm trong nhóm 90%. Hiển thị tính năng tiêu chuẩn.")

Chiến lược này là một bước ngoặt lớn cho sự ổn định. Bạn có thể bắt đầu triển khai ở mức 1%, theo dõi các bản ghi lỗi trên Sentry để tìm các đột biến, sau đó tăng dần lên 25%, 50% và cuối cùng là 100%.

Quy tắc thực tế để giữ code sạch

Feature flags rất hữu ích, nhưng chúng có thể nhanh chóng trở thành nợ kỹ thuật (technical debt). Tôi tuân theo một vài quy tắc nghiêm ngặt để giữ cho codebase của chúng tôi không trở thành một mớ hỗn độn các câu lệnh if cũ:

  • Sử dụng tên mô tả: Tránh dùng flag1. Hãy dùng enable_stripe_v3_migration để mọi người biết chính xác nó có tác dụng gì.
  • Đặt “Ngày tiêu hủy”: Flag chỉ nên mang tính tạm thời. Khi một tính năng đã ổn định 100%, hãy xóa flag và các đoạn code cũ. Tôi sử dụng vé Jira hoặc các ghi chú TODO để theo dõi việc dọn dẹp này.
  • Thất bại an toàn (Fail Safely): Nếu Redis gặp sự cố, code của bạn không được phép bị sập. Luôn đặt mặc định là False và bao bọc các kiểm tra flag của bạn trong các khối try/except.
  • Kiểm tra (Audit) các Toggles: Ghi lại ai đã thay đổi flag và khi nào. Nếu một tính năng đột ngột biến mất lúc 3 giờ sáng, bạn cần biết đó là do thay đổi thủ công hay do một kịch bản tự động.

Tự xây dựng hệ thống của riêng bạn là một cách tuyệt vời để học hỏi. Tuy nhiên, khi nhóm của bạn mở rộng, các nền tảng như Flagsmith hoặc LaunchDarkly cung cấp bảng điều khiển UI cho phép những người không phải kỹ sư cũng có thể quản lý các đợt phát hành. Feature flags đã chuyển quyền kiểm soát từ các script deployment sang chiến lược sản phẩm của tôi, giúp chu kỳ phát hành của chúng tôi vừa nhanh hơn vừa an toàn hơn đáng kể.

Share:
Tags: