GitHub Actions หรือ GitLab CI: นาทีถูกกว่าอาจสร้างเสร็จช้ากว่า

การเลือกระหว่าง GitHub Actions กับ GitLab CI ต้องเทียบต้นทุนต่อ pipeline ที่ให้ผลพร้อมเวลารอ ไม่ใช่ราคานาทีของ runner อย่างเดียว นาทีในโควตาของแพ็กเกจที่จ่ายไปแล้วอาจไม่ทำให้บิลเพิ่ม แต่ถ้า build ช้ากว่า ทีมก็ได้รับผลช้ากว่าอยู่ดี

สำหรับ repository ส่วนตัว คำตอบจึงขึ้นกับค่า seat โควตารายเดือน ขนาด runner จำนวน job และสถานะแคชด้วย งาน Redmine ที่ทดสอบบนเครื่องใกล้เคียงกันให้ GitHub Actions เสร็จเร็วกว่า GitLab CI ในรอบที่อุ่นแคชแล้ว แต่ผลนี้บอกความเร็วของชุดงานนั้นเท่านั้น ส่วนเวลาที่นักพัฒนาต้องรอจริงยังอาจมีคิวก่อน runner เริ่มงาน

ราคา runner กับโควตาเป็นคนละบรรทัด

ราคา GitHub Team แสดงค่า seat 4 ดอลลาร์ต่อผู้ใช้ต่อเดือนในช่วง 12 เดือนแรก และให้ Actions 3,000 นาทีต่อเดือนสำหรับงานใน repository ส่วนตัว ขณะที่ GitHub Free ให้ 2,000 นาทีต่อเดือน และงานใน repository สาธารณะใช้ฟรีบน runner มาตรฐาน โควตาของแต่ละแผนไม่ได้เพิ่มอีกชุดเมื่อรับสมาชิกใหม่เข้าทีม หากหลาย repository ใช้บัญชีองค์กรเดียวกัน นาทีจากงานเหล่านั้นก็ใช้โควตาร่วมกัน

อัตราและวิธีปัดนาทีของ GitHub คิด runner Linux มาตรฐาน 2 คอร์ที่ 0.006 ดอลลาร์ต่อนาที และ Windows 2 คอร์ที่ 0.010 ดอลลาร์ต่อนาที โดยปัดเวลาของแต่ละ job ที่มีเศษขึ้นเป็นนาทีเต็ม งานที่ใช้ 9 นาที 44 วินาทีจึงกินโควตา 10 นาที ไม่ใช่ 9.73 นาที เมื่อ workflow แตกเป็นหลาย job เศษเวลาของแต่ละ job อาจทำให้นาทีที่คิดมากกว่าการปัดผลรวมเพียงครั้งเดียว

สูตร compute minutes ของ GitLab นำวินาทีที่แต่ละ job รันมาหาร 60 แล้วคูณ cost factor ก่อนรวมเข้ากับการใช้ของ namespace ระดับบนสุด งานที่อยู่ในสถานะ created หรือ pending ยังไม่กิน compute minutes แม้ผู้พัฒนาจะรอผลอยู่ก็ตาม Linux runner ขนาด small มีตัวคูณ 1 และ medium มีตัวคูณ 2 นาทีตามนาฬิกาที่เท่ากันบน runner สองขนาดนี้จึงใช้โควตาไม่เท่ากัน

แพ็กเกจ GitLab.com ให้ Free 400 compute minutes ต่อเดือนและจำกัด 5 ผู้ใช้ต่อกลุ่มระดับบน ขณะที่ Premium ราคา 29 ดอลลาร์ต่อผู้ใช้ต่อเดือนเมื่อจ่ายรายปี รวม 10,000 compute minutes ต่อเดือน และมีชุดเสริม 1,000 นาทีราคา 10 ดอลลาร์ โควตาของ Premium ใช้ร่วมกันทั้งกลุ่ม ไม่ได้คูณตาม seat จึงต้องแยกค่าระบบที่ทีมจ่ายอยู่แล้วออกจากเงินที่ต้องเพิ่มเพื่อรัน CI

