Feature Flags คืออะไร? สอน Progressive Delivery และ Feature Toggle สำหรับ DevOps 2026

Feature Flags (หรือ Feature Toggles) เป็นเทคนิคที่ทรงพลังที่สุดอย่างหนึ่งใน Modern Software Delivery ช่วยให้คุณ Deploy code ขึ้น Production ได้ทุกวัน โดยไม่ต้องเปิดฟีเจอร์ให้ User ทุกคนเห็นทันที ทำให้สามารถ Release อย่างปลอดภัย ทดสอบกับ User จริง และ Rollback ได้ทันทีโดยไม่ต้อง Redeploy

บทความนี้จะสอน Feature Flags ครบทุกเรื่อง ตั้งแต่แนวคิดพื้นฐาน, Progressive Delivery, A/B Testing, Platform ยอดนิยม ไปจนถึง Best Practices สำหรับทีม DevOps

อ่านเพิ่ม: Error Handling คืออะไร? Resilience Patterns สำหรับ Backend ท · อ่านเพิ่ม: SRE คืออะไร? Site Reliability Engineering แนวคิดจาก Google ส · อ่านเพิ่ม: Zero-Downtime Deployment คืออะไร? กลยุทธ์ Deploy แบบไม่มี Do

Feature Flags คืออะไร?

Feature Flags (Feature Toggles) คือเทคนิคที่ใช้ Configuration เพื่อควบคุมว่า Feature ใดจะเปิดหรือปิดใน Runtime โดยไม่ต้องแก้ Code หรือ Deploy ใหม่ เปรียบเหมือน "สวิตช์" ที่เปิด-ปิดฟีเจอร์ได้ทันที

// ตัวอย่างพื้นฐาน

if (featureFlags.isEnabled('new-checkout')) {

  showNewCheckout()

} else {

  showOldCheckout()

}

ประเภทของ Feature Flags

Progressive Delivery คืออะไร?

Progressive Delivery คือแนวทางการ Release ซอฟต์แวร์แบบค่อยๆ เปิดให้ User เข้าถึง แทนที่จะ Release ทีเดียวให้ทุกคน (Big Bang Release) ประกอบด้วยเทคนิค:

เนื้อหาเกี่ยวข้อง — ดูเพิ่มเติมเรื่อง Wireless Site Survey Clean Architecture

• Canary Release — ปล่อยให้ User กลุ่มเล็กก่อน (เช่น 1%) แล้วค่อยขยาย
• Percentage Rollout — ค่อยๆ เพิ่มเปอร์เซ็นต์ (1% → 10% → 50% → 100%)
• Ring Deployment — Release ทีละกลุ่ม (Internal → Beta → GA)
• A/B Testing — ทดสอบ 2 versions กับ User จริง วัดผลลัพธ์

User Targeting

// Target by attribute

const flag = {

  name: 'beta-feature',

  rules: [

    // เปิดให้ทุก internal users

    { attribute: 'email', operator: 'endsWith', value: '@company.com', enabled: true },

    // เปิดให้ users ในประเทศไทย

    { attribute: 'country', operator: 'equals', value: 'TH', enabled: true },

    // เปิดให้ premium users

    { attribute: 'plan', operator: 'in', value: ['pro', 'enterprise'], enabled: true },

    // เปิดให้ specific users

    { attribute: 'userId', operator: 'in', value: ['user-123', 'user-456'], enabled: true }

  ],

  defaultValue: false  // ปิดสำหรับ users ที่ไม่ตรง rules

}

Feature Flag Platforms เปรียบเทียบ

Flag Lifecycle Management

Feature Flags มี Lifecycle ที่ต้องจัดการ ไม่เช่นนั้นจะกลายเป็น Technical Debt:

1. Creation — สร้าง Flag พร้อม description, owner, expiry date
2. Development — ใช้ Flag wrap ฟีเจอร์ใหม่ในระหว่าง development
3. Testing — ทดสอบทั้ง flag on/off
4. Rollout — ค่อยๆ เปิด (Canary → Percentage → Full)
5. Full Release — เปิด 100%
6. Cleanup — ลบ Flag code ออก (สำคัญมาก!)

// ตัวอย่าง Flag metadata

{

  "new-checkout": {

    "enabled": true,

    "percentage": 100,

    "owner": "team-checkout",

    "created": "2026-03-01",

    "expires": "2026-05-01",

    "description": "New checkout flow with Apple Pay",

    "jira": "PROJ-1234",

    "status": "full-rollout",    // ready-for-cleanup

    "stale_after_days": 30

  }

}

Trunk-based Development + Feature Flags

Feature Flags ช่วยให้ทีมใช้ Trunk-based Development ได้อย่างมั่นใจ:

