อัปปรูฟ / แอปปรูฟ: คืออะไร, approval และ code review ใน Git

อัปปรูฟ pull request คืออะไร

อัปปรูฟ (approval) คือการรีวิวเชิงบวกสำหรับ pull request ซึ่งหมายความว่าผู้รีวิวตรวจสอบโค้ดแล้ว ไม่พบปัญหาวิกฤต และเห็นว่าการเปลี่ยนแปลงพร้อมสำหรับการผสาน ในอินเทอร์เฟซของ GitHub นี่คือปุ่มสีเขียว "Approve" บนหน้า PR หลังจากการอัปปรูฟ ผู้เขียน (หรือสมาชิกคนใดก็ตามที่มีสิทธิ์เขียน) สามารถทำ merge ได้

กระบวนการอัปปรูฟเป็นส่วนหนึ่งของ Branch Protection Rules เจ้าของ repository กำหนดข้อกำหนดที่บังคับ: จำนวนการอัปปรูฟขั้นต่ำ (เช่น 1 หรือ 2), ใครบ้างที่อัปปรูฟได้ (เจ้าของโค้ด, สมาชิกทีม), และ PR ต้องถูกอัปปรูฟซ้ำหลังการแก้ไขหรือไม่ (Dismiss stale reviews) หากไม่ตั้งค่ากฎ การอัปปรูฟเป็นเพียงขั้นตอนทางเลือก แต่ในทีมมืออาชีพแล้วถือเป็นสิ่งจำเป็น

GitLab ใช้กลไกที่คล้ายกันชื่อ Approval Rules ใน GitLab คุณสามารถตั้งค่าได้ว่าต้องการการอัปปรูฟกี่ครั้งจากกลุ่มต่าง ๆ (เช่น 2 ครั้งจากนักพัฒนา backend และ 1 ครั้งจาก DevOps) หลังจากได้รับการอัปปรูฟที่บังคับครบทั้งหมด PR จะถูกปลดล็อกโดยอัตโนมัติสำหรับการ merge โดยมีเงื่อนไขว่า pipeline CI/CD เป็นสีเขียว

ประเภทการรีวิว: Approve, Request Changes, Comment

ใน GitHub และ GitLab มี การรีวิวสามประเภท ที่ผู้รีวิวสามารถฝากไว้บน pull request ได้ แต่ละประเภทมีสถานะและผลกระทบต่อกระบวนการผสานที่แตกต่างกัน Approve เป็นสีเขียว, Request Changes เป็นสีแดง, Comment เป็นสีเทากลาง ๆ การเลือกประเภทขึ้นอยู่กับคุณภาพของโค้ดและความพร้อมของการเปลี่ยนแปลงที่จะถูกนำเข้า

Approve — ผู้รีวิวยืนยันว่า: โค้ดเขียนอย่างถูกต้อง ตรงตามมาตรฐาน ไม่มีข้อผิดพลาดที่ชัดเจน และสามารถถูกผสานได้ Approve ไม่ได้หมายความว่าโค้ดสมบูรณ์แบบ — เพียงแต่ว่ามันดีพอสำหรับ production หากมีข้อสังเกตเล็กน้อย (สไตล์, การตั้งชื่อ) ก็สามารถฝากเป็นความคิดเห็นได้โดยไม่บล็อก PR

Request Changes — ผู้รีวิวพบปัญหาที่ต้องแก้ไขก่อนการ merge: ข้อผิดพลาดเชิงตรรกะ, ช่องโหว่, การละเมิดสถาปัตยกรรม, การไม่มีเทสต์ หลังจาก Request Changes PR จะถูกบล็อก และเพื่อปลดล็อกจำเป็นต้องมีการอัปปรูฟซ้ำจากผู้รีวิวคนเดิม (หากเปิดตัวเลือก Dismiss stale reviews เมื่อมีคอมมิตใหม่)

• Approve — โค้ดพร้อมสำหรับการผสาน, สามารถ merge ได้หลังผ่าน CI
• Request Changes — การแก้ไขที่จำเป็น, PR ถูกบล็อกจนกว่าจะมีการรีวิวซ้ำ
• Comment — ข้อสังเกตหรือข้อเสนอทั่วไปโดยไม่บล็อก PR

การตั้งค่ากฎการอัปปรูฟใน repository