ราคานาทีส่วนเกินของ GitHub กับราคานาทีเสริมของ GitLab เป็นราคาคนละเงื่อนไข GitHub คิดตามชนิด runner และปัดแต่ละ job ส่วน GitLab หัก compute minutes หลังคูณ cost factor และขายนาทีเพิ่มเป็นชุด ถ้า Premium มีโควตาเหลืออยู่ การรันอีก job บน runner small ไม่เพิ่มค่าใช้จ่ายทันที แม้เวลาที่ใช้ยังลดโควตาที่เหลือสำหรับงานถัดไป นี่คือกรณีที่นาทีซึ่งดูถูกกว่าสำหรับทีมอาจให้ผลช้ากว่าได้

ผลทดสอบ Redmine วัดความเร็วของงานแบบใด

การทดสอบ Redmine ของ Semaphore ซึ่งอัปเดต 27 พฤษภาคม 2026 ใช้ repository ชุดทดสอบ และขั้นตอนติดตั้ง dependency เดียวกัน รันบนเครื่อง 2 vCPU หลังอุ่นแคช แล้ววัดผู้ให้บริการละ 10 รอบโดยไม่ตัดค่าผิดปกติ GitHub Actions เฉลี่ย 9 นาที 44 วินาที และ GitLab CI เฉลี่ย 11 นาที 15 วินาที ผลต่างคือ 1 นาที 31 วินาทีต่อ build ในเงื่อนไขนั้น

งานทดสอบเป็น job เดี่ยว จึงไม่มีผลจากการแยกขั้นตอนให้ทำงานขนานกัน เครื่อง GitHub มี RAM 7 GB ส่วน GitLab มี 8 GB และผู้จัดทดสอบขายบริการ CI/CD ของตนเองด้วย ผลเฉลี่ยนี้เหมาะสำหรับตั้งสมมติฐานเรื่องความเร็วและต้นทุน แต่ไม่ใช่คำรับรองว่า repository ของทีมอื่นจะได้ส่วนต่างเท่ากัน

การอุ่นแคชเป็นเงื่อนไขที่ส่งผลต่อการตีความโดยตรง เมื่อ dependency ถูกดึงจากแคชได้ รอบงานย่อมต่างจากรอบแรกหลังเปลี่ยนไฟล์ dependency หรือรอบที่แคชหาไม่เจอ เวลาของการดาวน์โหลด สร้าง และอัปโหลดแคชอาจย้ายจุดคอขวดไปคนละช่วงของ job ได้ ดังนั้นตัวเลขข้างต้นใช้แทนผลของรอบแคชว่างไม่ได้

แบบจำลองทีม 5, 20 และ 50 คน

ตัวอย่างนี้เป็นสมมติฐาน: สมาชิกแต่ละคนเริ่ม 1 build ต่อวัน ทำงาน 22 วันต่อเดือน ทุก build เป็น job เดี่ยวบน Linux และใช้เวลาเฉลี่ยจาก Redmine เท่ากันทุกรอบ เปรียบเทียบ GitHub Team กับ GitLab Premium สำหรับ repository ส่วนตัว โดยไม่มีงานอื่นแบ่งโควตา ไม่มีภาษี ค่าเก็บข้อมูล หรือค่าบริการเสริม จำนวนคนเป็นเพียงตัวกำหนดจำนวน build และ seat ในแบบจำลอง ไม่ได้หมายความว่าทุกทีมมีพฤติกรรมรันงานเหมือนกัน

เวลาที่ใช้คำนวณคือ GitHub 10 นาทีต่อ job หลังปัด และ GitLab 11.25 compute minutes ต่อ job บน runner small ที่มี cost factor 1 ค่ารายเดือนในตัวอย่างเท่ากับค่า seat บวกค่านาทีเกินโควตา ถ้า GitLab ต้องซื้อนาทีเสริม ให้ซื้อเป็นชุดจนพอใช้ ผลต่อไปนี้จึงเป็นประมาณการจากเงื่อนไขเดียวกัน ไม่ใช่บิลขององค์กรจริง และไม่รวมระยะเวลารอคิว

