LEVEL 4 · ระดับเทพ
Runners & ความเร็วของ Pipeline
เมื่อทีมโตและ pipeline รันวันละหลายร้อยครั้ง สองเรื่องกลายเป็นปัญหาจริง: เครื่องที่รัน (runner) และเวลาที่ใช้ บทนี้คือมุมมองวิศวกรรมของการ scale CI/CD
13.1 Hosted vs Self-hosted — เลือกอย่างมีเหตุผล
| Hosted runner | Self-hosted runner | |
|---|---|---|
| ใครดูแล | แพลตฟอร์ม — เกิดใหม่สะอาดทุกครั้ง | คุณเอง — ติดตั้ง/อัปเดต/รักษาความปลอดภัย |
| เหมาะเมื่อ | งานทั่วไป เริ่มเร็ว ไม่อยากดูแล | ต้องการ GPU/ฮาร์ดแวร์พิเศษ, เข้าถึงเน็ตภายใน, คุมต้นทุนสเกลใหญ่ |
| ความเสี่ยง | ต่ำ | สูงถ้าใช้กับ public repo — โค้ดจาก PR อาจฝังตัวในเครื่องที่ใช้ซ้ำ |
13.2 ทำให้ pipeline เร็วขึ้น
pipeline ช้าคือ pipeline ที่บั่นทอนทุกคน เครื่องมือเร่งความเร็วเรียงตามผลที่ได้:
- ขนานงาน — แตก job อิสระให้รันพร้อมกัน (บทที่ 7) ลดเส้นทางวิกฤต
- cache — เลิกติดตั้ง dependencies ซ้ำ (บทที่ 6)
- ล้มเร็ว — เรียงด่านถูก/เร็ว (lint) ไว้หน้า ด่านแพง (E2E) ไว้หลัง (บทที่ 5)
- รันเฉพาะที่เปลี่ยน — ใน monorepo ใหญ่ ตรวจเฉพาะส่วนที่ถูกแก้ด้วย path filter แทนการรันทั้งหมด
- shallow clone —
git clone --depth 1ดึงแค่ commit ล่าสุด (ตรงกับบทที่ 15 ของเล่ม Git) ลดเวลา checkout repo ใหญ่
13.3 ทำ pipeline เป็นโค้ดที่ดูแลได้
เมื่อ workflow เยอะขึ้น มันก็คือโค้ดเบสอีกชุดที่ต้องดูแล หลีกเลี่ยงการก๊อป YAML ซ้ำไปมาด้วย reusable workflow และ composite action — แยกขั้นตอนที่ใช้ซ้ำออกเป็นชิ้นกลางแล้วเรียกใช้ เหมือนแยกฟังก์ชันในโค้ดทั่วไป pipeline ที่ดีถูกรีวิว เวอร์ชัน และรีแฟกเตอร์เหมือนโค้ด production
✅ สรุปบทที่ 13 — hosted runner สะดวกและสะอาดทุกครั้ง, self-hosted ใช้เมื่อต้องการฮาร์ดแวร์/เครือข่ายพิเศษ แต่ อันตรายกับ public repo — ใช้เป็น ephemeral และแยกเครือข่าย · เร่งความเร็ว: ขนานงาน + cache + ล้มเร็ว + รันเฉพาะที่เปลี่ยน + shallow clone · จัดการ workflow เป็นโค้ดด้วย reusable workflow/composite action