จากบทความเรื่อง Coding with Feature Flags: How-to Guide and Best Practices
ทำการอธิบายเกี่ยวกับ Feature Flag ว่าคืออะไร
เป็นอย่างไรบ้าง
มีปัญหาอะไรที่ต้องได้รับการแก้ไข
มีรูปแบบการใช้งานอย่างไรบ้าง
จึงทำการสรุปสิ่งที่น่าสนใจไว้นิดหน่อย
ลองไปอ่านเพิ่มเติมและนำไปใช้งานกันดู
อาจจะเรียกชื่ออื่น ๆ ได้อีก เช่น Feature toggle, swiching on/off เป็นต้น
สิ่งที่น่าสนใจคือ เมื่อใดเราจึงต้องใช้ Feature flag ด้วย
เริ่มด้วยเรื่องของ branching กัน
ถ้าใครเคยใช้ branching ใน version control ต่าง ๆ
ยกตัวอย่างเช่น CSV และ subversion
จะพบว่า การสร้าง branch ขึ้นมานั้น
ต้องคิดให้ดี ๆ เพราะว่าใช้ resource เท่าตัวเสมอ
ทำให้จำนวน branch ไม่เยอะมากนัก
หรือบางที่อาจจะทำการจัดการและพัฒนาแบบ Trunk-based development
คือมี branch เดียวนั่นเอง
แต่เมื่อเกิด Git ขึ้นมาซึ่งทำให้การสร้าง branch มันง่ายและไม่ใช้ resource น้อย
จึงก่อให้เกิด branch จำนวนมากขึ้นมา
ทั้ง master
ทั้ง develop
ทั้ง release
ทั้ง fix
ทั้ง feature branch
ทั้ง experiment
เมื่อจำนวน branch เยอะขึ้น
เรื่องของการ merge จึงสำคัญขึ้นอย่างมาก
ต้องทำด้วยความระมัดระวัง
ยิ่งในทีมมีสมาชิกจำนวนมาก
แน่นอนว่า active branch ก็เยอะ ยิ่งต้องระวังให้มาก ๆ
ดังนั้นจึงมีการคิดและสร้างวิธีการมากมายเพื่อมาจัดการ
ยกตัวอย่างวิธีการที่ได้รับความนิยมคือ Git Flow
ซึ่งในการทำงานและจัดการ
ก็ยังต้องการการพุดคุย
เพื่อให้มันตรงกับความต้องการ
บางครั้งมันทำให้เกิดความปวดหัวในการจัดการอีกด้วย
ทั้งเรื่องข้อขัดแย้งที่เกิดจากการ merge
ทั้งเรื่องของการวางแผนในการแยก branch
ทั้งเรื่องของการสร้าง Continuous Integration มาเพื่อช่วยตรวจสอบสิ่งที่เปลี่ยนแปลง
แต่ปัญหาจริง ๆ ที่เราเห็นอาจจะไม่ใช่การแตก branch
ปัญหาที่แท้จริงคือ branch ที่สร้าง มีอายุนานเกินไป
ดังนั้น ถ้าอายุของ branch สั้น ๆ หรือ ไม่ต้องสร้าง branch ขึ้นมา
ก็ไม่น่าจะมีปัญหา หรือ มีปัญหาน้อยลงนะ
เพราะว่า เราทำงานกันบน branch เดียวกันไปเลย
หรือเราทำงานบน code ชุดเดียวกัน
ไม่น่ามีปัญหาเรื่องการ merge ใช่ไหม ?
ถ้ามีเพียง branch เดียว ปัญหาก็ตามมาอีก
- พัฒนา feature จำนวนมากพร้อมกัน แต่ release หรือ deploy ไม่พร้อมกัน การแตก branch ไปน่าจะดีกว่าไหม ?
- พัฒนา feature เพื่อทดลอง ถ้าไม่ work ก็จะได้ลบ code หรือ feature ทิ้งไปได้ง่าย ๆ
หนึ่งในวิธีการแก้ไขคือ Feature Flag นั่นเอง
เพื่อทำการแยกแต่ละ feature อย่างชัดเจน
สามารถกำหนดว่าจะเปิดหรือปิดแต่ละ feature ได้เลย
นั่นคือ เราสามารถ deploy code ที่ไม่เสร็จขึ้นได้ด้วย
แต่ feature นั้น ๆ ยังปิดอยู่
แต่เราต้องวางแผนกันก่อนนนะ มิเช่นนั้นเละแน่นอน
อีกหนึ่งที่สำคัญมาก ๆ ของ Feature Flag คือ
จำนวน feature flag ที่ทำการจัดการนั้นต้องไม่เยอะ
Feature อะไรที่มันขึ้นไปแล้ว ก็เอา feature flag ออกไปซะ
ใช้เท่าที่จำเป็นเท่านั้น
อะไรที่ไม่ใช้ก็ลบไปบ้าง
มิเช่นนั้น ก็จะเกิดความซับซ้อนยากต่อการจัดการ
เช่นเดียวกับ branch เยอะ ๆ อีกนั่นเอง