• ทีม 5 คน: 110 build ใช้ GitHub 1,100 นาทีและ GitLab 1,237.5 compute minutes ทั้งคู่ยังอยู่ในโควตาของแผนที่เลือก ค่า GitHub Team เป็น 20 ดอลลาร์ต่อเดือน ส่วน GitLab Premium เป็น 145 ดอลลาร์ต่อเดือน ต้นทุนต่อ build รวม seat จึงประมาณ 0.18 กับ 1.32 ดอลลาร์ตามลำดับ
• ทีม 20 คน: 440 build ใช้ GitHub 4,400 นาที เกินโควตา 1,400 นาที ค่า seat 80 ดอลลาร์บวกค่านาที 8.40 ดอลลาร์ รวม 88.40 ดอลลาร์ต่อเดือน GitLab ใช้ 4,950 compute minutes ยังไม่เกินโควตา Premium จึงมีค่า seat 580 ดอลลาร์ หรือประมาณ 0.20 กับ 1.32 ดอลลาร์ต่อ build เมื่อรวมทั้งแพ็กเกจ
• ทีม 50 คน: 1,100 build ใช้ GitHub 11,000 นาที เกินโควตา 8,000 นาที ค่า seat 200 ดอลลาร์และค่านาที 48 ดอลลาร์ รวม 248 ดอลลาร์ GitLab ใช้ 12,375 compute minutes เกินโควตา 2,375 นาที ต้องซื้อเพิ่ม 3 ชุด ชุดละ 1,000 นาทีเป็นเงิน 30 ดอลลาร์ เมื่อนับค่า seat 1,450 ดอลลาร์ ยอดรวมเป็น 1,480 ดอลลาร์และยังเหลือนาทีที่ซื้อเพิ่ม 625 นาที

สำหรับทีม 5 คน ข้อสรุปด้านบิลจะเปลี่ยนอีกครั้งหากเลือกแผนฟรีแทนแผนเสียเงิน: โควตา GitHub Free พอกับ 1,100 นาทีในสมมติฐาน ส่วน GitLab Free ต้องซื้อเพิ่มอย่างน้อย 1 ชุดเพื่อรองรับ 1,237.5 นาที การจ่าย GitLab Premium ตั้งแต่แรกจึงไม่ใช่ทางเลือกต้นทุนต่ำสุดสำหรับทีมขนาดนี้ และแพ็กเกจสองฝั่งก็ให้ความสามารถด้านการจัดการโครงการต่างกัน

ผลต่างของบิลทีมใหญ่ส่วนมากมาจาก seat มากกว่านาทีของ job หากองค์กรจ่าย GitLab Premium เพื่อคุณสมบัติอื่นอยู่แล้ว ค่า seat เหล่านั้นเป็นต้นทุนที่มีอยู่ก่อนเลือก CI และคำถามที่เกี่ยวข้องคือการรันงานเพิ่มกินโควตาหรือต้องซื้อชุดเสริมเท่าไร แต่ถ้ายังไม่ได้ซื้อแผนใด การนำค่า seat เข้าสมการตั้งแต่ต้นทำให้เห็นภาระงบทั้งหมด

เวลาตามนาฬิกาไม่เท่ากับ compute minutes

เวลาตามนาฬิกาเริ่มจากการเรียก pipeline จนผลพร้อม รวมช่วงที่ job รอ runner เริ่มงานและเวลาของขั้นตอนที่ต้องทำตามลำดับ ส่วนนาทีที่ระบบคิดค่ารันรวมเวลาของ runner ทุก job หาก job หลายตัวทำพร้อมกัน ผลรวมนี้อาจมากกว่าเวลาที่เห็นจากต้นจนจบ หาก runner ไม่พอ คิวอาจยืดเวลาตามนาฬิกาโดยไม่เพิ่ม compute minutes ของ GitLab