• ทุกคน commit เข้า main (trunk) ทุกวัน
• ฟีเจอร์ที่ยังไม่เสร็จซ่อนด้วย Feature Flag
• ไม่ต้องใช้ Long-lived Feature Branches
• Deploy main ไป production ทุกวัน (Continuous Deployment)
• เปิด/ปิดฟีเจอร์ผ่าน Flag โดยไม่ต้อง deploy ใหม่

Workflow

แนะนำเพิ่มเติม — iCafeForex

1. Developer สร้าง flag "new-search"

2. เขียน code wrap ด้วย flag

เนื้อหาเกี่ยวข้อง — บทความที่เกี่ยวข้อง: Python SQLAlchemy SSL TLS Certificate

3. Commit เข้า main → Deploy to production (flag ปิด)

4. ทดสอบใน production กับ internal users (flag เปิดเฉพาะ internal)

5. Canary release 5% → 25% → 50% → 100%

6. ลบ flag code → commit → deploy

แนะนำเพิ่มเติม — คู่มือเทรดจาก SiamCafeBook

ข้อดี:

• ไม่มี merge conflicts จาก long-lived branches
• ทุก commit ผ่าน CI/CD ทันที
• ฟีเจอร์ถูก test กับ production traffic จริง

Testing กับ Feature Flags

// ทดสอบทั้ง flag on และ off

describe('Checkout', () => {

  it('shows new checkout when flag is ON', () => {

    // Mock flag service

    jest.spyOn(flagService, 'isEnabled')

      .mockReturnValue(true)



    render(<CheckoutPage />)

    expect(screen.getByTestId('new-checkout')).toBeInTheDocument()

  })



  it('shows old checkout when flag is OFF', () => {

    jest.spyOn(flagService, 'isEnabled')

      .mockReturnValue(false)



    render(<CheckoutPage />)

    expect(screen.getByTestId('old-checkout')).toBeInTheDocument()

  })

})



// Integration test matrix

// ทดสอบ combinations ของ flags ที่อาจกระทบกัน

const flagCombinations = [

  { 'new-checkout': true, 'promo-bar': true },

  { 'new-checkout': true, 'promo-bar': false },

  { 'new-checkout': false, 'promo-bar': true },

  { 'new-checkout': false, 'promo-bar': false },

]

Best Practices

Anti-patterns ที่ต้องระวัง

• Flag Explosion — มี flags มากเกินไป (>100) โดยไม่ cleanup ทำให้ codebase ซับซ้อน
• Nested Flags — Flag ที่ depend กับ flag อื่น (if flag A && flag B && flag C) ยากต่อการ test
• Permanent Release Flags — ใช้ Release Flag แบบ permanent แทนที่จะ cleanup
• Flag-based Architecture — ออกแบบ architecture ทั้งหมดรอบ flags แทนที่จะใช้ proper abstraction
• Missing Default — ไม่มี default value เมื่อ flag service ล่ม

Flag-driven Development Workflow

Step-by-step workflow สำหรับทีม

เนื้อหาเกี่ยวข้อง — อ่านต่อ: GitLab CI Include Consensus Algorithm

1. Product: สร้าง feature flag ใน dashboard

• ตั้งชื่อ, description, owner, expiry

2. Dev: เขียน code wrap ด้วย flag

• commit เข้า main ทุกวัน

3. QA: ทดสอบ flag on/off ใน staging

• ทดสอบ edge cases, combinations

4. Release Manager: เปิด flag ให้ internal users

• Dogfooding ภายใน 1-2 วัน

5. Gradual Rollout: 5% → 25% → 50% → 100%

เนื้อหาเกี่ยวข้อง — AWS Fargate Developer Experience DX

• Monitor metrics ทุก stage

6. Cleanup: ลบ flag code + config

• PR review + merge ภายใน 2 สัปดาห์

สรุป

Feature Flags เป็นเครื่องมือสำคัญสำหรับ Modern Software Delivery ช่วยให้ทีม Deploy ได้บ่อยขึ้น Release อย่างปลอดภัย และ Rollback ได้ทันทีเมื่อเกิดปัญหา เมื่อรวมกับ Progressive Delivery ทำให้สามารถ Release ฟีเจอร์ใหม่ให้ User กลุ่มเล็กก่อน ทดสอบกับ Traffic จริง แล้วค่อยขยายไปทั้งระบบ

เริ่มต้นง่ายๆ: เลือก Platform ที่เหมาะกับทีม (Unleash สำหรับ self-hosted, LaunchDarkly สำหรับ enterprise, PostHog สำหรับ flags + analytics) สร้าง flag แรก wrap ฟีเจอร์ใหม่ แล้วลอง rollout ทีละ 10% — คุณจะเข้าใจทันทีว่าทำไม Feature Flags ถึงเปลี่ยนวิธีที่เรา deliver software