สรุปเรื่องของ 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