Trunk Based Development คือ ?

ความจริงเรื่องของ TBD ไปอ่านละเอียดได้ที่ https://trunkbaseddevelopment.com/

แต่ถ้าจะลองสรุปตามความเข้าใจง่ายๆก็จะประมาณว่า มันคือวิธีที่ทีมใช้ branch เดียวในการ develop ไม่ว่าจะมีกี่ feature ก็ตามก็จะ push-pull ไปที่ branch เดียวเสมอ ในกรณีที่มี feature ไม่ได้มากนัก
ในกรณีที่มี feature เริ่มเยอะ อาจจะมีความเป็นไปได้ว่าจะมีการแตก branch ออกไปได้ แต่ก็จะทำในช่วงเวลาสั้นๆ (สั้นมากๆ) และรีบ merge กลับไปที่ branch หลัก(อาจจะทำคนเดียว และทำแค่ 1-2วัน)

นี่คือคำอธิบายสั้นๆสำหรับการทำ Trunk Based Development

ข้อดีของการทำ TBD มีหลายสิ่ง หลักๆก็คือการเลี่ยง merge hell

สิ่งที่จะตามมาจากเรื่องนี้ก็จะมีอีกหลายสิ่ง เช่น Feature Toggle เนื่องจากเราทำงานกันบน single branch การจะ release feature ใดๆ ก็ควรจะมี trigger ซึ่งต่างจาก feature branch ที่เราแตก branch ตาม feature และอาจจะทำ PR เข้ามา branch หลักเพื่อ release แต่สุดท้ายก็อาจจะหนีการทำ toggle ไม่ได้อยู่ดี

การทำงานบน branch เดียว จะเหมือนถูกบังคับให้มี feature toggle ไปโดยปริยาย ซึ่งข้อดีคือ เราจะรู้ตัวตั้งแต่แรก ว่าเรามี toggle และเราจะเทสมันอยู่เรื่อยๆด้วยซ้ำ ซึ่งข้อนี้มีข้อเปรียบเทียบเล็กน้อยระหว่าง การมาเพิ่ม toggle เมื่อยามฉุกเฉิน เช่น ทีมทีทำ feature branch มาโดยตลอด มาวันหนึ่ง merge ของทุกอย่างพร้อม release แต่ดันมีบาง feature ต้องปิดไว้ก่อน
ทีมอาจจะเลือกทำ cherry-pick เฉพาะการ toggle เข้าไป ซึ่งเป็นของใหม่ และอาจจะยังเทสไม่ครบถ้วนเข้าไป แบบนี้จะมีความเสี่ยงมากกว่าการมี toggle ตั้งแต่แรก

อีกเรื่องหนึ่งที่จะตามมาคือ คำถามและข้อโต้แย้งจากคนที่ทั้งชีวิตเคยทำแต่ feature driven แบบ branching มาโดยตลอด และพอเจอทีมที่จะผลักดัน TBD พวกนี้ก็จะพยายามดันกลับไปทำ branching ให้ได้ เพราะความไม่เข้าใจ และไม่คุ้นเคย คนพวกนี้เวลาเราเล่า TBD ให้ฟัง ก็จะทำหน้ามุ่ย แล้วก็บอกแต่ว่า เราทำไม่ถูก ของที่ถูกมันต้องแตก branch แล้ว PR สิ อันนี้บอกตรงๆ เหนื่อย!!! วิธีมันมีตั้งเยอะแยก ไม่ใช่ว่าเคยทำมาแบบเดียว แล้วมันจะมีแค่แบบเดียวซะที่ไหนน้อ

แย่กว่านั้นคือ บางบริษัทมีทีม DevOps ที่คอยกำกับการ deploy และมี framework ไว้ให้แล้ว พวกนี้ก็คุยยากเหมือนกัน เพราะการที่เรานำเสนอแนวทางอื่น เขาจะมองว่าเราไปแหกกฎเหล็กของเขา ซึ่งเป็นความผิดร้ายแรง ต้องเอาไปแก้ให้ตรงกับของที่เขาทำไว้สิ แบบนี้ยิ่งเหนื่อยกว่า

ส่วนตัวผมเคยทำงานกับทีมที่ใช้ Single Branch ยังไม่ถึง TBD แต่ก็เกือบๆละ ซึ่งทีมนี้ก็มี release ทุกๆครึ่งเดือน และทำ feature toggle มาตั้งแต่แรก 7-8 ปีมาแล้ว ก็น่าจะยังทำแบบนี้อยู่(เพราะออกมาแล้วเลยไม่รู้) ผมว่าปัญหามันก็มีบ้าง ก็ต้องแลกกับ feature branch แหล่ะเอาจริง แต่ถ้าให้เลือกเจ็บ ผมยืนยันเหมือน SM ของผมคือ จั๊ว Odd-e ว่า ผมยอมเจ็บแบบใช้ feature toggle ดีกว่าเช่นกัน

เพราะแค่ merge code ธรรมดาแล้วเจอ conflict บางรอบก็เล่นเอาเหงื่อตกกันแล้ว แล้วถ้าไป merge ทั้ง branch ทิ้งเวลาห่างกันเป็นสัปดาห์ ผมคิดว่า สวดพานยักษ์ก็ยังไม่สบายใจถ้าจะให้ผมลอง merge ดู

เพราะอย่างน้อยในหนังสือ ProGit ก็บอกตั้งแต่บทแรกๆว่า วิธีใช้ Git ที่ดีคือ merge ให้บ่อยที่สุด ผมก็เลยจะติดนิสัย git commit ถี่มากๆ และ push/pull บ่อยมากๆ ซึ่งมันก็ตรงกับการทำ TBD ตรงนี้พอดี ที่เราทำงานบน branch เดียวเสมอ ไม่ทิ้งระยะการ merge ให้นานไป เพราะการคุยกันของ developer เราคุยกันผ่าน code เพราะฉะนั้น ยิ่งคุยกันบ่อยยิ่งดีนะครับ

และถ้าไปจนสุดเลย การทำ TBD อาจส่งผลไปถึงการจัดทีมทำงานกันเลยทีเดียว