![]()
อ่านบทความเรื่อง
Rapid release at massive scale จาก Facebook
แล้วไปเจอ paper ที่ทาง facebook เขียนไว้คือ
Continuous Deployment of Mobile Software at Facebook (Showcase)
ตามจริงมี paper ที่เกี่ยวข้องอีกหลายฉบับเลย
ใน paper ฉบับนี้มีความน่าสนใจในเรื่อง
- Release cycle ของ mobile app ทั้ง iOS และ Android
- การจัดเก็บข้อมูลต่าง ๆ ที่เกี่ยวกับการ release และ deployment
- การทดสอบระบบงาน
- มีการสรุปข้อมูลต่าง ๆ ของการพัฒนาอีกด้วย
ดังนั้นมาดูกันนิดหน่อย
เปิดด้วยข้อสรุปของ paper นี้ดีกว่า
รอบของการ release ระบบที่สั้น ๆ นั้น
ช่วยทำให้ Time to Market เร็วขึ้น
ช่วยทำให้ได้รับ feedback จากผู้ใช้งานเร็วและดีขึ้น
แต่การมีเพียง continuous deployment เพียงอย่างเดียว
มันไม่ได้ช่วยเพิ่ม productivity ของทีมพัฒนาหรอกนะ
รอบการ release ที่สั้นลงนั้น
มันเป็นการบังคับให้องค์กร ให้ทีมต้องทำการปรับปรุงสิ่งต่าง ๆ ด้วยเช่นกัน
ทั้งคน
ทั้งกระบวนการ
ทั้งเครื่องมือ
และการทดสอบแบบอัตโนมัติ
สำหรับการ release ของ Mobile app นั้นมันไม่ง่ายเลยทั้งการ rollout และ rollback
ดังนั้นสิ่งที่นำมาใช้งานคือ
Feature Flag
เพื่อให้สามารถเปิดหรือปิด function/feature ของระบบจาก server ได้ง่าย ๆ
ดังนั้นถ้า function/feature ใด ๆ มีปัญหา
ก็สามารถทำการปิดจาก server ได้เลย
การ release แบบรอบสั้น ๆ ช่วยลดปัญหาต่าง ๆ ลงไป
เช่นข้อขัดแย้งของ code ในไฟล์เดียวกัน ที่ต้องแก้ไขจากหลาย ๆ คน
เรื่องของ Mobile Release Cycle
โดยแบ่งออกเป็นสองส่วนคือ
- Development Activity โดยนักพัฒนาจะทำการ push code ไปที่ Master branch
- Deployment Activity โดย Release engineer จะทำการ cut code จาก Master branch มายัง Release branch
จากนั้นก็เข้าสู่กระบวนการ release ต่อไป
Release Cycle สำหรับ iOS เป็นดังรูป
โดยแบ่งเป็นรอบ ๆ ละ 2 สัปดาห์
![]()
เรื่องการจัดเก็บข้อมูลของแต่ละ release และ deployment
มีเยอะมาก ๆ ยกตัวอย่างเช่น
- Revision-control system records เก็บข้อมูลของแต่ละ commit, push เช่น จำนวนบรรทัดและเจ้าของ เป็นต้น
- Crash database เป็นระบบ crash report ซึ่งจะได้รับข้อมูลเมื่อ FB app มีปัญหา ซึ่งแบ่งตามการ release ไป
- Flytrap database เก็บข้อมูลของ issue ต่าง ๆ ที่ถูก report มาจากผู้ใช้ภายในและภายนอก
- Tasks database เป็น database หลักของทีม Release Engineer ซึ่งเก็บข้อมูล task ต่าง ๆ ทั้งการ implement และ issue ต่าง ๆ ที่ทำ
- Production issue database ปัญหาต่าง ๆ ที่เกิดขึ้นบน production
- Daily Active People (DAP) ข้อมูลผู้ใช้งาน Facebook app ในแต่ละวัน
โดยข้อมูลเหล่านี้จะนำมาใช้ในการวิเคราะห์ต่อไป
เรื่องการทดสอบระบบงาน
การทดสอบเป็นสิ่งที่สำคัญมากสำหรับ Mobile app เนื่องจาก
- Mobile software มีการเปลี่ยนแปลงที่บ่อยและเยอะมาก ๆ
- จำนวน device และ version ของ device มีมากมายและแตกต่างกัน
- ยากต่อการแก้ไขปัญหาที่เกิดขึ้นหลังจากการ deploy/release !!
โดยการทดสอบของ FB app นั้นจะมีการทดสอบต่าง ๆ เหล่านี้
- Unit test เป็น white-box testing สำหรับการ verify การทำงานในส่วนต่าง ๆ
- Static Analysis เป็นการวิเคราะห์ source code เพื่อช่วยหาจุดที่อาจจะก่อให้เกิดปัญหาได้ เช่น null pointer, resource leak และ memory leak เป็นต้น
- Build test เป็นการทดสอบว่า source code ทั้งหมดยัง build ได้
- Snapshot test เป็นการทดสอบโดยบันทึกแต่ละหน้าจอเป็นรูปภาพ จากนั้นเอามาเปรียบเทียบกับสิ่งที่ต้องการ
- Integration test เป็น black-box testing เพื่อทดสอบการทำงานในแต่ละ feature และ flow ต่าง ๆ ทั้งหมด นั่นคือ regression test นั่นเอง
- Performance test เป็นการทดสอบใน mobile lab เน้นในเรื่องประสิทธิภาพของการทำงาน รวมทั้งการใช้งาน resource ต่าง ๆ อีกด้วย
สิ่งที่น่าสนอีกเรื่องของ Testing Principle
- Coverage การทดสอบต้องครอบคลุมการทำงานในส่วนต่าง ๆ และแต่ละ test ต้องมีประโยชน์และทำการทดสอบบ่อย ๆ
- Responsive การทดสอบต้องเร็ว เมื่อเกิดปัญหาต้องบอกได้เลยว่าเป็นปัญหาจากอะไร ตรงไหน
- Quality
- Automation การทดสอบต้องทำงานแบบอัตโนมัติให้ได้มากที่สุดเท่าที่จะเป็นไปได้ จะทำให้สามารถทดสอบซ้ำแล้วซ้ำอีกได้ และทดสอบได้บ่อยเท่าที่ต้องการ
- Prioritization ต้องจัดเรียงลำดับความสำคัญของการทดสอบด้วย เนื่องจากการทดสอบต้องใช้ resource ต่าง ๆ เยอะ แต่ก็ต้องการความเร็วเช่นกัน ยกตัวอย่างเช่น developer อยากรู้ว่า code มีปัญหาหรือไม่ ดังนั้นทำการทดสอบ unit test ก่อน เพื่อให้นักพัฒนารู้ผล จากนั้นจึงทำการทดสอบ integration test ต่อไป
และสิ่งที่ขาดไปไม่ได้เลยคือ Testing Infrastructure
และแน่นอนว่า Manual testing ก็ยังไม่อยู่เช่นกัน
ส่วนผลการวิเคราะห์ในมุมต่าง ๆ ลองอ่านใน Paper ดูนะครับ
