ในการสร้างระบบ Continuous Integration และ Continuous Delivery สำหรับ Mobile นั้น
มีหลายสิ่งอย่างที่ควรคำนึงถึง
ไม่ว่าจะเป็น
- จำนวนของ device ที่แตกต่าง
- การออกแบบของแต่ละ platform
- การพัฒนา
- โครงสร้างของ code
- การทดสอบ
- การ deploy
- การ release
โดยสิ่งที่เราต้องการคือ feedback loop ที่รวดเร็ว
แน่นอนว่ามันย่อมรวดเร็วกว่าระบบอื่น ๆ อย่างมาก
ดังนั้นสิ่งที่เราควรต้องทำการวางแผนงาน
จากนั้นลงมือทำและสร้างมันขึ้นมาดังนี้
1. Testing นั่นคือการทดสอบ คำถามคือจะทดสอบกันอย่างไรบ้าง ?
เนื่องจาก Mobile มันซับซ้อนและหลากหลายนะ ทั้ง hardware และ software
รวมทั้งระบบรอบข้างที่ Mobile app ต้องทำงานร่วมด้วย
ทำให้การทดสอบจะเยอะและซับซ้อนมาก ๆ
คำถามที่ตามมาคือ เรายังสามารถทดสอบแบบเดิม ๆ หรือ manual ได้หรือไม่ ?
ถ้าได้ แล้ว feedback loop มันเร็วเพียงใด !!
ดังนั้นสิ่งที่ขาดไม่ได้เลยคือ Automation testing
จะแบ่งออกเป็นสองส่วนคือ
- ส่วนที่ทดสอบได้เร็ว นั่นคือไม่จำเป็นต้องใช้ device/emulator เพื่อทดสอบในแต่ละส่วนว่าทำงานได้ตามที่คาดหวัง
- ส่วนที่ทดสอบได้ช้า แต่ต้องการทำให้แน่ใจว่าทำงานบน 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 จะไหวไหมนะ ?
ถ้าคิดว่าไหวก็ทำไป !!
แต่ผมคิดว่า เราน่าจะมาสร้างระบบที่ทำงานแบบอัตโนมัติกันให้มากขึ้นนะ
เพื่อลดการทำงานซ้ำ ๆ
เพื่อลดปัญหาเดิม ๆ ที่เกิดจากคน
คำถามคือ คุณพร้อมที่จะปรับปรุงหรือไม่ ?
ลงมือทำเถอะครับ จะรออะไรอยู่
