สรุปเรื่องของ Git Branching Strategy

วันนี้อ่านหนังสือเรื่อง Git for Teams มีเรื่องที่น่าสนใจอย่างยิ่ง หนึ่งในนั้นคือเรื่อง Git Branching Strategy ซึ่งมีหลากหลายวิธีให้เลือกนำมาใช้งานมาก ดังนั้น ในการพัฒนา software แต่ละองค์กร แต่ละทีม ต้องทำการเลือกและตัดสินใจว่า จะใช้วิธีการไหน ที่เหมาะสมกับงานของคุณ มาดูกันว่ามีวิธีการอะไรบ้าง ? มีคำพูดที่น่าสนใจ คือ

ค่าจ้างของ Developer นั้นแพงกว่า การทำ branching อย่างมาก แต่การเลือกวิธีการ branching ที่ผิด ยิ่งก่อให้เกิดค่าใช้จ่ายที่มากกว่ายิ่งนัก !!

ดังนั้นสิ่งที่ทีม ต้องคุย ต้องเลือก ก่อนที่จะเริ่มพัฒนา software คือ Branching Strategy ถ้าใช้งาน Git จะเรียกว่า Git Branching Strategy

ลองกลับไปดูสิว่า Release software process ของคุณเป็นอย่างไร ?

ก่อนอื่นมาดูว่า มีรูปแบบพื้นฐานอะไรกันบ้าง ? เพื่อนำไปใช้พิจารณาต่อไป

1. Mainline Branch Strategy

เป็นวิธีการที่เรียบง่ายที่สุด แถมยังมีประสิทธิภาพอย่างมากสำหรับทีมที่ไม่ใหญ่มาก เนื่องจากจะทำงานบน branch หลักเดียวเท่านั้น โดยที่ branch หลักนี้ ต้องพร้อมที่จะ deploy/release อยู่ตลอดเวลา ในการทำงานนั้น developer แต่ละคน จะทำงานบน local branch ของตัวเอง เมื่อทำการพัฒนาเสร็จแล้ว ให้ทำการ merge code เขาไปยัง branch หลัก แสดงดังรูป ข้อควรระวัง แต่ละงานที่ทำนั้น ควรเป็นงานที่เล็ก ๆ ไม่เช่นนั้น จะทำให้ local branch ยาวนานเกินไป ก็จะทำให้เกิด merge conflict กันเยอะ แต่ละงานที่มำนั้น ควรเป็น code ที่แยกออกจากกันชัดเจน ไม่เช่นนั้น ก็จะทำให้เกิด merge conflict กันเยอะ อีกอย่างหนึ่งที่ควรพึงระวัง ถ้าทำการ merge แบบ manual เยอะ ๆ แสดงว่า คุณกำลังมาผิดทาง เช่น

• Local branch ใช้เวลาพัฒนานานเกินไป
• ไม่ทำการ merge code บ่อย ๆ
• ไม่พูดคุยกัน

2. Feature Branch Strategy

ทำการจัดการ code แต่ละ branch แยกตาม feature ไป เมื่อ developer ทำการพัฒนา และ ทดสอบเสร็จแล้ว จะทำการ merge code จาก feature branch ไปยัง integration branch จากนั้นทำการทดสอบอีกครั้งบน integration branch เมื่อทุกอย่างเรียบร้อย ก็ทำการ merge กลับไปยัง branch หลักต่อไป แสดงดังรูป ดังนั้นสถานะของ code บน branch หลัก คือพร้อมที่จะ dpeloy/release อยู่ตลอดเวลา อีกอย่างหนึ่งที่เห็นได้ชัดเจนก็คือ มีการทำงานแบบ manual เยอะมาก ๆ ดังนั้น เราสามารถลดด้วยการทำระบบทำงานแบบอัตโนมัติเข้ามาช่วย ทั้งการ merge การทดสอบ และ การ deploy ระบบงาน ตัวอย่างที่นำวิธีการนี้ไปประยุกต์ใช้งาน เช่น Github flow กล่าวคือ เมื่อ developer แต่ละคนทำการพัฒนา feature เสร็จแล้ว จะไม่สามารถ merge code กลับไปยัง integration branch และ branch หลักได้ แต่จะต้องส่ง Pull Request ไปยัง integration branch ซึ่งการจัดการ Pull Request ส่วนใหญ่จะเป็นแบบ manual เนื่องจากต้องทำการ review และ ทดสอบ code เมื่อผ่านทั้งหมดแล้ว จะทำการ merge ไปยัง branch หลักต่อไป ข้อควรระวัง ยิ่ง feature branch มีอายุ หรือ การพัฒนาที่ยาวนานเพียงใด การดูแลรักษาก็ยากมากขึ้นไปเท่านั้น ชื่อของ feature branch ควรดูดี มีสาระ !! นั่นคือ ต้องมีชื่อตรงตามความต้องการของระบบ ไม่ใช่อยากจะตั้งชื่ออะไรก็ตั้ง แถมยังต้องมีการจัดการ branch ต่าง ๆ อยู่เป็นประจำ เช่นการลบ branch ต่าง ๆ ที่ทำการ merge ไปยัง branch หลักต่อไปซะ ไม่เช่นนั้น จะมี branch อยู่มากมายก่ายกอง ซึ่งยากต่อการจัดการเป็นอย่างมาก

