ลองลดเวลา Deploy ของ Github Actions กันไหม?

ลองลดเวลา Deploy ของ Github Actions กันไหม?

บทความนี้เล่าถึงวิธีต่าง ๆ ที่ได้ลองใช้เพื่อลดเวลาในการ Deploy ด้วย Github Actions และประสบการณ์ในการแก้ปัญหาที่พบระหว่างทาง

• เมื่อเวลา Deploy ค่อย ๆ นานขึ้น ก็เริ่มส่งผลเสียต่อความเร็วในการพัฒนาและประสิทธิภาพการทำงานของทีม
• บทความนี้อธิบายว่ามีการปรับปรุงหลายอย่างอย่างไรบ้างเพื่อแก้ปัญหา เช่น เปลี่ยนกระบวนการ Deploy ให้ทำงานแบบขนาน และเพิ่ม selective build trigger

สถานการณ์ปัญหา

• เวลา Deploy ที่ใช้ Github Actions ค่อย ๆ ยาวนานขึ้น จนมีเวลา Deploy เฉลี่ย 27 นาที
• เริ่มส่งผลกระทบต่อประสิทธิภาพการพัฒนา
• เดิมใช้วิธี build และ deploy Frontend, Intro, Backend แบบเรียงลำดับ ซึ่งเมื่อเวลาผ่านไปกลายเป็นวิธี Deploy ที่ไม่มีประสิทธิภาพและทำให้เวลา Deploy เพิ่มขึ้น

การปรับปรุงหลัก

• นำการประมวลผลแบบขนานมาใช้
  • แยกงาน Deploy ของ Frontend และ Backend ที่เดิมทำแบบลำดับให้ทำงานแบบขนาน ทำให้เวลา Deploy ลดจาก 27 นาทีเหลือ 18 นาที
  • ในกระบวนการนี้ยังมีการทำโมดูลาร์ให้กับโค้ด Github Workflow ด้วย
• นำ selective build trigger มาใช้
  • เดิมใช้ path-filter เพื่อให้ build เฉพาะส่วนที่มีการเปลี่ยนแปลง แต่พบปัญหาในสถานการณ์ rollback
  • จึงเลิกใช้วิธี path-filter และเปลี่ยนเป็นให้ผู้พัฒนาเลือกเป้าหมายการ Deploy ได้ผ่านตัวเลือกของ Workflow
• กลยุทธ์การใช้ Docker Image Tag
  • ลดเวลา Deploy จาก 18 นาทีเหลือ 15 นาทีด้วยการนำ Docker Image กลับมาใช้ซ้ำ
• การทำ Deploy แบบขนาน
  • แยกขั้นตอน Deploy ให้สามารถทำงานแบบขนานได้เช่นกัน เพื่อช่วยลดเวลา Deploy ลงเพิ่มเติม
• แยก Intro ออกมา
  • แยกการ build หน้า Intro ออกจาก service build ของ frontend เพื่อเพิ่มประสิทธิภาพในการ Deploy ให้สูงสุด

ผลลัพธ์

• เวลา Deploy ลดลง 55% (27 นาที -> 12 นาที)
• สามารถลดเวลาได้สูงสุด 70% ช่วยลดค่าใช้จ่ายด้านอินฟรา และเพิ่มประสิทธิภาพการพัฒนาผลิตภัณฑ์
• ประโยชน์เพิ่มเติม
  • การทำ Workflow ให้เป็นโมดูลช่วยเพิ่มการนำกลับมาใช้ซ้ำและทำให้บำรุงรักษาได้ง่ายขึ้น
  • ลดเวลาในการแก้ปัญหา และเพิ่มเสถียรภาพของระบบ