การปรับใช้คือเมื่อโค้ดมาถึงในการใช้งานจริง การเผยแพร่คือเมื่อมีคนสามารถใช้งานได้จริง การทำให้ทั้งสองสับสนเป็นหนึ่งในวิธีที่รวดเร็วที่สุดในการทำให้ทุกการใช้งานมีความตึงเครียดเล็กน้อย
feature flag ทำหน้าที่วางช่องว่างระหว่างสองช่วงเวลานี้ คุณสามารถปรับใช้วันนี้ เริ่มต้นพรุ่งนี้สำหรับทีมภายใน จากนั้นสำหรับลูกค้านำร่อง จากนั้นสำหรับผู้ใช้ 10% หากมีสิ่งผิดปกติเกิดขึ้น ให้ปิดธง คุณไม่จำเป็นต้องย้อนกลับการเปิดตัวทั้งหมด
ธงไม่ได้เป็นเพียงถ้า
ในทางเทคนิคแล้วมักจะเป็น if ในด้านวัฒนธรรมมันมีมากกว่านั้นมาก
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
if เล็กๆ น้อยๆ นั้นสามารถแสดงถึงการเปิดตัวแบบค่อยเป็นค่อยไป การทดลอง การย้ายข้อมูล ใบอนุญาตองค์กร หรือการดำเนินการ kill switch ปัญหาคือหากคุณจัดการไม่ดีก็อาจกลายเป็นหนี้ทางเทคนิคที่ค้างอยู่ในโค้ดเป็นเวลาสองปีได้
OpenFeature เข้ามาที่ไหน
OpenFeature เป็นข้อกำหนดแบบเปิดสำหรับการประเมิน feature flag ด้วย API ทั่วไป แนวคิดนั้นง่ายมาก: รหัสแอปพลิเคชันของคุณไม่ควรขึ้นอยู่กับผู้จำหน่ายหรือระบบภายในที่คุณใช้สำหรับแฟล็กโดยตรง
แอพถามว่า:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
ผู้ให้บริการเป็นผู้ตัดสินใจว่ากฎมาจากไหน: SaaS, ไฟล์, บริการภายใน, ติดธง, การกำหนดค่า GitOps หากวันหนึ่งคุณเปลี่ยนแบ็กเอนด์การแฟล็กคุณลักษณะ ไม่จำเป็นต้องเขียนแอปพลิเคชันใหม่ทุกที่
การแยกนี้ดูเหมือนเป็นรายละเอียดทางสถาปัตยกรรม แต่จะรู้สึกได้เมื่อโครงการเติบโตขึ้น
บริบทมีชัยไปกว่าครึ่ง
การเปิดหรือปิดแฟล็กสำหรับทุกคนนั้นมีประโยชน์ แต่ก็มีข้อจำกัด ชีวิตการส่งมอบแบบก้าวหน้าในบริบท:
- ผู้ใช้ภายในหรือภายนอก
- แผนฟรีหรือแผนองค์กร
- หมู่บ้าน;
- องค์กร;
- เวอร์ชันแอป;
- เปอร์เซ็นต์การรับส่งข้อมูลที่มั่นคง
คีย์สำคัญคือ targetingKey: จะต้องมีเสถียรภาพ หากมีการเปลี่ยนแปลงในทุกคำขอ ผู้ใช้อาจจบลงที่ตัวแปร A หนึ่งครั้งและอีกครั้งในตัวแปร B สำหรับการทดสอบนั้นแย่มาก แต่สำหรับการชำระเงินก็อาจเป็นหายนะได้
การเปิดตัวที่สมเหตุสมผล
กระแสที่ฉันชอบคือ:
- ปรับใช้โดยปิดแฟล็ก;
- การจุดระเบิดสำหรับนักพัฒนาและ QA;
- การเปิดเครื่องสำหรับลูกค้านำร่องหรือผู้เช่า
- การเปิดตัว 5%;
- การเปิดตัวที่ 25%;
- การเปิดตัว 100%;
- การลบโค้ดและแฟล็กเก่าออก
จุดที่ถูกลืมบ่อยๆคือจุดสุดท้าย ธงชั่วคราวต้องมีวันตาย ถ้ามันคงอยู่ตลอดไป ทุก ๆ refactor ในอนาคตจะต้องถามว่า: "แต่สาขานี้ยังมีประโยชน์อยู่หรือไม่"
Kill switch: เตรียมตัวให้พร้อมก่อน
kill switch คือแฟล็กที่ช่วยคุณเมื่อการพึ่งพาภายนอกเริ่มรบกวนคุณ งานใช้ทรัพยากรมากเกินไป หรือตรรกะใหม่ทำให้เกิดข้อผิดพลาดแปลกๆ
kill switch ที่ดีจะต้องเป็น:
- หาง่าย
- บันทึกไว้ใน runbook;
- ทดสอบเป็นครั้งคราว
- สังเกตได้เมื่อเปิดใช้งาน;
- เป็นอิสระจากส่วนที่อาจแตกหักได้มากที่สุด
สิ่งที่เลวร้ายที่สุดคือการค้นพบระหว่างเกิดอุบัติเหตุว่ามีธงอยู่ แต่ไม่มีใครรู้ว่าธงยังใช้งานได้อยู่หรือไม่
การสังเกตหรือการส่งมอบไม่ก้าวหน้า
การเปิดคุณลักษณะที่ 10% โดยไม่ดูเมตริกเป็นเพียงการมองโลกในแง่ดีด้วยหลายขั้นตอน
การเปิดตัวแต่ละครั้งควรตอบคำถามง่ายๆ ดังนี้
- มีข้อผิดพลาดเพิ่มขึ้นหรือไม่?
- เวลาแฝงมีการเปลี่ยนแปลงหรือไม่?
- ผู้ใช้ทำโฟลว์เสร็จสมบูรณ์หรือไม่?
- มีตั๋วเพิ่มเติมหรือลองอีกครั้งหรือไม่
- ตัวแปรหนึ่งส่งผลกระทบเพียงเซ็กเมนต์เดียวหรือไม่
OpenFeature รองรับ hooks รอบการประเมินค่าสถานะ มีประโยชน์สำหรับการบันทึกข้อผิดพลาด การเพิ่มตัวชี้วัด หรือการเชื่อมโยงคะแนนไปที่ trace
การตั้งชื่อและความเป็นเจ้าของ
ชื่อมีความสำคัญ new_ui ไม่พูดอะไรเลย checkout.v2.enabled พูดได้มากกว่านั้นมาก
สำหรับแต่ละธง ฉันจะทำเครื่องหมายอย่างน้อย:
- ชื่อ;
- คำอธิบาย;
- เจ้าของ;
- ค่าเริ่มต้นที่ปลอดภัย
- เหตุผลว่าทำไมจึงมีอยู่
- วันที่หรือเงื่อนไขของการถอดถอน
ธงที่ไม่มีเจ้าของมักเป็นธงที่ไม่มีใครสามารถเคลียร์ได้
จะประเมินได้ที่ไหน
ส่วนหน้า ส่วนหลัง หรือขอบ? พึ่งพา.
หากแฟล็กมีไว้สำหรับเลย์เอาต์ คัดลอก หรือการเริ่มต้นใช้งาน ส่วนหน้าก็ใช้ได้ หากเกี่ยวข้องกับสิทธิ์ การเรียกเก็บเงิน ขีดจำกัด หรือข้อมูลที่ละเอียดอ่อน จะต้องอยู่ในแบ็กเอนด์ หากเกี่ยวข้องกับการทดลองการกำหนดเส้นทางหรือการรับส่งข้อมูลสูง Edge อาจสมเหตุสมผล
กฎง่ายๆ: ส่วนหน้าสามารถปรับปรุงประสบการณ์ได้ แต่ไม่ควรเป็นเพียงอุปสรรคด้านความปลอดภัยเท่านั้น
บทสรุป
feature flag ทำได้ดีเปลี่ยนความสัมพันธ์กับการผลิต พวกเขาไม่ได้ขจัดความเสี่ยง แต่ทำให้ความเสี่ยงเล็กลงและจัดการได้ง่ายขึ้น คุณสามารถปล่อยเป็นชิ้นๆ สังเกต หยุด ย้อนกลับ เรียนรู้
OpenFeature เพิ่มรากฐานที่สะอาด: API ทั่วไป ผู้ให้บริการที่ใช้แทนกันได้ และวิธีที่เป็นระเบียบมากขึ้นในการขยายระบบ แต่วินัยยังคงเป็นของคุณ: ค่าเริ่มต้นที่ปลอดภัย ชื่อที่ชัดเจน หน่วยวัด เจ้าของ และความสะอาด
ธงที่ดีที่สุดคือธงที่ช่วยให้คุณปล่อยอย่างสงบแล้วหายไปเมื่อไม่ต้องการอีกต่อไป