แต่สิ่งที่สำคัญมาก ๆ คือ branch หลักยังต้องพร้อม deploy/release อยู่เสมอ มันคือหัวใจหลักเลย

3. Environment Branch Strategy

เป็นอีกรูปแบบหนึ่งของการจัดการ branch ซึ่งจะทำการสร้าง branch ขึ้นมาตามจำนวนของ environment ของระบบ เช่น

• Development
• Testing
• Staging
• Pre-production
• Production

ถ้าต้องการที่จะ deploy ไปยัง environment ไหน ก็ให้ทำการสร้าง merge request จาก branch หลักไปยัง branch นั้น ๆ ซะ ตัวอย่างเช่น

1. ในปัจจุบัน branch หลักทำการ deploy ไปยัง staging แล้ว
2. จากนั้นถ้าต้องการ deploy ไปยัง pre-production ก็ให้ทำการสร้าง merge request
3. ถ้าต้องการ deploy ไปยัง production ก็ให้สร้าง merge request จาก pre-production อีกที

โดยจากขั้นตอนการทำงานจะเป็นแบบทิศทางเดียวเท่านั้น เพื่อทำให้มั่นใจว่า ได้ทำการทดสอบบนทุก ๆ environment แสดงดังรูป

4. Released Branch Strategy

หรือจะเรียกว่า Branch by release นั่นเอง ในแต่ละ branch คือ แยกไปตามแต่ละ version ของระบบงาน แต่ส่วนการทำงานหลักยังคงอยู่ที่ branch หลักนะ แต่ปัญหาที่ตามมาก็คือ การดูแลจัดการในแต่ละ branch หรือ แต่ละ release ซึ่งก่อนอื่นต้องทำการแก้ไขและ merge มายัง branch หลักก่อนเสมอ จากนั้นจึงใช้ความสามารถของ git ชื่อว่า Cherry Pick เพื่อหยิบการแก้ไขไปยัง branch หรือ release ต่าง ๆ ต่อไป รวมทั้งถ้าทำการแก้ไขในแต่ละ branch หรือ release แล้ว ต้องทำการ Cherry Pick มายัง branch หลักเช่นกัน โดยนโยบาย หรือ วิธีการทำงานแบบนี้ เรียกว่า Upstream First แสดงดังรูป

สุดท้ายแล้ว ทีมลองคุยกันสิว่า วิธีการใดที่เหมาะสม ?

ลองพูดคุยกันในเรื่องของ ข้อดีและข้อเสีย ผมเชื่อว่า แต่ละงาน แต่ละ product ล้วนมีรูปแบบที่แตกต่างกัน ดังนั้น Branching Strategy ก็ย่อมแตกต่างกันไป อาจจะทำการเพิ่ม หรือ ลด กระบวนการลงไปอีกก็ได้ Reference Website https://www.javacodegeeks.com/2015/11/git-branching-strategies.html http://www.infoq.com/articles/no-hotfix-deployment http://www.kumaranuj.com/2015/11/gi-branching-strategies.html