Triển khai là khi mã được đưa vào sản xuất. Phát hành là khi ai đó thực sự có thể sử dụng nó. Nhầm lẫn cả hai là một trong những cách nhanh nhất khiến mỗi lần triển khai trở nên căng thẳng một chút.
feature flag dùng để tạo khoảng trống giữa hai khoảnh khắc này. Bạn có thể triển khai ngay hôm nay, khởi động vào ngày mai cho nhóm nội bộ, sau đó cho khách hàng thí điểm, sau đó cho 10% người dùng. Nếu có sự cố xảy ra, hãy tắt cờ. Bạn không nhất thiết phải khôi phục toàn bộ bản phát hành.
Cờ không chỉ là nếu
Về mặt kỹ thuật, nó thường là if. Về mặt văn hóa thì còn hơn thế nữa.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
if nhỏ đó có thể đại diện cho việc triển khai dần dần, thử nghiệm, di chuyển, giấy phép doanh nghiệp hoặc kill switch hoạt động. Vấn đề là nếu bạn không quản lý tốt, nó cũng có thể trở thành khoản nợ kỹ thuật tồn tại trong code suốt hai năm.
OpenFeature xuất hiện ở đâu
OpenFeature là thông số kỹ thuật mở để đánh giá feature flag với điểm chung API. Ý tưởng rất đơn giản: mã ứng dụng của bạn không nên phụ thuộc trực tiếp vào nhà cung cấp hoặc hệ thống nội bộ mà bạn sử dụng cho cờ.
Ứng dụng hỏi:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Nhà cung cấp quyết định các quy tắc đến từ đâu: SaaS, tệp, dịch vụ nội bộ, gắn cờ, cấu hình GitOps. Nếu một ngày nào đó bạn thay đổi tính năng gắn cờ phụ trợ, ứng dụng sẽ không cần phải viết lại ở mọi nơi.
Sự tách biệt này có vẻ giống như một chi tiết kiến trúc, nhưng nó được cảm nhận khi dự án phát triển.
Bối cảnh là một nửa trận chiến
Cờ bật hoặc tắt dành cho mọi người đều hữu ích nhưng có giới hạn. Cuộc sống giao hàng tiến bộ trong bối cảnh:
- người dùng nội bộ hoặc bên ngoài;
- gói miễn phí hoặc doanh nghiệp;
- làng bản;
- tổ chức;
- phiên bản ứng dụng;
- Tỷ lệ lưu lượng truy cập ổn định.
Chìa khóa quan trọng là targetingKey: nó phải ổn định. Nếu nó thay đổi theo mọi yêu cầu, người dùng có thể một lần ở biến thể A và một lần ở biến thể B. Đối với một thử nghiệm thì điều đó thật tồi tệ, còn đối với việc thanh toán thì điều đó có thể là thảm họa.
Triển khai hợp lý
Một dòng chảy tôi thích là thế này:
- triển khai khi tắt cờ;
- đánh lửa cho các nhà phát triển và QA;
- bật cho khách hàng hoặc người thuê thí điểm;
- Triển khai 5%;
- triển khai ở mức 25%;
- Triển khai 100%;
- loại bỏ mã và cờ cũ.
Điểm thường bị lãng quên là điểm cuối cùng. Một lá cờ tạm thời phải có ngày chết. Nếu nó tồn tại mãi mãi, mọi nhà tái cấu trúc trong tương lai sẽ phải hỏi: "nhưng nhánh này còn hữu ích không?".
Kill switch: chuẩn bị trước
kill switch là cờ giúp bạn cứu nguy khi một phần phụ thuộc bên ngoài bắt đầu làm phiền bạn, một công việc tiêu tốn quá nhiều tài nguyên hoặc logic mới tạo ra các lỗi lạ.
Điểm kill switch tốt phải là:
- dễ tìm;
- được ghi lại trong sổ ghi chép;
- thỉnh thoảng được thử nghiệm;
- có thể quan sát được khi được kích hoạt;
- độc lập, càng xa càng tốt, khỏi phần có thể bị vỡ.
Điều tồi tệ nhất là trong vụ tai nạn phát hiện ra rằng lá cờ tồn tại nhưng không ai biết liệu nó có còn hoạt động hay không.
Khả năng quan sát được hoặc phân phối không lũy tiến
Bật một tính năng ở mức 10% mà không xem số liệu chỉ là sự lạc quan qua nhiều bước.
Mỗi lần triển khai phải trả lời các câu hỏi đơn giản:
- lỗi có tăng lên không?
- độ trễ có thay đổi không?
- người dùng có hoàn thành quy trình không?
- có thêm vé hoặc thử lại không?
- một biến thể chỉ tác động đến một phân khúc phải không?
OpenFeature hỗ trợ các móc nối xung quanh việc đánh giá cờ. Chúng rất hữu ích khi ghi lại lỗi, thêm số liệu hoặc liên kết xếp hạng với trace.
Đặt tên và quyền sở hữu
Tên quan trọng. new_ui không nói gì. checkout.v2.enabled nói lên nhiều điều hơn thế.
Đối với mỗi lá cờ tôi sẽ đánh dấu ít nhất:
- tên;
- Sự miêu tả;
- người sở hữu;
- mặc định an toàn;
- lý do tại sao nó tồn tại;
- ngày hoặc điều kiện loại bỏ.
Một lá cờ không có chủ sở hữu hầu như luôn là một lá cờ mà không ai có thể xóa được.
Đánh giá chúng ở đâu
Frontend, backend hay edge? Phụ thuộc.
Nếu cờ dành cho bố cục, sao chép hoặc giới thiệu thì giao diện người dùng vẫn ổn. Nếu nó liên quan đến quyền, thanh toán, giới hạn hoặc dữ liệu nhạy cảm thì nó phải nằm ở phần phụ trợ. Nếu nó liên quan đến việc định tuyến hoặc thử nghiệm lưu lượng truy cập cao, thì lợi thế có thể có ý nghĩa.
Quy tắc đơn giản: giao diện người dùng có thể cải thiện trải nghiệm nhưng đó không phải là rào cản bảo mật duy nhất.
Kết luận
Việc feature flag được thực hiện tốt sẽ thay đổi mối quan hệ với sản xuất. Chúng không loại bỏ rủi ro nhưng làm cho nó nhỏ hơn và dễ quản lý hơn. Bạn có thể phát hành theo từng lát, quan sát, dừng lại, quay lại, học hỏi.
OpenFeature bổ sung một nền tảng sạch: API chung, các nhà cung cấp có thể hoán đổi cho nhau và một cách gọn gàng hơn để phát triển hệ thống. Nhưng kỷ luật vẫn là của bạn: mặc định an toàn, tên rõ ràng, số liệu, chủ sở hữu và độ sạch sẽ.
Lá cờ tốt nhất là lá cờ giúp bạn thảnh thơi một cách bình tĩnh rồi biến mất khi không còn cần thiết nữa.