สมมติ pipeline มี 3 job ที่รันพร้อมกันและแต่ละ job ใช้ 10 นาที หลังเริ่มงานผลอาจพร้อมราว 10 นาที แต่มีเวลาประมวลผลรวม 30 นาที บน GitLab runner ที่มี cost factor 2 งานลักษณะนี้จะใช้ 60 compute minutes ส่วนการรอคิวก่อนเริ่มไม่ได้รวมในเลข 60 นาที ตัวอย่างนี้แสดงความต่างของหน่วยวัด โดย pipeline ที่มีขั้นตอนพึ่งพากันอาจใช้เวลาตามนาฬิกานานกว่า

ถ้าใช้ผล Redmine ในแบบจำลองทีม 20 คน ความต่าง 1 นาที 31 วินาทีคูณ 440 build เท่ากับเวลารอบงานสะสมประมาณ 11 ชั่วโมง 7 นาทีต่อเดือน เลขนี้ไม่ใช่ชั่วโมงแรงงานที่บริษัทสูญเสียทั้งหมด เพราะนักพัฒนาอาจทำงานอื่นขณะรอ และ build หลายรอบอาจเกิดพร้อมกัน มูลค่าเวลารอควรนับเฉพาะช่วงที่ผล CI ขวางงานถัดไปจริง เช่น การ merge หรือส่งให้ผู้ตรวจรับงาน แล้วคูณต้นทุนเวลาที่ทีมไทยใช้เป็นบาทต่อชั่วโมง

แคช งานสาธารณะ และ runner ที่ดูแลเอง

แคชลดเวลาติดตั้ง dependency ได้เมื่อข้อมูลเดิมนำกลับมาใช้ได้ แต่ก็มีต้นทุนจากการจัดเก็บและการสร้างใหม่เมื่อ key เปลี่ยน ผลของแคชจึงขึ้นกับขนาด dependency ความถี่ที่ไฟล์ล็อกเปลี่ยน และการเก็บข้อมูลระหว่าง job หาก cache miss บ่อย ราคาต่อนาทีเดิมจะคูณกับเวลารันที่ยาวขึ้น ส่วนการทำ job ให้เล็กลงอาจเพิ่มจำนวนครั้งที่ต้องดาวน์โหลดหรืออัปโหลดข้อมูลซ้ำ

สำหรับโครงการสาธารณะ เงื่อนไขของ runner มาตรฐานบน GitHub และโควตาบน GitLab.com ทำให้การคำนวณต่างจากงานส่วนตัว GitLab ยังมี cost factor ลดลงสำหรับโครงการที่อยู่ใน GitLab for Open Source ตามเงื่อนไขของโครงการ การเปิด repository เป็นสาธารณะเพียงอย่างเดียวจึงไม่ทำให้สองฝั่งมีเงื่อนไขค่านาทีเท่ากัน

เมื่อทีมใช้ runner ที่ดูแลเอง ต้นทุนจะย้ายไปอยู่ที่เครื่อง เครือข่าย พื้นที่แคช การอัปเดต และผู้ดูแล บน GitLab.com งานที่รันด้วย runner ของทีมไม่หักโควตา compute minutes ส่วน GitHub Actions ก็มีทางเลือก self-hosted สำหรับงานลักษณะเดียวกัน แต่ความจุของเครื่องที่มีอยู่เป็นตัวกำหนดคิวและเวลารอ หากมี build มากกว่าช่องรันที่รองรับได้ ต้นทุนเครื่องโฮสต์อาจลดลงพร้อมกับเวลาที่ผลพร้อมช้าลง

สำหรับการเลือกระหว่างสองระบบ เวลารันเฉลี่ยที่สั้นบนเครื่องเดี่ยวอาจไม่ช่วยรอบส่งงานหากงานจริงติดคิว เช่นเดียวกับโควตาที่เหลือในแผนซึ่งมีประโยชน์ก็ต่อเมื่อ runner รับงานของทีมได้ทัน ความต่างระหว่างรอบแคชพร้อมกับรอบที่ต้องสร้างใหม่ จำนวน build ที่เกิดพร้อมกัน และค่า seat ที่ทีมจ่ายอยู่แล้ว จึงเปลี่ยนต้นทุนต่อผลลัพธ์ได้มากกว่าราคานาทีเพียงตัวเดียว