การเจาะกลุ่ม

โดยค่าเริ่มต้น สภาพแวดล้อมจะให้บริการค่าเริ่มต้นของ flag แก่อุปกรณ์ทุกเครื่อง การเจาะกลุ่ม คือวิธีที่คุณให้บริการค่าอื่นแก่อุปกรณ์ บางส่วน ผู้ทดสอบเบต้า แอปเวอร์ชันหนึ่งโดยเฉพาะ 10% ของทุกคน หน้านี้อธิบายกลไก ส่วนคู่มือการ rolloutพาคุณลงมือใช้งานทีละขั้น

แท็ก สิ่งที่กฎมองเห็น

กฎทดสอบ แท็ก — ข้อเท็จจริงเล็ก ๆ แบบคีย์/ค่าเกี่ยวกับอุปกรณ์ที่ส่งคำขอมา SDK ส่งแท็กในตัวบางรายการให้อัตโนมัติ (appVersion appBuild osVersion platform sdkVersion) และแอปของคุณเพิ่มแท็กของตัวเองได้ อย่าง cohort: "beta"

มีสองเรื่องเกี่ยวกับแท็กที่ควรรู้ตั้งแต่ต้น

• แท็กถูกประเมินแล้วลืมทิ้ง FortressFlag ใช้แท็กเพื่อตอบคำขอครั้งเดียวที่แท็กมาด้วย แล้วทิ้งไป — แท็กไม่เคยถูกเก็บและไม่เคยถูกบันทึกลง log ไม่มีประวัติแท็กอยู่ที่ไหนเลย โดยการออกแบบ
• แท็กคือคำกล่าวอ้างของแอปคุณ แท็กบรรจุอะไรก็ได้ที่โค้ดของคุณใส่ลงไป — ดังนั้นอย่าใส่ความลับหรือข้อมูลส่วนบุคคลของผู้ใช้ของคุณลงในค่าแท็ก จำกัดไว้ที่กลุ่ม cohort เวอร์ชัน และการตั้งค่า

กฎ รายการที่เรียงลำดับ กฎแรกที่ตรงชนะ

flag + สภาพแวดล้อมแต่ละคู่มี รายการกฎที่เรียงลำดับ กฎหนึ่งข้อคือกลุ่มเงื่อนไขที่ AND เข้าด้วยกัน — cohort เป็น beta AND appVersion ≥ 2.0 — บวกกับค่าที่กฎให้บริการเมื่อตรง

การประเมินเรียบง่ายและควรจำให้ขึ้นใจ

1. กฎถูกตรวจ จากบนลงล่าง
2. กฎแรกที่เงื่อนไขเป็นจริงทุกข้อ เป็นผู้ตัดสินค่า กฎที่อยู่ต่ำกว่าจะไม่ถูกพิจารณา — ลำดับคือความหมาย และคุณจัดลำดับกฎใหม่ได้ในแดชบอร์ด
3. เงื่อนไขบนแท็กที่อุปกรณ์ ไม่ได้ส่งมา จะไม่เป็นจริง ไม่มีแท็ก ก็ไม่ตรง — กฎถูกข้ามไป ไม่ใช่ข้อผิดพลาด
4. ถ้า ไม่มีกฎใดตรง ค่าเริ่มต้นของ flag จะให้บริการ

กฎที่ ไม่มี เงื่อนไขจะตรงเสมอ — นั่นคือรูปแบบ “ทุกคนที่เหลือ” ที่คุณวางไว้ท้ายรายการ

การเปรียบเทียบเวอร์ชัน

เงื่อนไขเปรียบเทียบเวอร์ชันได้ appVersion ≥ 2.0 เวอร์ชันถูกแยกที่จุด แล้วเปรียบเทียบเป็นตัวเลขจากซ้ายไปขวา ส่วนที่ขาดหายอ่านเป็นศูนย์ — ดังนั้น 2.0 เท่ากับ 2.0.0 และ 2.10 ใหม่กว่า 2.9 เวอร์ชันของอุปกรณ์ที่แยกเป็นตัวเลขคั่นจุดไม่ได้ (เช่น 2.0-beta) จะทำให้เงื่อนไขไม่เป็นจริงเฉย ๆ คำต่อท้าย pre-release ไม่รองรับ — เปรียบเทียบเวอร์ชันแบบตัวเลขคั่นจุดล้วน

