ปัญหาที่มักพบเจอกับระบบ Continuous Delivery ของ Mobile app

ในการสร้างระบบ Continuous Integration และ Continuous Delivery สำหรับ Mobile นั้น มีหลายสิ่งอย่างที่ควรคำนึงถึง ไม่ว่าจะเป็น

• จำนวนของ device ที่แตกต่าง
• การออกแบบของแต่ละ platform
• การพัฒนา
• โครงสร้างของ code
• การทดสอบ
• การ deploy
• การ release

โดยสิ่งที่เราต้องการคือ feedback loop ที่รวดเร็ว แน่นอนว่ามันย่อมรวดเร็วกว่าระบบอื่น ๆ อย่างมาก ดังนั้นสิ่งที่เราควรต้องทำการวางแผนงาน จากนั้นลงมือทำและสร้างมันขึ้นมาดังนี้

1. Testing นั่นคือการทดสอบ คำถามคือจะทดสอบกันอย่างไรบ้าง ?

เนื่องจาก Mobile มันซับซ้อนและหลากหลายนะ ทั้ง hardware และ software รวมทั้งระบบรอบข้างที่ Mobile app ต้องทำงานร่วมด้วย ทำให้การทดสอบจะเยอะและซับซ้อนมาก ๆ คำถามที่ตามมาคือ เรายังสามารถทดสอบแบบเดิม ๆ หรือ manual ได้หรือไม่ ? ถ้าได้ แล้ว feedback loop มันเร็วเพียงใด !! ดังนั้นสิ่งที่ขาดไม่ได้เลยคือ Automation testing จะแบ่งออกเป็นสองส่วนคือ

1. ส่วนที่ทดสอบได้เร็ว นั่นคือไม่จำเป็นต้องใช้ device/emulator เพื่อทดสอบในแต่ละส่วนว่าทำงานได้ตามที่คาดหวัง
2. ส่วนที่ทดสอบได้ช้า แต่ต้องการทำให้แน่ใจว่าทำงานบน device/emulator จริง ๆ ได้

2. จำนวน Branch ของ code

สิ่งที่ควรคำนึงมาก ๆ คือ จำนวน branch ของ code เช่นจะใช้ branch เท่าไร และอย่างไรบ้าง เช่นแยก branch ตาม device เช่น mobile และ tablet เป็นต้น เพื่อทำให้การดูแลรักษาง่ายขึ้น หรือจะแยกตาม feature !!

ยิ่ง branch มากขึ้นเท่าไร การดูแลรักษาจะยากขึ้นมากเท่านั้น

3. โครงสร้าง code เอื้อต่อการทดสอบหรือไม่ ? (Testable app)

ข้อนี้จำเกี่ยวข้องกับข้อ 1 อย่างมากซึ่งมีการทดสอบ 2 ส่วน ลองคิดดูสิว่า ถ้าโครงสร้างของ code ไม่เอื้อต่อการทดสอบ การทดสอบแบบอัตโนมัติก็ยากมาก ๆ ถึงทำไปก็ไร้ประโยชน์หรือมีน้อยมาก ๆ ดังนั้นสิ่งที่ควรให้ความสนใจคือ Testable app การแยกส่วนการทำงานออกเป็นส่วน ๆ แต่ละส่วนสามารถทดสอบได้ง่าย ดังนั้นขึ้นการ pair programming และ code review จึงขาดไม่ได้ เพื่อปรับปรุง feedback loop ให้รวดเร็วขึ้น

4. Environment ที่เกี่ยวข้องสนับสนุนหรือไม่ ?

แน่นอนว่า Mobile app มักจะต้องทำงานร่วมกับระบบอื่น ๆ และระบบต่าง ๆ เหล่านี้มักก่อให้เกิดปัญหาตามมามากมาย ตัวอย่างเช่น สามารถทดสอบซ้ำ ๆ ได้หรือไม่ ? ใช้เวลาในการ setup ข้อมูลสำหรับการทดสอบนานหรือไม่ ? นั่นคือระบบต่าง ๆ เอื้อต่อ Automation test หรือไม่ ? ถ้าไม่ นั่นคือปัญหาที่ต้องแก้ไข เพื่อให้ได้รับ feedback ที่มีค่ายิ่ง

5. Automation Deployment

จากข้อ 1 ถึงข้อ 4 พูดเครื่องของ Internal quality ล้วน ๆ ดังนั้นเราต้องส่งมอบสิ่งที่พัฒนาขึ้นมา ออกไปยังผู้ใช้งานหรือลูกค้าให้รวดเร็วและบ่อย เพื่อให้เราได้รับ feedback จากผู้ใช้งานจริง ๆ ว่าสิ่งที่เราพัฒนาขึ้นมานั้นมีประโยชน์ หรือช่วยผู้ใช้งานอย่างไรบ้าง เพื่อนำมาปรับปรุงและแก้ไขต่อไป คำถามคือ ถ้ายังมาทำแบบ manual process จะไหวไหมนะ ? ถ้าคิดว่าไหวก็ทำไป !! แต่ผมคิดว่า เราน่าจะมาสร้างระบบที่ทำงานแบบอัตโนมัติกันให้มากขึ้นนะ เพื่อลดการทำงานซ้ำ ๆ เพื่อลดปัญหาเดิม ๆ ที่เกิดจากคน

คำถามคือ คุณพร้อมที่จะปรับปรุงหรือไม่ ? ลงมือทำเถอะครับ จะรออะไรอยู่