การวัดผลกระทบ Feature Flags ใน Ruby on Rails ด้วย AppSignal – คู่มือปฏิบัติ

Feature flags เป็นเครื่องมือทรงพลังในการพัฒนาซอฟต์แวร์ อนุญาตให้นักพัฒนาควบคุมพฤติกรรมของแอปพลิเคชันใน runtime โดยไม่ต้อง deploy โค้ดใหม่ พวกเขาช่วยให้ทีมทดสอบฟีเจอร์ใหม่ ทำ A/B testing และ roll out การเปลี่ยนแปลงอย่างค่อยเป็นค่อยไป

ใน Ruby on Rails feature flags สามารถจัดการได้โดยใช้เครื่องมือหลากหลาย ที่นิยมที่สุดคือ Flipper gem บทความนี้จะสำรวจการ implement และวัดผลกระทบของ feature flags ใน Solidus storefront โดยใช้ Flipper และ custom metrics ของ AppSignal

Feature Flags ใน Rails คืออะไร อีกครั้ง?

หากคุณมองหาบทนำเกี่ยวกับหัวข้อนี้ โปรดดูโพสต์ Add Feature Flags in Ruby on Rails with Flipper

ในข้อความสั้นๆ Feature flags เป็นวิธีที่จะส่งผลต่อวิธีที่แอปพลิเคชันของคุณทำงาน ใน runtime โดยไม่ต้อง deploy โค้ดใหม่ ประเภทที่เรียบง่ายที่สุดของ feature flags คือ environment variables ทุกแอปพลิเคชัน Ruby on Rails ใช้พวกมัน out of the box ตัวอย่างหนึ่งคือการกำหนดค่า application server concurrency โดยใช้ ENV['WEB_CONCURRENCY']

อย่างไรก็ตาม มีวิธีอื่นๆ ในการจัดการ feature flags เช่น การใช้ persistence layer อย่าง ActiveRecord หรือ Redis วิธีที่ครอบคลุมมากกว่าคือการใช้ Flipper gem

โค้ดสนิทต่อไปนี้แสดงตัวอย่างว่าจะประเมิน feature flag performance_improvement สำหรับ user ที่กำหนดอย่างไร:

ต่อไป เราจะตั้งค่า Solidus storefront เพื่อเริ่มทดลองกับ feature flags

แอปตัวอย่างของเรา: Solidus Storefront

เพื่อวัดผลกระทบของ feature flags ในสถานการณ์ที่สมจริงบ้าง ให้เรา bootstrap Solidus store อย่างรวดเร็ว:

Generator นี้จะนำคุณผ่านกระบวนการและถามคำถามการตั้งค่าบางอย่าง

1. เลือก frontend starter เมื่อถามถึง frontend type
2. ข้ามการตั้งค่า payment method
3. เลือกที่จะ mount Solidus application ของคุณที่ / เนื่องจากเราใช้มันเป็น standalone app

หลังจากนั้น รัน bin/dev จากเทอร์มินัลของคุณ และคุณควรพร้อมแล้ว เมื่อคุณไปที่ https://localhost:3000 คุณจะเห็นหน้าจอนี้:

Implement Feature Flags ด้วย Flipper

ตอนนี้มาลงมือ implement สอง use cases ตัวอย่างสำหรับ feature flags:

• Performance improvement (การปรับปรุงประสิทธิภาพ)
• Conversion rate optimization attempt (การพยายามเพิ่ม conversion rate)

ก่อนอื่น แต่อย่างไรก็ตาม เราต้องเพิ่ม gem flipper พร้อมกับ active_record storage adapter:

สิ่งนี้จะตั้งค่าตารางฐานข้อมูลที่จำเป็นเพื่อ lookup Flipper "gates" นั่นคือ conditionals ที่แท้จริงที่จะประเมินเมื่อตรวจสอบ feature flag

การทดสอบ Performance Improvement

เพื่อประเมินสถานการณ์นี้ เราจะจำลอง slow request ใน storefront โดยการเพิ่มการเรียก sleep 1 สำหรับกรณี unoptimized:

ตอนนี้ เราจะใช้กลยุทธ์ "percentage of time" เพื่อ roll out optimization ไปยังชุดคำขอสุ่ม เปิด Rails console และพิมพ์ต่อไปนี้:

โดยใช้ oha load testing tool เราสามารถยืนยันได้ว่า ครึ่งหนึ่งของคำขอใช้เวลานานกว่าอีกครึ่งหนึ่งหนึ่งวินาที:

การทดสอบ Conversion Rate Optimization

เมื่อจัดการกับ user-facing features ตัวอย่างเช่น การเปลี่ยนแปลงใน UI มักเหมาะสมที่จะใช้กลยุทธ์ "percentage of actors" เพื่อ roll out flags วิธีนี้ ทุก user จะได้รับประสบการณ์ที่สอดคล้องกันเสมอ

ดังนั้นเพื่อเริ่มต้น เราจะสร้างสอง users สำหรับแอป e-commerce ของเรา เปิด Rails console และออกคำสั่งต่อไปนี้:

สิ่งนี้สร้าง sample users สองคน และรับรองว่า feature flag consistently เปิดใช้งานสำหรับหนึ่งในพวกเขา

เพื่อจำลองฟีเจอร์ที่พยายามขับ conversion rates เราจะทำให้ checkout button กระพริบ:

หากเราล็อกอินด้วยทั้งสอง users และจัดหน้าต่างเบราว์เซอร์ติดกัน เราสามารถสังเกตได้ว่า effect นั้น active สำหรับ user คนหนึ่ง (ด้านซ้าย):

