Git branching strategies vs trunk base development ตอนที่ 1
กลยุทธ์การแตก branch
วันก่อนขณะที่ผมกำลังเล่าเรื่อง A successful git branching model ผมก็ไปเจอบทความ Git Branching Strategies vs. Trunk-Based Development อ่านแล้วชอบ เลยอยากเอามาแปลตามความเข้าใจของผมให้ทุกคนฟัง
branching strategy คืออะไร?
branching strategy ก็คือกลยุทธ์ในการแตก branch ที่ทีมพัฒนาใช้เวลาเขียน, merge และส่งมอบโค้ดใน version control system เช่น Git เป็นต้น
บทความนี้จะแสดงให้เห็นข้อดีข้อเสียของกลยุทธ์แบบต่าง ๆ สุดท้ายเราจะเปรียบเทียบให้ดูว่า trunk-based development มันแก้ข้อเสียของกลยุทธ์แบบต่าง ๆ และสนับสนุน engineering practice ที่จะส่งมอบซอฟต์แวร์อย่างสม่ำเสมอผ่านเทคนิค feature flag ได้ยังไง
เมื่อไหร่ที่เราจำเป็นต้องใช้กลยุทธ์ในการแตก branch?
กลยุทธ์ในการแตก branch ช่วยให้ทุกคนในทีมพัฒนาแก้ของใน source control ไปในทิศทางเดียวกัน กลยุทธ์ที่เหมาะสมจะส่งเสริมทั้งความร่วมมือ, ประสิทธ์ภาพในการทำงาน และ ความแม่นยำในการส่งมอบซอฟต์แวร์
ในทางกลับกัน การเลือกกลยุทธ์ผิดหรือไม่มีกลยุทธ์ (มั่วซั่ว) ทำให้เสียเวลาได้เป็นชั่วโมง ๆ
ต่อไปนี้จะเป็น usecase ต่าง ๆ ที่ใช้ในการเลือกกลยุทธ์
workflow ในการพัฒนาตามปรกติ
ในการทำงานปรกติ developer ก็จะแก้โค้ดไปตามธรรมดา โค้ดที่แก้ไปเหล่านี้ไม่ได้เร่งด่วนอะไร ปริมาณโค้ดที่เปลี่ยนก็ขนาดไม่เล็กไม่ใหญ่ และไม่ได้มีความซับซ้อนมากมายนัก และการ integrate ก็มักจะกอง ๆ หลาย ๆ commit แล้วค่อย integrate ทีนึง และเพราะ flow การพัฒนาตามปรกตินี้จะถูกใช้บ่อยที่สุด กลยุทธ์ที่จะใช้ในกรณีนี้ต้องสนับสนุนการทำงานร่วมกันของ developer หลาย ๆ คน และรองรับ policy ต่าง ๆ ที่ทีมมีเช่น automate unit tests, pull request และการ deploy
ดับไฟบน production
กลยุทธ์ที่เราเลือกต้องรองรับให้ developer สามารถดับไฟบน production (ซึ่งส่วนใหญ่หมายถึงการแก้บั๊ก) ได้อย่างรวดเร็ว โดยยัง align กับ process การทำงานปรกติอยู่
การเปลี่ยนแปลงทั้งเล็กและใหญ่
ขณะที่ทิศทางที่อุตสาหกรรมกำลังเน้นไปทางให้ developer เปลี่ยนโค้ดทีละเล็ก ๆ และเน้น continuous delivery แต่มันก็จะมีวันที่เราต้องแก้ของใหญ่ ๆ เช่นปรับโครงสร้างระบบ กลยุทธ์ที่เราเลือกมาต้องรองรับการแก้ไขแบบนี้ด้วย
การทดลอง
นอกจากรองรับการเปลี่ยนแปลงแบบปรกติแล้ว บางทีเราก็ต้องลองอะไรที่เรายังไม่มั่นใจ เช่นลองดูว่า library ใหม่นี้เข้ากับระบบเราได้ดีแค่ไหน ซึ่งเราอาจจะอยากแบ่งปัน branch นี้กับเพื่อน ๆ ในทีม แต่ยังไม่มั่นใจจะเอาสิ่งนี้ไป deploy ใน production กลยุทธ์ที่เราเลือกมาต้องรองรับสถานการณ์นี้ด้วย
สัปดาห์หน้าผมจะมาแปลเรื่อง Git branching ต่อนะครับ สัปดาห์นี้พอแค่นี้ก่อน ใครอดใจรอไม่ไหว ไปตามอ่านในต้นฉบับที่อ้างอิงด้านล่างเอานะครับ
