จากบทความเรื่อง Feature Flag-Driven Development
ทำการอธิบายถึงพื้นฐาน และ ที่ไปที่มาของ feature flag ได้อย่างน่าสนใจ
ตั้งแต่การนำมาใช้งานสำหรับการ rollout ระบบ
ไปจนถึงการทำ A/B Testing
ดังนั้น จึงนำมาแปล และ สรุปส่วนที่น่าสนใจไว้ดังนี้
ทำความรู้จักกับ Feature Flag กันก่อน
มันมีชื่อเรียกมากมาย เช่น
- Feature Flag
- Feature Bit
- Feature Toggle
- Feature Control
- Feature Flipper
- Feature Rollout
- Feature Switch
มีเป้าหมายเพื่อควบคุมการปล่อย feature ของระบบให้ผู้ใช้งานนั่นเอง
ทำให้เราสามารถจัดการ และ เลือกได้ว่า
จะทำการเปิด หรือ ปิด feature อะไรบ้าง
จาก component อะไรให้ลูกค้าใช้ได้บ้าง
ตลอดจนสามารถไปใช้กับการเปิด feature ให้กับผู้ใช้งานบางกลุ่ม
หรือการทำ A/B Testing อีกด้วย
เป้าหมายหลักอีกอย่าง คือ การลดความเสี่ยงของการ rollout ระบบงาน
ซึ่งเรามักชอบทำแบบ Big Bang หรือทั้งระบบ
และมักพบว่า มีความผิดพลาดตามมาเยอะมาก !!
ดังนั้น เราน่าจะหาวิธีการใหม่ ๆ มาแก้ไขกันดีไหม ?
แล้ว Feature Flag มันทำงานอย่างไร ?
มีขั้นตอนการทำงานดังนี้
- ผู้ใช้งานเข้ามายังระบบ
- ระบบงานทำการตรวจสอบว่าผู้ใช้งานนั้นเป็นใคร อยู่กลุ่มไหน เพื่อเปิด feature ให้ใช้งานตามที่กำหนด
แสดงดังรูป
เราจะสร้าง Feature Flag ได้อย่างไร ?
จากรูปจะเห็นว่า สถานะของ feature มันมีเพียง TRUE กับ FALSE
หรือสถานะเปิด กับ ปิด เท่านั้นเอง
ซึ่งพัฒนาได้ง่ายมาก ๆ
แต่สิ่งที่ยากกว่ามาก ๆ คือ
จะทำการออกแบบเพื่อแบ่งการทำงานของแต่ละ feature ออกจากกันได้อย่างไร ?
นั่นคือ ความท้าทายของการออกแบบระบบ
และเป็นหัวใจของวิธีการนี้ !!
ในปัจจุบันมีเครื่องมือ และ framework ในการจัดการ Feature Flag เยอะมาก ๆ
สามารถดูได้จาก
มาทำความรู้จักกับ Feature Flag Driven Development กัน
การพัฒนาด้วยแนวคิด Feature Flag นั้น
จำเป็นอย่างยิ่งต้องพัฒนาด้วยแนวคิด Test-Driven Development (TDD)
เนื่องจากขั้นตอนในการ rollout และ release feature ของระบบมันเร็วมาก
รวมทั้งรอบการ rollout และ release feature มันบ่อยมาก
ดังนั้นเราจึงต้องมีวิธีการทดสอบที่รวดเร็ว
หรือสามารถรู้ความผิดพลาดได้อย่างรวดเร็ว
เพื่อทำให้สามารถปรับปรุงการระบบ และ การทำงานได้อย่างรวดเร็วเช่นกัน
ขั้นตอนการพัฒนาเป็นดังนี้
- เพิ่ม feature flag สำหรับ feature ใหม่ และ feature ที่ต้องการเปลี่ยน
- ทำการเขียน code สำหรับพัฒนา feature
- ทำการ deploy และ release เพื่อวัดผล
- เลือก feature ที่ได้ผลออกมาดี และ เปิด feature ที่ผลไม่ได้
- ทำซ้ำ ๆ แบบนี้กับ feature ใหม่ และ feature ที่ต้องการเปลี่ยน
แนวคิดนี้ มันเป็นวิธีการเพื่อให้เราได้ feedback จากลูกค้าได้อย่างรวดเร็ว
รวมทั้งทำให้เราสามารถตอบสนองต่อการเปลี่ยนแปลงได้อย่างรวดเร็วเช่นกัน
โดยรูปแบบการทำงานของ Feature Flag Driven Development
เน้นที่ feedback จากลูกค้าเป็นหลัก
จากนั้นทำการปรับปรุง แก้ไข และทำการ rollout/release
และรับ feedback ซ้ำ ๆ แบบนี้ไปเรื่อย ๆ
หรืออาจจะเรียกได้ว่า Small is Better และ Rollout at scale
ซึ่งมันจะแตกต่างจากการพัฒนาในรูปแบบเดิม
แสดงดังรูป
สุดท้ายแล้ว
ลด ละ เลิก การ rollout/release ระบบแบบ Big Bang กันเถอะนะ
ยังไม่พอนะ เราสามารถนำแนวคิดเหล่านี้ไปใช้กับเรื่องอื่น ๆ ได้อีกด้วย
ตัวอย่างเช่น
- ทำ A/B Testing
- ทำการ run Beta program บน production server
- ปิด หรือ ลบ feature ที่ไม่มีคนใช้ทิ้งไป
- แน่นอนว่า ทำให้การ rollout feature ต่าง ๆ ของระบบทำได้ง่าย และ บ่อย นั่นคือการ scale ใช่หรือไม่
- ทำการ block ผู้ใช้งานในแต่ละ feature
- ใช้สำหรับการจัดการเรื่อง Subscription plan ของระบบ
- จัดกลุ่ม feature ให้เหมาะกับกลุ่มผู้ใช้งาน เช่น beginner และ expert เป็นต้น
- สำหรับการปิด maintenance ระบบ