Branch Protection Rules คือกลไกของ GitHub สำหรับควบคุมคุณภาพของการผสาน ตั้งค่าได้ที่ Settings → Branches สำหรับแต่ละสาขาที่ได้รับการป้องกัน (main, develop, release/*) พารามิเตอร์หลัก: จำนวนการอัปปรูฟที่บังคับ, เจ้าของโค้ด (CODEOWNERS), การตรวจสอบ CI/CD ที่บังคับ, และการห้าม push โดยไม่มี PR

พารามิเตอร์ Dismiss stale pull request approvals — จะยกเลิกการอัปปรูฟโดยอัตโนมัติหากมีการเพิ่มคอมมิตใหม่ลงใน PR ซึ่งรับประกันว่าผู้รีวิวจะอนุมัติเวอร์ชันของโค้ดที่จะถูกผสานจริง ๆ หากไม่มีการตั้งค่านี้ ผู้เขียนอาจเพิ่มโค้ดใหม่หลังการอัปปรูฟ และมันจะเข้าไปใน main โดยไม่มีการตรวจสอบซ้ำ

CODEOWNERS — ไฟล์ที่รากของ repository ซึ่งกำหนดผู้รับผิดชอบสำหรับแต่ละไดเรกทอรี หาก PR แตะต้องไฟล์ที่เป็นของเจ้าของโค้ด การอัปปรูฟของเขาจะกลายเป็นสิ่งจำเป็น CODEOWNERS ช่วยกระจายขอบเขตความรับผิดชอบ: นักพัฒนา iOS รับผิดชอบไฟล์ Swift, DevOps — คอนฟิก Docker, ผู้ทดสอบ — สถานการณ์การทดสอบ

# ตัวอย่างไฟล์ CODEOWNERS ในรากของ repository

# นักพัฒนา iOS เป็นเจ้าของโค้ด Swift
*.swift @team/ios-developers

# DevOps เป็นเจ้าของคอนฟิก CI/CD
.github/workflows/* @devops-team

# วิศวกร QA ตรวจสอบเทสต์
**/tests/* @qa-engineers

# เจ้าของเริ่มต้นสำหรับสิ่งอื่นทั้งหมด
* @tech-leads

Code review ก่อนอัปปรูฟ: ควรตรวจสอบอะไร

Code review ก่อนการอัปปรูฟคือการตรวจสอบโค้ดอย่างเป็นระบบ ไม่ใช่การกวาดดู diff แบบผ่าน ๆ การ code review ที่มีคุณภาพรวมถึงการตรวจสอบสถาปัตยกรรม, ตรรกะ, สไตล์, เทสต์ และความปลอดภัย หากไม่มีการตรวจสอบนี้ การอัปปรูฟก็กลายเป็นเพียงพิธีการ ไม่ใช่เครื่องมือควบคุมคุณภาพ

สิ่งที่ตรวจสอบก่อนอื่น: ตรรกะของการเปลี่ยนแปลง — โค้ดแก้ปัญหาที่ได้รับมอบหมายได้หรือไม่, มีผลข้างเคียงหรือไม่, การจัดการกรณีขอบถูกต้องหรือไม่ เทสต์ — เทสต์ใหม่ครอบคลุมทุกสถานการณ์หรือไม่, เทสต์เดิมยังผ่านหลังการเปลี่ยนแปลงหรือไม่ ความปลอดภัย — มี SQL injection, XSS, การรั่วไหลของข้อมูลที่ละเอียดอ่อนหรือไม่

สิ่งที่ไม่ควรเป็นประเด็นของการรีวิว: สไตล์การจัดรูปแบบ (สำหรับสิ่งนี้มี linter และ formatter), การตัดสินใจเชิงสถาปัตยกรรม ที่ตกลงกันไว้ล่วงหน้า (มีการหารือก่อนการเขียนโค้ด) หากรีวิวมีมากกว่า 400 บรรทัดหรือใช้เวลานานกว่าหนึ่งชั่วโมง — นั่นคือสัญญาณว่างานใหญ่เกินไปและต้องแบ่งย่อย แนวปฏิบัติที่ดีที่สุดในการรีวิว — ทีละ 200-400 บรรทัดภายใน 24 ชั่วโมงหลังสร้าง PR

• ตรรกะ — ความถูกต้องของการแก้ปัญหา, การจัดการข้อผิดพลาด, กรณีขอบ
• เทสต์ — ความครอบคลุมของสถานการณ์ใหม่, การผ่านของเทสต์เดิม, การไม่มีเทสต์ flaky
• ความปลอดภัย — ไม่มี injection, การ escape เอาต์พุต, การเข้าถึงข้อมูล
• ประสิทธิภาพ — ประสิทธิภาพของอัลกอริทึม, คิวรีที่ซ้ำซ้อน, การรั่วไหลของหน่วยความจำ
• เอกสารประกอบ — เอกสารได้รับการอัปเดตหรือไม่, ความคิดเห็นในส่วนที่ซับซ้อนเข้าใจง่ายหรือไม่

Workflow ที่มีการอัปปรูฟในทีม

workflow ทั่วไปที่มีการอัปปรูฟในทีมนักพัฒนา 5-10 คนมีหน้าตาแบบนี้: นักพัฒนาสร้าง PR, กำหนดผู้รีวิว (โดยปกติ 1-2 คนจากทีมหรือเจ้าของโค้ด), CI/CD เริ่มการตรวจสอบอัตโนมัติ หลังจากได้รับการอัปปรูฟที่บังคับครบทั้งหมดและ CI เป็นสีเขียว ผู้เขียนก็ทำ merge เวลาจากการสร้าง PR จนถึง merge โดยเฉลี่ยอยู่ที่ 2 ชั่วโมงถึง 2 วัน ขึ้นอยู่กับความซับซ้อน

GitHub Actions อนุญาตให้ ทำให้ merge เป็นอัตโนมัติ หลังการอัปปรูฟ หากตั้งค่ากฎของสาขาไว้ GitHub จะบล็อกการ merge เองจนกว่าจะเป็นไปตามเงื่อนไขทั้งหมด บางทีมใช้ bors-ng หรือ Mergify — บอทที่ผสาน PR โดยอัตโนมัติหลังจากได้รับการอัปปรูฟทั้งหมดและผ่าน CI ซึ่งช่วยเร่งกระบวนการและตัดปัจจัยมนุษย์ออกจากการ merge

แนวทางสมัยใหม่คือ trunk-based development ที่มีสาขาอายุสั้น ใน workflow นี้ต้องได้รับการอัปปรูฟภายในไม่กี่ชั่วโมง ไม่เช่นนั้นงานจะถือว่าล้าสมัยและต้องซิงค์กับ main ใหม่ ทีมที่มีวัฒนธรรมการรีวิวเข้มแข็งจะพยายามให้เวลาอัปปรูฟไม่เกิน 4 ชั่วโมงทำงาน

ข้อผิดพลาดในการอัปปรูฟและวิธีหลีกเลี่ยง

ข้อผิดพลาดที่พบบ่อยที่สุด คือการอัปปรูฟแบบพิธีการโดยไม่ตรวจสอบโค้ดจริง ๆ เมื่อ PR ใหญ่หรือ deadline ใกล้เข้ามา ผู้รีวิวอาจกด Approve โดยไม่ลงรายละเอียดในการเปลี่ยนแปลง ซึ่งทำให้กระบวนการ code review ทั้งหมดไร้ค่า วิธีแก้ไข: ตั้งขีดจำกัดขนาดของ PR (ไม่เกิน 400 บรรทัด) และใช้เครื่องมือวิเคราะห์โค้ด (SonarQube, CodeClimate) สำหรับการตรวจสอบอัตโนมัติ

ข้อผิดพลาดที่สอง — การอัปปรูฟที่เข้มงวดเกินไป การคาดหวังโค้ดที่สมบูรณ์แบบจะบล็อกการพัฒนา ผู้รีวิวบางครั้งเรียกร้องให้แก้ไขข้อสังเกตด้านสไตล์ซึ่งไม่ส่งผลต่อคุณภาพ วิธีแก้ไข: แยกให้ชัดเจนระหว่างข้อสังเกตที่บังคับ (การบล็อก) กับข้อเสนอทางเลือก (ความคิดเห็น) GitHub อนุญาตให้ระบุอย่างชัดเจนว่าความคิดเห็นใดเป็นการบล็อกหรือไม่

ข้อผิดพลาดที่สาม — การอัปปรูฟโดยไม่ตรวจสอบ CI/CD แม้โค้ดจะดูถูกต้อง แต่ก็อาจคอมไพล์ไม่ผ่านหรือเทสต์ไม่ผ่าน Branch Protection ที่ตั้งค่าไว้จะบล็อกการ merge โดยอัตโนมัติเมื่อ CI เป็นสีแดง แต่บางทีมปิดการป้องกันนี้เพื่อความรวดเร็ว วิธีแก้ไข: ตรวจสอบสถานะ CI ก่อนอัปปรูฟเสมอ และไม่ควรอนุมัติ PR ที่มี pipeline เป็นสีแดง

• การอัปปรูฟแบบพิธีการ — ไม่มีการตรวจสอบโค้ดจริง ๆ วิธีแก้ไข: ขีดจำกัด 400 บรรทัดต่อ PR
• ความเข้มงวดเกินไป — การบล็อกเพราะข้อสังเกตด้านสไตล์ วิธีแก้ไข: แบ่งเป็น blocking และ optional
• การเพิกเฉย CI — การอัปปรูฟเมื่อ pipeline เป็นสีแดง วิธีแก้ไข: ตรวจสอบสถานะการตรวจสอบเสมอ
• การกำหนดให้ผู้เขียน — การอัปปรูฟโดยผู้เขียน PR วิธีแก้ไข: ตั้งค่า Branch Protection ต่อต้านผู้เขียน