ใช้ AppSignal Custom Metrics เพื่อวัดผลกระทบของ Feature Flags

ระบบ feature flag ที่ดีที่สุดก็ไร้ประโยชน์หากไม่มีทางประเมินผลกระทบ ในสถานการณ์ตัวอย่างของเรา เราเพียงอยากรู้:

• Performance improvement นำไปสู่ latency reduction ที่ significant ไหม?
• Pulsating checkout button ของเรานำไปสู่ conversion rate ที่สูงขึ้นอย่าง significant ไหม?

เราจะใช้ custom metrics ของ AppSignal เพื่อวัดผลตอบแทนของ optimizations เหล่านี้

ก่อนอื่น สร้างแอปพลิเคชันใหม่ในองค์กร AppSignal ของคุณ และเชื่อมต่อกับแอปของคุณโดยปฏิบัติตามคำแนะนำ:

การวัด Latency ด้วย Measurement Metric

เราได้ยืนยันว่าการปรับปรุงของเรา effective อย่างไรด้วย oha CLI ข้างต้น แต่เพื่อทำ valid judgments เราจะติดตั้ง server-side telemetry ที่รายงาน latency ไปยัง AppSignal Measurement metric อนุญาตให้ทำได้พอดี: เราจะส่ง response times ใน milliseconds และเพิ่ม metric tag ที่ระบุว่า performance optimization ของเรา active สำหรับคำขอเฉพาะหรือไม่

มี gotcha เล็กน้อยที่นี่: เนื่องจากเราใช้ metric "Percentage of Time" เราต้อง capture state ของ flag ใน instance variable เพื่อให้ค่าเดียวกันถูกใช้สำหรับ execution และ reporting:

ตอนนี้มาทำ local load testing ซ้ำจากข้างต้น:

เราจะดู charting และการประเมิน metric นี้ในไม่ช้า ก่อนหน้านั้น มาเปลี่ยนไปที่ feature flag ที่สอง

การนับ Conversions ด้วย Count Metric

เราจะใช้ counter metric เพื่อนับ conversions นี่เป็นตัวเลือกที่ดีหากสิ่งที่คุณอยากทำคือแค่เก็บ tally ของ event

เพื่อทำสิ่งนี้ เราจะต้องเปิด CartsController และ เพื่อการสาธิต เพิ่มการเรียก increment_counter หาก checkout button ถูกคลิก:

ตอนนี้มาทดสอบโดยการเปิดหน้าต่างเบราว์เซอร์ respective และคลิกปุ่ม "Checkout" 3 ครั้ง และในอีกกรณีแค่ครั้งเดียว ดרךนี้ เราสามารถเห็นได้ว่า optimization flag active หรือไม่

ตั้งค่า Custom Dashboards ใน AppSignal

ขั้นตอนสุดท้ายของเราคือการสร้างกราฟิกที่ให้ข้อมูลเพื่อตัดสินใจทางธุรกิจที่ขับเคลื่อนด้วยข้อมูล เราจะใช้ dashboards ของ AppSignal เพื่อบรรลุสิ่งนี้ มาผ่านขั้นตอนทีละขั้น:

1. ในแถบด้านซ้าย คลิก "Add dashboard" และตั้งชื่อว่า "Feature Flag Evaluation"

1. คลิก "Add Graph" และ metric products_response_time เลือก "mean" เพื่อแสดงแค่ averages และ apply tag performance_improvement_enabled

1. คลิก "Add new Graph" เพื่อเพิ่ม chart สำหรับ checkout counts อีกครั้ง apply tag optimization_active

ตอนนี้ custom dashboard ของคุณพร้อมแล้ว ใน line graph ด้านซ้าย คุณสามารถยืนยันได้ว่า performance improvement ของคุณ effective ด้านขวา สังเกตว่า higher count ของ checkouts ใน optimized case ถูกบันทึก

และนั่นคือทั้งหมด!

สรุป

เราเห็นว่า feature flags เสนอวิธีที่ยืดหยุ่นและมีประสิทธิภาพในการจัดการและ deploy ฟีเจอร์ใหม่ในแอปพลิเคชัน Ruby on Rails ด้วยการใช้เครื่องมืออย่าง Flipper gem และ custom metrics ของ AppSignal นักพัฒนาสามารถไม่เพียงควบคุม feature rollouts แต่ยังวัดผลกระทบต่อประสิทธิภาพและพฤติกรรมผู้ใช้

แนวทางนี้รับรองว่าฟีเจอร์ใหม่ถูกทดสอบและเพิ่มประสิทธิภาพอย่างละเอียดก่อนที่จะ deployed เต็มที่ สุดท้ายนำไปสู่แอปพลิเคชันที่มั่นคงและใช้งานง่ายกว่า สุดท้าย อาจนำไปสู่ business decisions ที่มีข้อมูลมากขึ้นเมื่อประเมิน effectiveness ของ alternative approaches

Happy coding!

P.S. หากคุณอยากอ่าน Ruby Magic posts ทันทีที่พวกเขาออก ให้ subscribe Ruby Magic newsletter ของเรา และไม่เคยพลาดโพสต์เดี่ยว!

Julian Rubisch

ผู้เขียนรับเชิญ Julian เป็น freelance Ruby on Rails consultant ที่ตั้งอยู่ใน Vienna เฉพาะทางใน Reactive Rails ส่วนหนึ่งของ StimulusReflex core team เขาอยู่ที่ front line ของการพัฒนา cutting-edge HTML-over-the-wire technology ตั้งแต่ 2020

บทความทั้งหมดโดย Julian Rubisch