Stripe คือ payment service สำหรับระบบที่ต้องการจ่ายเงินผ่าน internet
โดยทีมพัฒนาทำการเขียนบทความเรื่อง
การลดเวลาทดสอบจาก 3 ชั่วโมงเหลือเพียง 3 นาที
ซึ่งในบทความมีแนวคิดที่น่าสนใจมากมาย
ดังนั้น เรามาดูกันหน่อยสิ ว่ามีวิธีการอย่างไรบ้าง ?
ข้อมูลเบื้องต้น
ในการพัฒนาระบบ Stripe นั้น
จะมีชุดการทดสอบแบบอัตโนมัติ
เพื่อช่วยทำให้ระบบที่พัฒนามีความเสถียร น่าเชื่อถือ
ซึ่งจะครอบคลุมไปยังส่วนการทำงานต่าง ๆ ทั้งหมด
ทำการ run test ผ่านระบบ Continuous Integration
และจะทำการ deploy ได้หลังจากที่การทำงานผ่านทั้งหมดเท่านั้น
ยิ่งนานวัน ระบบงานยิ่งมีความซับซ้อนสูงขึ้นเรื่อย ๆ
ขนาดของ code ก็ใหญ่ขึ้นเรื่อย ๆ
ส่งผลให้ขนาด หรือ จำนวนของการทดสอบสูงขึ้นตามเช่นกัน
โดยในเดือนสิงหาคม 2015 นี้
- ประกอบไปด้วย 1,400 ไฟล์
- ประกอบไปด้วย 15,000 การทดสอบ
- ประกอบไปด้วย 130,000 assertion
ทั้งหมดใช้เวลาการทดสอบถึง 3 ชั่วโมงบนระบบ Continuous Integration !!!
ถ้าทำการ run แบบเรียงตามลำดับ …
นี่คือปัญหาที่เกิดขึ้น และ ต้องทำการแก้ไขโดยเร่งด่วน
นักพัฒนาทุกคนจะต้องรอให้ test มัน run จนเสร็จในทุก ๆ การเปลี่ยนแปลง !!!
ให้รอ 3 ชั่วโมง … มันเป็นปัญหาใหญ่มากมาย
คำถาม
แก้ไขปัญหานี้อย่างไรดีล่ะ ?
คำตอบ
ในอดีตนั้นใช้วิธีการเพิ่มเครื่องในระบบ Continuous Integration
แต่เมื่อใช้งานไปได้สักพัก พบว่ามันมีปัญหาตามมากมาย
โดยระบบ Continuous Integration เป็นพวก service จากที่อื่นนะ
ดังนั้นจึงเปลี่ยน !!!
โดยซื้อเครื่องมาทำเองดีกว่า
เนื่องจากสามารถควบคุมการทดสอบในรูปแบบต่าง ๆ ได้เอง
รวมทั้งสามารถทดลองวิธีการใหม่ ๆ ได้ง่ายอีกด้วย
จากการลองผิดลองถูก
จึงได้วิธีการลดเวลาการทดสอบจาก 3 ชั่วโมงให้เหลือเพียง 3 นาที
นั่นก็คือ “Distributed test runner”
มาดูกันว่าต้องทำอะไรบ้าง ?
1. ทำการทดสอบแบบ parallel
ระบบพัฒนาด้วยภาษา Ruby ซึ่งเขียน test ด้วย minitest
ดังนั้นสิ่งที่ทีมพัฒนาทำคือ
สร้าง plugin เพื่อ run test แบบ parallel
ทั้ง multiple CPU และ multiple server
2. ใช้ Docker สิ
เนื่องจาก process การทำงานมีเยอะมาก
ดังนั้นใน build หรือทำงานจะอยู่ภายใน Docker ทั้งหมด
นั่นทำให้ไม่ต้องสนใจเรื่องการ clean up
หรือคืน resource ให้กับระบบหลังจากทดสอบเสร็จสิ้น
3. การจัดการ build worker
ในการ build และ ทดสอบ จะอยู่ใน Jenkins ทั้งหมด
ดังนั้น การจัดการ build worker จึงง่ายมากขึ้น
ไม่ต้องมาเขียน code และ custom อะไรให้ยุ่งยาก
ใช้เพียงแค่ plug-in เท่านั้น เช่น
- Matrix build plug-in สำหรับการออกแบบและแยก build worker process
- Heavy job plugin สำหรับจัดการ job ต่าง ๆ
4. Visualization แสดงการทำงานอยู่ในรูปแบบกราฟซะ
เพื่อทำให้ทีมพัฒนาเข้าใจถึงปัญหา หรือ สถานะของสิ่งที่ทำอยู่
แทนที่จะต้องทำการ debug เพื่อทำการแก้ไข
ก็ให้แสดงข้อมูลทุก ๆ อย่างอยู่ในรูปแบบกราฟที่เข้าใจง่ายซะ
มันจะทำให้เราเห็นรูปแบบของปัญหาต่าง ๆ ได้ชัดเจนขึ้น
ทำให้คุณสามารถชี้จุดของปัญหาได้อย่างทันท่วงที
โดยทีมพัฒนาของ Stripe ใช้กราฟชื่อว่า Waterfall chart
สุดท้ายแล้ว
หวังว่าวิธีการและแนวคิดต่าง ๆ จะเป็นประโยชน์ไม่มากก็น้อย
สำหรับทีมพัฒนาที่ต้องการปรับปรุงความเร็วของการทดสอบนะครับ
ซึ่งแน่นอนว่าทางทีมของ Stripe ก็ยังทำการทดลองวิธีการใหม่ ๆ
เพื่อปรับปรุงกระบวนการทำงาน ให้ดีขึ้นอย่างต่อเนื่อง
แล้วคุณล่ะ มีวิธีการอย่างไรบ้าง ?
