Trunk Based Development

จริงๆ แล้วเรื่องนี้เป็นส่วนหนึ่งของ Continuous Integration ที่เคยเขียนถึงไปแล้ว แต่วันนี้จะลงรายละเอียดไปอีกหน่อย

การจะทำ CI ให้ประสบความสำเร็จนั้น ทีมพัฒนาจำเป็นจะต้องมีวินัยด้วย ไม่ใช่ว่าแค่ตั้ง CI server, Jenkins(Hudson) หรือ CruiseControl ขึ้นมาแล้วจะบอกว่าตัวเองทำ CI แล้ว ระเบียบวินัยที่ว่านี้มีหลายด้าน วันนี้จะมาว่าด้วยเรื่องของ source code version control ครับ

Trunk Based Development คือ อะไร?

มันคือ สไตล์การจัดการ source code version control ที่เอื้อให้เกิดการรวม code ตั้งแต่ช่วงเริ่มต้น และตลอดการพัฒนา โดยวิธีการคือ นักพัฒนาทุกคน ไม่ว่าจะทีมใหญ่แค่ไหน อยู่ที่เดียวกัน หรืออยู่ต่างจังหวัด ต่างประเทศกันก็ตาม ทุกคนต้อง commit code เข้าที่ branch เดียวเสมอๆ (และบ่อยๆ)

ได้ยินแบบนี้หลายท่านอาจจะรู้สึกขัดใจ เพราะตามที่เราเข้าใจกันมา ทีมระดับเทพ และโปรเจ็คที่มีความใหญ่ประมาณหนึ่งขึ้นไปควรจะมีการจัดการ branch ที่ดี อาจจะแบ่งตามเวอร์ชั่น แบ่งตามฟีเจอร์ แบ่งตามนักพัฒนาก็ว่ากันไป มีโปรเซสในการรวม code ที่ดี และการตรวจสอบเทสบั๊ก จากการรวม code เข้ามาตรวจจับและวิเคราะห์หาบั๊กและปัญหาต่างๆ และแก้ได้ถูก branch เป็นการจำกัดขอบเขตความเสียหาย และหาจุดบกพร่องได้ง่ายขึ้น

“ไอ่ที่มี SVN branch เดียว ทุกคน commit ไปรวมกันหมด ชิบหายมานักต่อนักแล้ว มันเอาไว้ให้โปรเจ็คเล็กๆ ง่ายๆ พัฒนาคนเดียว หรือไม่่กี่คนเค้าใช้กัน”

ข้างบนนี้คือ ความคิดแวบแรกของผมที่ได้ยินคอนเซปนี้เลยครับ แต่พอได้รู้ถึงเหตุผล และผลเสียของการแตก branch ผมก็เริ่มเข้าใจมากขึ้น

• ลองคิดถึงเวลาต้อง merge code ที่ไม่ได้ merge กันมาเป็นเวลานาน มันยากขนาดไหน ต้องใช้เวลานานขนาดไหน ส่วนตัวผมเคยถึงขั้น ไม่สามารถ merge กันได้ ต้องแยกกันไปเลยก็มี
• เคยมั้ยที่คุณไม่กล้าแก้ refactor code ให้ดีขึ้นเพราะกลัวจะ merge กับเพื่อนแล้วมีปัญหา
• เคยมั้ยที่เรากำลังจะทำงานๆ หนึ่ง แล้วมันต้องใช้ code ที่เพื่อนร่วมทีมของคุณทำไปแล้ว แต่ไม่ได้ merge เข้ามา หรือยัง merge เข้ามาไม่ได้
• ฯลฯ

ปัญหาเหล่านี้หละครับ เป็นส่วนหนึ่งที่ทำให้เกิดความล่าช้า และความซับซ้อนในการพัฒนาโดยไม่จำเป็น

ตามคำกล่าวที่ว่า “if it hurts, do it more often” ถ้ามันยากนักก็ทำมันบ่อยๆ ซะ มันก็จะง่ายขึึ้นเอง ถ้าการ merge code ทำให้ชีวิตเราลำบาก ทำไมเราไม่ merge มันบ่อยๆ หละ

อยากให้ลองกันดูครับ ไม่ยากอะไร แค่ กำหนดให้นักพัฒนาทุกคนที่พัฒนาบน source code ชุดเดียวกัน อย่างน้อยคนละครั้งต่อวัน แล้วสิ่งดีๆ จะตามมา

ถ้าบริษัทที่มีนักพัฒนาเยอะระดับ Google เค้าทำได้ เราก็ต้องทำได้ครับ

 

FAQ

แล้ว ถ้า code คนอื่นมาทำทั้งโปรเจ็คพังไปหมดจะทำไงหละ?

– การป้องกันการพังด้วยการ ไม่เอา code มารวมกัน มันเป็นการแก้ปัญหาที่ไม่ตรงจุดนะครับ กรณีนี้ผมก็คงต้องแนะนำให้นักพัฒนาทุกคน มีความรับผิดชอบต่อ code ตัวเอง(อีกวินัยหนึ่งที่จำเป็นต่อ CI) ด้วยการเขียน test อย่างครอบคลุมครับ

แล้วถ้า feature ที่ทำอยู่มันทำงานร่วมกับ feature ปัจจุบันไม่ได้เลยหละ จะทำยังไง?

– เรื่องนี้ผมรู้ว่ามี 2 เทคนิคที่เอามาช่วยแก้ปัญหานี้ได้ครับ อันนึงคือ Feature toggle (Feature bit) อีกอันนึงคือ Branch by abstraction ถ้ามีโอกาส (และความอยาก) จะมาเล่า 2 เรื่องนี้ให้ฟังครับ

อย่างงี้ DVCS เท่ๆ ของเราทั้ง Git ทั้ง Mecurial ก็หมดความหมายไปเลยสิ?

– จริงๆ แล้วประเด็นของวิธีนี้ ไม่ได้กำหนดว่าห้ามสร้าง branch ครับ แต่ต้องมีวินัยนำกลับมา trunk เร็วที่สุด ตัว DVCS ยังให้ประโยชน์แก่เราในกรณีอื่นๆ อีกมากมาย ไม่ใช่แค่สร้าง branch ได้ cheap เพียงอย่างเดียวครับ DVCS ของเรายังเท่อยู่ครับ