วันนี้มีโอกาสไปแบ่งปันเรื่อง Branching Strategy
ในงาน Thailand Agile Coaching Meetup 2/2559 ตอน Game Game และ Game
ซึ่งจัดที่บริษัท THiNKNET
โดยเนื้อหาเป็นแนวคิดสำหรับ
การจัดการความเสี่ยงอย่างหนึ่งในนั้นคือ เรื่อง Branching
แต่สิ่งที่ไม่เคยคิดกันต่อก็คือการ Merging
มีรายละเอียดคร่าว ๆ ดังต่อไปนี้
เริ่มต้นด้วยปัญหาที่ได้รับจาก Cargo Cult
หนึ่งวิธีในการแก้ไขก็คือ
การทำ branching ของ source code ใน Version Control System
คำถามคือ แล้วเราจะทำการ branching แบบไหนล่ะ ?
คำตอบของหลาย ๆ คนก็คือ
ทำตามบริษัทใหญ่ ๆ สิ หรือบริษัทที่มันแจ่ม ๆ
ยกตัวอย่างเช่น บางคนบอกว่าทำตาม Google สิ
แสดงดังรูป
แต่คนส่วนใหญ่กลับไม่อ่านข้อนี้ !!
คำถามต่อไปคือ
แนวทางเหล่านี้มันเหมาะสมกับระบบงานของเราหรือไม่ ?
แนวทางเหล่านี้มันเหมาะสมกับทีมของเราหรือไม่ ?
แนวทางเหล่านี้ได้รับการสนับสนุนจากฝ่าย management หรือไม่ ?
ถ้าได้รับคำตอบที่ดี ก็น่าจะทำให้ผลออกมามันดี
แต่ส่วนใหญ่จะได้ผลตรงกันข้าม !!
มาดูกันหน่อยว่ารูปแบบของการ Branching มีอะไรบ้าง ?
- Integration branch หรือ Main/Trunk/Master
- Release branch
- Feature/task branch
- Shelving branch
- Fork and pull request
- No branch (feature toggle)
โดยสรุปแล้วรูปแบบของการ braching ที่ได้พูดมี 3 แบบ
ประกอบไปด้วย
- No branching
- Branching by feature
- Branching by release
จะเลือกวิธีการไหน ต้องตอบให้ได้ว่า
วิธีการที่ทำอยู่นั้นเป็นอย่างไร ?
ปัญหาในปัจจุบันคืออะไร ?
ปัจจุบันนโยบายของบริษัทเป็นอย่างไร ? (องค์กรเป็นแบบไหน branching ก็เป็นแบบนั้น)
คำตอบจากคำถามเหล่านี้
จะนำไปสู่แนวทางการแก้ไขต่อไป
ส่วนการนำไปใช้งานจริง ๆ นั้น
อาจจะนำแนวคิดต่าง ๆ มาใช้งานร่วมกัน (Hybrid approach)
และสุดท้ายก็นำเครื่องมือต่าง ๆ มาช่วยเหลือ
เพื่อลด overhead ต่าง ๆ ลงไป
ดังนั้นให้เข้าใจความต้องการของตัวเอง
หรือทำความเข้าใจกับปัญหาที่พบก่อนนะครับ
ข้อคิดสะกิดใจ
ถ้าทำไปแล้วรู้สึกว่ามันลำบาก หรือ มีปัญหามากกว่าเดิม
แสดงว่า สิ่งที่ทำอยู่ไม่น่าจะถูกต้อง หรือ เหมาะสมนะ
ต้องทำการแก้ไข และ ปรับเปลี่ยนต่อไปอย่างต่อเนื่อง
และวันนี้คุณทำการ commit, push และ merge code แล้วหรือยัง ?
และทำบ่อยหรือไม่ อย่างไร ?
โดย slide อยู่ที่นี่
