ทำความรู้จักกับ Feature Flag-Driven Development

จากบทความเรื่อง 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 เยอะมาก ๆ สามารถดูได้จาก

• http://www.beautifulbuilds.com/feature-toggle-frameworks-list/
• http://featureflags.io/resources/

มาทำความรู้จักกับ Feature Flag Driven Development กัน

การพัฒนาด้วยแนวคิด Feature Flag นั้น จำเป็นอย่างยิ่งต้องพัฒนาด้วยแนวคิด Test-Driven Development (TDD) เนื่องจากขั้นตอนในการ rollout และ release feature ของระบบมันเร็วมาก รวมทั้งรอบการ rollout และ release feature มันบ่อยมาก ดังนั้นเราจึงต้องมีวิธีการทดสอบที่รวดเร็ว หรือสามารถรู้ความผิดพลาดได้อย่างรวดเร็ว เพื่อทำให้สามารถปรับปรุงการระบบ และ การทำงานได้อย่างรวดเร็วเช่นกัน ขั้นตอนการพัฒนาเป็นดังนี้

1. เพิ่ม feature flag สำหรับ feature ใหม่ และ  feature ที่ต้องการเปลี่ยน
2. ทำการเขียน code สำหรับพัฒนา feature
3. ทำการ deploy และ release เพื่อวัดผล
4. เลือก feature ที่ได้ผลออกมาดี และ เปิด feature ที่ผลไม่ได้
5. ทำซ้ำ ๆ แบบนี้กับ 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 ระบบ