เซกเมนต์ ชิ้นส่วนของกฎที่คุณตั้งชื่อและใช้ซ้ำ

เซกเมนต์ คือรายการเงื่อนไขแบบ AND ที่ตั้งชื่อไว้ — beta-testers internal-devices — ซึ่งคุณกำหนดครั้งเดียวสำหรับทั้งองค์กร แล้วอ้างอิงจากกฎข้าม flag และข้ามสภาพแวดล้อม แก้เซกเมนต์ แล้วทุกกฎที่ใช้มันจะตามไปด้วย

ขอบเขตที่กว้างขนาดนั้นคือเหตุผลที่การแก้ไขเซกเมนต์ต้องใช้ สิทธิ์ระดับ production เซกเมนต์ที่ถูกอ้างอิงโดยกฎ production จะเปลี่ยน production เมื่อมันเปลี่ยน ไม่ว่าใครเป็นคนบันทึก

Rollout ตามเปอร์เซ็นต์

กฎใดก็ได้บรรจุ เปอร์เซ็นต์ rollout ได้ แทนที่จะตรงกับทุกอุปกรณ์ที่ผ่านเงื่อนไข มันจะตรงกับเพียง N% แรกของอุปกรณ์เหล่านั้น นั่นคือวิธีที่ “10% ของผู้ทดสอบเบต้า” ทำงาน — เงื่อนไขก่อน ประตูเปอร์เซ็นต์ทีหลัง

คุณสมบัติสามข้อทำให้ rollout ไว้ใจได้

• คงที่ อุปกรณ์อยู่ในเปอร์เซ็นต์หรือไม่ คำนวณจากตัวตนของอุปกรณ์และคีย์ของ flag — อุปกรณ์เดียวกันได้คำตอบเดียวกันทุกคำขอ ไม่มีใครกะพริบเข้าออกจาก rollout และการเพิ่ม 10% เป็น 20% ยังคง 10% เดิมไว้
• แยกตาม flag การคำนวณผสมคีย์ของ flag เข้าไปด้วย ดังนั้น rollout 10% บน flag หนึ่งกับ rollout 10% บนอีก flag จะจับอุปกรณ์ คนละ ส่วนสิบของฝูงอุปกรณ์คุณ ไม่มีอุปกรณ์ 10% ที่โชคร้ายถาวรและโดนทุกการทดลองพร้อมกัน
• ไม่มีอะไรถูกเก็บ การเป็นสมาชิกกลุ่มเป็นเลขคณิตล้วน คำนวณใหม่ทุกคำขอ — FortressFlag ไม่เก็บบันทึกว่าอุปกรณ์ใดอยู่ใน rollout ไหน ไม่มีอะไรจะรั่ว และไม่มีอะไรต้องเก็บกวาด

ขีดจำกัด

กว้างพอที่คุณมักจะไม่ชน แต่ตายตัวเพื่อให้ payload มีขอบเขต สูงสุด 20 กฎต่อ flag ต่อสภาพแวดล้อม 5 เงื่อนไขต่อกฎ (การอ้างอิงเซกเมนต์นับเป็นหนึ่ง และเซกเมนต์บรรจุเงื่อนไขของตัวเองได้ถึง 10 ข้อ) คีย์แท็กยาวได้ถึง 64 ตัวอักษร ค่าของเงื่อนไขยาวได้ถึง 256

ไปต่อที่ไหนดี

• ตั้งค่า rollout ตามเปอร์เซ็นต์ — งานนี้ ทีละขั้น
• สภาพแวดล้อมและโปรเจกต์ — การเจาะกลุ่มแยกตามสภาพแวดล้อม
• Flag ไปถึงแอปของคุณอย่างไร — ทำไมอุปกรณ์ไม่มีวันเห็นกฎของคุณ