LEVEL 1 · พื้นฐานที่ใช้จริง
Build · Test · Lint — สามเสาหลักของ CI
CI ที่ดีไม่ได้วัดที่ "มี pipeline" แต่วัดที่ "ตรวจอะไรบ้าง" สามเสาหลักต่อไปนี้คือด่านมาตรฐานที่ทุก pipeline ควรมี เรียงจากเร็ว/ถูกไปช้า/แพง เพื่อให้ "ล้มเร็ว" — ด่านที่ถูกที่สุดควรล้มก่อน
5.1 Lint — ด่านที่ถูกและเร็วที่สุด
Lint คือการตรวจรูปแบบและกลิ่นของโค้ดโดยไม่ต้องรัน เช่น ตัวแปรที่ประกาศแล้วไม่ใช้, การจัดรูปแบบไม่สม่ำเสมอ, รูปแบบที่เสี่ยงบั๊ก มันเร็วมาก (วินาที) จึงควรเป็นด่านแรก ๆ — ไม่มีเหตุผลที่จะปล่อยให้เทสต์ที่ใช้เวลา 5 นาทีรันไปก่อน ทั้งที่โค้ดมี syntax ผิดที่ lint จับได้ใน 3 วินาที
5.2 Test — หัวใจของ CI
เทสต์อัตโนมัติคือสิ่งที่ทำให้ CI มีความหมาย เพราะมันคือสิ่งที่ "ตอบแทนคุณ" ว่าการเปลี่ยนแปลงไม่ทำของเดิมพัง โดยทั่วไปแบ่งเป็นชั้น ๆ ตามต้นทุน/ความเร็ว เรียกว่า testing pyramid:
| ชั้น | ตรวจอะไร | ความเร็ว / จำนวน |
|---|---|---|
| Unit | ฟังก์ชัน/หน่วยเล็กที่สุด แยกเดี่ยว | เร็วมาก · มีเยอะที่สุด |
| Integration | หลายส่วนทำงานร่วมกัน (เช่น โค้ด + ฐานข้อมูล) | ปานกลาง · มีพอประมาณ |
| End-to-End (E2E) | ทั้งระบบเหมือนผู้ใช้จริงกดใช้งาน | ช้า/เปราะ · มีน้อยที่สุด |
หลักคือ มี unit test เยอะ ๆ (เร็ว ถูก) เป็นฐาน แล้วมี E2E น้อย ๆ (ช้า แพง) ไว้บนยอด pipeline ฉลาด ๆ จะรัน unit ก่อนเพื่อล้มเร็ว แล้วค่อยลงทุนรัน E2E เมื่อชั้นล่างผ่านแล้ว
5.3 Build — พิสูจน์ว่ามันประกอบเป็นของจริงได้
การ build (คอมไพล์/แพ็ก) ใน CI พิสูจน์ว่าโค้ดไม่ใช่แค่ "เทสต์ผ่าน" แต่ "ประกอบออกมาเป็น artifact ที่ deploy ได้จริง" สำหรับภาษาที่คอมไพล์ ขั้นนี้จับ type error และปัญหา dependency ได้ ส่วนงานยุคใหม่มักจบที่การสร้าง container image ที่จะถูกส่งต่อไป deploy ในฝั่ง CD
5.4 เชื่อม CI กลับเข้า Git: status check & branch protection
นี่คือจุดที่ CI กับ Git บรรจบกันอย่างทรงพลัง ผลของ pipeline (เขียว/แดง) จะแสดงเป็น status check บน Pull Request และคุณตั้ง branch protection ให้ main ได้ว่า "ห้าม merge PR เข้ามาถ้า CI ยังไม่เขียว" — เท่ากับเปลี่ยน "ควรรันเทสต์นะ" (วินัยที่คนลืม) ให้เป็น "ระบบไม่ยอมให้ผ่านถ้าเทสต์ตก" (กฎที่บังคับเอง)
🧭 ต่อจากบทที่ 10 ของเล่ม Git — จำ Pull Request ได้ไหม — branch protection คือสิ่งที่เปลี่ยน PR จาก "ที่ขอให้รีวิว" ให้กลายเป็น "ประตูที่มีด่านอัตโนมัติเฝ้า" ทีมจริงจังมักบังคับทั้งสองอย่าง: ต้องมีคนรีวิวอนุมัติ และ CI ต้องเขียว ถึงจะกดปุ่ม merge ได้
✅ สรุปบทที่ 5 — สามเสาหลัก เรียงจากถูก/เร็วไปแพง/ช้า: lint → test → build ให้ด่านถูกล้มก่อน · เทสต์เป็นพีระมิด: unit เยอะ (ฐาน) E2E น้อย (ยอด) · build พิสูจน์ว่าประกอบเป็น artifact จริงได้ · ผูก CI กลับเข้า Git ด้วย status check + branch protection เพื่อบังคับว่า "CI ไม่เขียว = merge ไม่ได้"