Time to Main คือตัวชี้วัดที่ดีสำหรับ Continuous Integration

จากหนังสือ Beautiful Builds ทำการอธิบายเกี่ยวกับ Time to Main หรือ Time to Trunk ซึ่งเป็นสิ่งที่ใช้วัดเรื่อง Continuous Integration มาดูกันว่า Time to Main มันคืออะไร ? และมันใช้วัดอย่างไร เพื่ออะไร ? ผมคิดว่าหลาย ๆ ทีมได้นำแนวคิด Continuous Integration ไปใช้งาน หรืออาจจะสร้างระบบ Continuous Integration ขึ้นมา เพื่อทำให้ขั้นตอนการพัฒนาดีขึ้น เช่น การ build การทดสอบ เป็นต้น

คำถามที่น่าสนใจคือ

เราจะทำการวัดว่าระบบ Continuous Integration ของเรามันเป็นอย่างไร ? เราจะรู้ได้อย่างไรว่า ระบบที่กำลังพัฒนามันค่อย ๆ โตขึ้นตามเป้าหมายที่วางไว้นะ ? หลาย ๆ ที่จะต้องมีตัวชี้วัดในการทำงาน เช่น KPI (Key Performance Indicator) เพื่อช่วยให้เราไปถึงฝั่งฝัน หรือ เป้าหมายที่ตั้งไว้ เช่นเดียวกันสำหรับ Time to Main ก็เป็นหนึ่งในตัวชี้วัดที่น่าสนใจตัวหนึ่งของการพัฒนาระบบงาน

มาดูตัวอย่างของปัญหาที่ต้องได้รับการแก้ไข

โดยปกติในการพัฒนาระบบงาน ต้องมีหลายทีมทำงานร่วมกัน ระบบงานมี Architecture ที่ดีสุด ๆ จึงทำให้เกิด dependency ระหว่างทีมมากมายไปหมด แสดงดังรูป คำอธิบาย มีทีมพัฒนาในระบบนี้ 4 ทีม แต่ละทีมก็มี branch สำหรับจัดการ code ของแต่ละทีมไป โดยในการ release ระบบงานจะอยู่ที่ main branch สิ่งที่มันสนุกก็คือ ทุก ๆ ทีมจะต้องใช้ Library จากทีม NEO เสมอ ไอ้ทีม NEO มันต้องเป็น Component team สำหรับทำระบบหลักแน่ ๆ นั่นหมายความว่าทีม NEO มันคือ dependency ของทุก ๆ ทีม ยังไม่พอนะ จากนั้นทีม HAMMER จะทำการ update และ build binary เพื่อส่ง binary ไปให้กับทีม ORCA จากนั้นทีม ORCA จะทำการ update และ build binary เพื่อส่ง binary ไปให้กับทีม DRAGON จากนั้นทีม DRAGON จะทำการ update และ build binary เพื่อส่ง binary ไปให้กับทีม ADAM เมื่อทุกอย่างเรียบร้อย จึงทำการ merge code ไปยัง main branch ตามลำดับ

มาถึงตรงนี้ น่าจะพอเห็นภาพของปัญหาแล้วนะ

หรือว่ามีใครบ้างทำงานในรูปแบบนี้อยู่บ้าง ? เราสามารถทำการปรับปรุงขั้นตอนการทำงานให้มันดีขึ้นได้ แต่ก่อนอื่นเราต้องการวิธีการวัดก่อนนะ ว่าจะทำการวัดอย่างไร เพื่อจะได้บอกว่า สิ่งที่เรากำลังจะทำต่อไปนี้ มันทำให้ขั้นตอนการทำงานดีขึ้นนะ หนึ่งในวิธีการวัด คือ Time to Main ไงล่ะ !!

นั่นคือ เราใช้เวลานานเท่าไรกว่าจะทำการ merge code จากทุกทีมมายัง main branch ?

มาดูสถานการณ์ในปัจจุบันก่อนสิ จากรูปจะใช้เวลา Time to Main = 1 + 3 + 3 + 5 = 12 วัน ยังไม่พอต้องเผื่อเวลาในการ merge code อีกนะ เพราะว่า ถ้าระบบใหญ่ ๆ จะมี code จำนวนมาก ดังนั้นเผื่อไปอีกสัก 3 วัน สรุปแล้ว Time to Main = 15 วัน นี่ยังไม่รวมการทดสอบอีกนะ ว่าทำแบบ manual หรือ automated เมื่อเรารู้ค่าเริ่มต้น หรือ based line หรือ สถานะปัจจุบัน รวมทั้งวิธีการวัดการทำงานแล้ว

ต่อไปคือ จะแก้ไข หรือ ปรับปรุงขั้นตอนการทำงานอย่างไรดีล่ะ ?

• ทุกทีมทำงานบน main branch ไปเลยดีไหม ?
• สร้างที่เก็บ dependency library ตรงกลางดีไหม ? เมื่อมีการเปลี่ยนแปลงก็มีเก็บที่นี่แทน ใคร ๆ ก็ใช้ได้
• ลดการทดสอบแบบ manual ลงไปดีไหม ?

แต่ไม่ว่าจะวิธีการไหนก็ตาม สิ่งที่ต้องถามตัวเราเอง และ ทีมอยู่เสมอก็คือ วิธีการเหล่านั้น มันส่งผลกระทบต่อ Time to Main อย่างไรบ้าง ? ถ้ามันช่วยลดเวลาลง ก็ให้ลงมือทำในกรอบเวลาสั้น ๆ จากนั้นทำการวัดผลว่ามันช่วยปรับปรุงจริงไหม ? ยิ่งค่า Time to Main น้อยมากเท่าไร ก็ยิ่งดีใช่ไหมล่ะ

ดังนั้น Time to Main มันน่าจะเป็นอีกตัวชี้วัดหนึ่ง

ที่ช่วยให้เราเห็นว่า การทำงานของเรามีข้อจำกัด หรือ ปัญหาอะไรบ้าง ที่จะขัดขวางให้เราส่งมอบงานได้ล่าช้า ยิ่งแต่ละทีม หรือ แต่ละคนใช้เวลาบน branch ของตัวเองนาน ก็ยิ่งส่งผลต่อ Time to Main มากขึ้น ปัญหาที่ตามมาก็เยอะเช่นกัน !! ดังนั้นมาปรับปรุงกันเถอะครับ

คำถามสำหรับทีมที่นำเอา Continuous Integration มาใช้งาน เวลาของ Time to Main เป็นเท่าไรกันบ้าง ?