ปัญหาหลักที่มักเจอเกี่ยวกับการจัดการ source code
ด้วย VCS (Version Control System) เช่น Git คือ
เราจะเลือก branch strategy แบบไหนดี ?
ยกตัวอย่างเช่น
- TBD (Trunk-Based Development)
- Integration branch (Master และ Develop)
- Feature branch/ Git flow
- Pull Request
จากสิ่งที่พบเจอมานั้น มีสิ่งที่น่าสนใจคือ
TBD ไม่เหมาะกันงานของเรา
Integration branch ดีเลยนะ แต่งานของเราขึ้นไม่พร้อมกัน
Feature branch/ Git flow มันใช่เลย
แต่ ไป ๆ มา ๆ จำนวน branch เยอะมาก
แต่ ไป ๆ มา ๆ แต่ละ branch มีอายุที่ยามนานมาก ๆ กว่าจะ merge ไปยัง branch หลัก
Pull request ก็มีปัญหาเยอะ ในการ review อีกทั้ง code แย่และไม่ถูกต้อง
ประเด็นคือ ทำไมแต่ละแนวทางมีแต่ปัญหานะ ?
ทั้งที่เราทำงานเป็นรอบสั้น ๆ นะ
ทั้งที่เราทำงานแบบ feature-based นะ
แต่เมื่อเราลงไปดูในรายละเอียด
ของแต่ละ branch แต่ละ feature พบสิ่งที่สะเทือนใจมาก ๆ คือ
จำนวน commit เยอะมาก ๆ บางทีมบอกว่า
แต่ละ commit มันคือแต่ละ task เลยนะ
จำนวน commit มันบอกให้เรารู้ว่า
มี task ที่ต้องทำเยอะมากมาย
เมื่องานเยอะเกินไป ปัญหาจึงตามมา
นั่นคือ
ทำการ merge code กับ branch หลักก็ยาก conflict เพียบ
ทดสอบก็ยาก
การ deploy แต่ละครั้งจึงเจ็บปวดรวดร้าว
ดังนั้นสิ่งที่ควรทำเป็นอันดับแรกเลย
คือการกำหนดจำนวนและขนาดของงานที่ทำก่อนเลย
ยกตัวอย่างเช่น
ทำทีละงาน
กำหนดเวลาหรืออายุของ feature branch ที่สร้าวขึ้นมา
เมื่อสิ้นสุดเวลาที่กำหนด หรือ งานที่ทำเสร็จแล้ว
ให้ทำการ merge, test และ deploy กันเลย
ที่สำคัญคือ ลบ branch เมื่อทุกอย่างมีสำเร็จ
โดยวิธีการนี้
มันช่วยทำให้เราเห็นว่า
สิ่งที่เราทำนั้นเป็นอย่างไร
การทำงานของเราเป็นอย่างไร
เพื่อปรับปรุงและแก้ไขต่อไป
ที่สำคัญจะทำให้เราเห็นว่า
feature หรือ story ที่พัฒนานั้น ควรมีขนาดเล็กเท่าไรดี
และไม่มี branch ที่มีอายุนาน ๆ อีกต่อไป
สุดท้ายแล้วการ Pull Request ก็จะง่ายขึ้น
ถ้า feature นั้นมันเล็ก
กำหนดจำนวนและขนาดของแต่ละ task ที่ทำ
คือ การแก้ไขปัญหาที่ต้นเหตุ
ไม่ใช่ไปแก้ไขที่ปลายเหตุ เช่น ถ้า code มัน conflict กันมีเครื่องมืออะไรช่วยไหม !! เป็นต้น
คำถามคือ วันนี้คุณมีปัญหาเรื่องนี้อยู่หรือไม่ ?
ถ้ามี คำถามคือ คุณแก้ไขที่ต้นเหตุหรือปลายเหตุกันแน่ ?
