ผมจะ focus ในเรื่องที่เกี่ยวกับ การ Approve code การ Run CI และการ Merge code

การ Approve code

การ review สามารถทำได้ทั้ง offline และ online เช่น

• review offline แบบ pair programming
• review offline แบบ mob programming
• review online ผ่านระบบ เช่น GitHub, GitLab

กฎเกณฑ์ในการ approve code มีหลายแบบที่สามารถเลือกใช้ได้ ไม่ว่าจะ review แบบ offline หรือ online เท่าที่ผมรู้จักมีประมาณนี้

1. No approval

ใครก็ได้สามารถ merge code ได้ทันที ไม่ต้องมีการ approve

ปกติจะใช้กับการขึ้น project ใหม่ในช่วงเริ่มต้น หรือทีมที่ยังไม่มี process ชัดเจน

บางครั้งถ้าคนทำ project มีประสบการณ์สูงอยู่แล้วก็ไม่จำเป็นต้องรีวิวได้เช่นกัน

process นี้จะเน้นความรวดเร็วในการ contribute

2. Anyone can approve

ในแบบนี้คือใครก็สามารถ approve code ได้ โดยปกติทีมจะตกลงกันว่าต้องมี approve กี่คนขั้นต่ำ เช่น 2 คน

เหมาะกับทีมที่มี engineer ระดับ senior ขึ้นไปจำนวนไม่เยอะ สามารถลดงานของ senior ได้

ปัญหาคือ engineer ระดับ junior รีวิวด้วยกัน อาจจะไม่เห็นปัญหายากๆ ที่ซ่อนอยู่

3. Senior can approve

ให้ engineer ระดับ senior ขึ้นไป approve เท่านั้น สามารถตกลงจำนวนคน approve ขั้นต่ำได้ด้วย เช่น 2 คน แต่ส่วนมากแล้วสามารถใช้ senior 1 คน approve ได้ทันที

เหมาะกับกรณี senior approve code ของ junior ตัว code จะมีมาตรฐานดีขึ้น ปัญหาน้อยลง และเกิดการ coaching junior ผ่าน code review

ข้อเสียคือ senior แต่ละคนอาจมี code style หรือมี vision เรื่อง code ไม่เหมือนกัน ทำให้ดูแล project ในระยะยาวได้ยากกว่า

4. Code owner can approve

assign owner ให้ในแต่ละ repo หรือละเอียดกว่านั้น เช่น ระดับ directory และกำหนดให้ code owner approve ได้เท่านั้น สามารถกำหนดจำนวนคน approve ขั้นต่ำได้ด้วย เช่น 2 คน แต่ส่วนมากแล้วสามารถใช้ code owner 1 คน approve ได้ทันที ทั้งนี้อาจจะให้ code owner เป็น engineer level senior ขึ้นไปก็ได้ หรือจะให้ junior เป็นก็ได้

เหมาะกับการดูแล code ในระยะยาวให้มี code style ที่ consistent สามารถดูแล technical debt ได้สะดวกกว่า

ข้อเสียคือต้อง manage code owner อยู่ตลอด และต้องทำ knowledge sharing ระหว่าง owner หาก repo นั้นมี owner หลายคน

การ run CI

เมื่อมีการ submit code เข้ามา ไม่ว่าจะเป็นแบบ offline (เรียกไป review) หรือ online (ผ่าน pull request/merge request) โดยปกติจะมีการ run automated test เกิดขึ้นด้วย จังหวะในการ run automated test มีหลายแบบ

โดยปกติ engineer จะต้อง run unit test ในเครื่องตัวเองให้ผ่านก่อนถึงจะ push code ขึ้นไปได้ บางครั้งอาจใช้ git hook เพื่อบังคับ run unit test ก่อน push code ได้อีกด้วย ป้องกันการลืม

1. full test@CI pipeline

เมื่อ engineer push code ขึ้นไปใน feature branch หรือ branch ชั่วคราวแล้ว ตัว CI จะ run full test เมื่อ run จบจะบันทึกผลลัพธ์เอาไว้

ระบบ CI จะต้องมี dependency ครบถ้วนก่อน run เช่น database, message queue เป็นต้น

2. quick test@CI pipeline

เมื่อ engineer push code ขึ้นไปใน feature branch หรือ branch ชั่วคราวแล้ว ตัว CI จะ run test เฉพาะ test ที่ทำงานเร็ว เช่น unit test เมื่อ run จบจะบันทึกผลลัพธ์เอาไว้

ระบบ CI ไม่จำเป็นต้องมี dependency ครบถ้วน ทำให้ง่ายต่อการจัดการและไม่เปลือง cost server

3. full test after merge

หลังจาก merge code เข้า branch หลักแล้ว CI จะ build และ deploy code เข้า environment สักตัวหนึ่ง อาจจะเป็น env ที่สร้างใหม่ หรือเป็น env หลักที่ engineer ใช้ทดสอบก็ได้ โดย CI จะ run full test และบันทึกผลลัพธ์เอาไว้ โดยปกติจะใช้งานคู่กับข้อ 2.

ข้อดีคือ dependency ต่างๆ จะเป็นชุดเดียวกัน (หรือใกล้เคียงกับ) env ที่ engineer ใช้ เมื่อเกิดปัญหาสามารถไป investigate ใน env ได้

การ merge code

หลังจาก code ได้รับการ approve แล้ว มีหลายวิธีที่จะ merge code เข้าไป branch หลักได้ดังนี้

1. feature owner merge ด้วยตัวเอง

หลังจาก code approve แล้ว ผู้ที่เป็นเจ้าของ code ใหม่จะเป็นคนกด merge ด้วยตัวเอง

ข้อดีคือ feature owner กำหนดเวลาในการ merge ได้ เช่นพร้อมทดสอบหรือ release ตอนไหนก็ merge ได้เลย

2. approver merge ด้วยตัวเอง

เมื่อ code approve แล้ว ผู้ที่ approve จะเป็นคนรับผิดชอบในการ merge ให้

ข้อดีคือ approver มักจะเป็น senior หรือผู้ที่รู้ code เป็นอย่างดี สามารถ manage sequence ในการ merge หรือ sequence ในการ release ได้ ลดการ coordinate และป้องกันปัญหาต่างๆ เช่น compatibility

3. code owner merge ให้

เมื่อ code approve แล้ว owner ของ repo หรือ folder จะเป็นผู้ merge ให้

มีข้อดีแบบเดียวกับข้อ 2 และยังได้ความปลอดภัยเพิ่มขึ้น เพราะไม่จำเป็นต้อง grant สิทธิการ merge ให้กับผู้อื่น

สรุป

เราสามารถเลือกใช้วิธีต่างๆ ประยุกต์ หรือผสมเข้าด้วยกันได้ เพื่อให้เหมาะกับ process ขนาดทีม และ policy ขององค์กรได้

#git #team