ในการพัฒนาซอฟต์แวร์ร่วมกัน การรันการทดสอบ API ด้วยตนเองหลังจากการคอมมิตโค้ดทุกครั้งอาจกลายเป็นเรื่องน่าเบื่อหน่ายอย่างรวดเร็ว จะดีกว่าไหมถ้าการทดสอบเหล่านี้สามารถรันได้โดยอัตโนมัติเมื่อมีการพุชโค้ดใหม่?
ข่าวดีคือสิ่งนี้เป็นไปได้ทั้งหมด ทีมส่วนใหญ่ใช้แพลตฟอร์ม CI/CD อยู่แล้วเพื่อจัดการการบิลด์โค้ดและการปรับใช้ (deployment) และแพลตฟอร์มเหล่านี้ออกแบบมาเพื่อรับฟังเหตุการณ์ Git commit เมื่อคุณพุชโค้ด พวกมันจะดำเนินการตามงานที่กำหนดไว้ล่วงหน้าโดยอัตโนมัติ เช่น การคอมไพล์ การแพ็คเกจ หรือการปรับใช้
การรันการทดสอบ API แบบอัตโนมัติก็เช่นกัน Apidog มีเครื่องมือ CLI ที่ช่วยให้คุณสามารถเรียกใช้การทดสอบอัตโนมัติได้ด้วยคำสั่งเดียว ด้วยการเพิ่มคำสั่งนี้ลงใน CI/CD pipeline ของคุณ คุณสามารถมั่นใจได้ว่าการทดสอบจะทำงานโดยอัตโนมัติหลังจากการส่งโค้ดทุกครั้ง
กระบวนการตั้งค่านั้นตรงไปตรงมา สิ่งสำคัญที่ต้องทำความเข้าใจคือกลไกการทริกเกอร์ทำงานอย่างไร จากนั้นเลือกวิธีการผสานรวมที่เหมาะสมตามแพลตฟอร์มที่ทีมของคุณใช้งานอยู่
กลไกการทริกเกอร์การทดสอบอัตโนมัติทำงานอย่างไร? (หลักการ)
หัวใจของกระบวนการทั้งหมดคือ "การรับฟังเหตุการณ์ (Event Listening) + การดำเนินการคำสั่ง (Command Execution)"
เมื่อคุณพุชโค้ดไปยัง Git repository แพลตฟอร์ม CI/CD จะรับฟังเหตุการณ์ Git นี้ และตามการกำหนดค่าที่คุณตั้งไว้ล่วงหน้า (เช่น สคริปต์ pipeline หรือไฟล์ config) จะดำเนินการคำสั่งทดสอบของ Apidog โดยอัตโนมัติ
หลักการนี้สามารถอธิบายได้ดังนี้:
แพลตฟอร์ม CI/CD มีวิธีการรับฟังเหตุการณ์ Git หลักๆ สองวิธี:
วิธีแรกคือกลไกเหตุการณ์ในตัวของแพลตฟอร์ม ตัวอย่างเช่น GitHub Actions สามารถระบุได้โดยตรงในไฟล์ config: on: [push, pull_request] เมื่อคุณพุชโค้ดหรือสร้าง PR แพลตฟอร์มจะรับฟังเหตุการณ์ Git เหล่านี้โดยอัตโนมัติและเริ่มการทดสอบ
วิธีที่สองคือผ่าน Webhook ซึ่งเหมาะสำหรับสถานการณ์ที่ต้องการการสื่อสารข้ามแพลตฟอร์ม เช่น Jenkins คุณจะต้องกำหนดค่า URL สำหรับการทริกเกอร์ด้วยตนเอง
ไม่ว่าจะใช้วิธีใด ขั้นตอนสุดท้ายก็ยังคงเหมือนเดิมเสมอ: ดำเนินการคำสั่ง apidog run เพื่อเริ่มการทดสอบอัตโนมัติ
โซลูชันการผสานรวมสำหรับแพลตฟอร์มยอดนิยม
หากคุณใช้แพลตฟอร์มโฮสติ้งโค้ดเช่น GitHub หรือ GitLab การทริกเกอร์การทดสอบจะง่ายเป็นพิเศษ แพลตฟอร์มเหล่านี้มีบริการ CI/CD ในตัว (เช่น GitHub Actions, GitLab CI) ที่สามารถรับฟังเหตุการณ์ Git และดำเนินการตามงานได้โดยตรง คุณสามารถอ้างอิงเอกสารเหล่านี้เพื่อเริ่มต้นได้อย่างรวดเร็ว:
อย่างไรก็ตาม หลายทีมมีการตั้งค่าที่ซับซ้อนกว่า ตัวอย่างเช่น โค้ดถูกโฮสต์บน GitHub หรือ GitLab แต่ CI/CD pipeline ทำงานบน Jenkins ในกรณีนี้ GitHub/GitLab และ Jenkins เป็นสองระบบที่แยกจากกัน — ระบบแรกไม่สามารถทริกเกอร์ระบบหลังได้โดยตรง
สำหรับสถานการณ์ข้ามแพลตฟอร์ม Webhook เป็นโซลูชันที่เรียบง่ายและมีประสิทธิภาพ Webhook ทำงานเหมือนกลไก callback—เมื่อเหตุการณ์เฉพาะ (เช่น Git push) เกิดขึ้นบน GitHub มันจะส่งคำขอไปยัง Webhook URL ที่กำหนดไว้ล่วงหน้าโดยอัตโนมัติ เพื่อแจ้งเตือนระบบภายนอก ด้วยการจัดหา Webhook endpoint, Jenkins สามารถรับการแจ้งเตือนเหล่านี้และทริกเกอร์งานทดสอบได้โดยอัตโนมัติ
มาดูการกำหนดค่าเฉพาะ: โค้ดถูกโฮสต์บน GitHub แต่ test pipeline ทำงานบน Jenkins
การผสานรวม GitHub + Jenkins สำหรับการรันการทดสอบอัตโนมัติของ Apidog
หากทีมของคุณเก็บโค้ดบน GitHub แต่ใช้ Jenkins ในการรันงานบิลด์ นี่คือวิธีการตั้งค่า:
ขั้นตอนที่ 1: กำหนดค่า Jenkins และรับ Webhook URL
ขั้นแรก เตรียมงานทดสอบใน Jenkins ทำตามเอกสาร ผสานรวมกับ Jenkins เพื่อสร้างโปรเจกต์ กำหนดค่าคำสั่งบิลด์ และตรวจสอบให้แน่ใจว่าคำสั่ง CLI สามารถทำงานได้อย่างถูกต้อง
ถัดไป รับ Webhook URL จาก Jenkins URL นี้ทำหน้าที่เป็นจุดเข้าสำหรับระบบภายนอกในการเรียก Jenkins และ GitHub จะใช้มันเพื่อทริกเกอร์งานทดสอบ
วิธีที่ง่ายที่สุดคือการติดตั้งปลั๊กอิน "Generic Webhook Trigger" ค้นหาและติดตั้งได้ในหน้าการจัดการปลั๊กอินของ Jenkins จากนั้นรีสตาร์ท Jenkins
จากนั้นไปที่หน้าการกำหนดค่าโปรเจกต์ของคุณและเปิดใช้งานปลั๊กอินนี้ ที่อยู่ Webhook จะเป็น:
http://<your Jenkins server address>/generic-webhook-trigger/invoke`
เพื่อความปลอดภัย ขอแนะนำให้ตั้งค่า Custom Token เพื่อให้ที่อยู่กลายเป็น:
http://<your Jenkins server address>/generic-webhook-trigger/invoke?token=<xxxxxx>เมื่อคุณได้ URL นี้แล้ว คุณสามารถกำหนดค่า Webhook ใน GitHub ได้
ขั้นตอนที่ 2: กำหนดค่า GitHub Webhook
ไปที่ "GitHub repository → Settings → Webhooks" ของคุณ เพิ่ม Webhook ใหม่ ป้อนที่อยู่จากขั้นตอนก่อนหน้า ตั้งค่า Content type เป็น application/json เลือก push หรือเหตุการณ์อื่นๆ ที่คุณต้องการทริกเกอร์การทดสอบ และบันทึกการกำหนดค่า
หลังจากการกำหนดค่า ทุกครั้งที่มีการพุชโค้ดจะทริกเกอร์ Jenkins ให้ดำเนินการงานทดสอบโดยอัตโนมัติ คุณสามารถพุชโค้ดบางส่วนเพื่อทดสอบและตรวจสอบบันทึกการบิลด์ของ Jenkins และผลการทดสอบได้
ขั้นตอนที่ 3: ตรวจสอบกระบวนการทั้งหมด
เมื่อคุณพุชโค้ดไปยัง GitHub Webhook ที่กำหนดค่าไว้จะส่งการแจ้งเตือนไปยัง Jenkins Jenkins จะรับคำขอและเริ่มงานบิลด์โดยอัตโนมัติ คุณสามารถดูบันทึกการดำเนินการทดสอบได้ใน "Console" ของโปรเจกต์ Jenkins และดูรายงานผลการทดสอบขั้นสุดท้าย
การกำหนดค่า Webhook สำหรับแพลตฟอร์มอื่นๆ
นอกจาก GitHub แล้ว แพลตฟอร์มโฮสติ้งโค้ดอื่นๆ ก็รองรับ Webhook เช่น:
วิธีการกำหนดค่าจะคล้ายกัน กุญแจสำคัญคือการทำความเข้าใจกลไกการทริกเกอร์: การคอมมิต Git จะสร้างเหตุการณ์ ซึ่งจากนั้นจะถูกใช้เพื่อแจ้งเตือนแพลตฟอร์ม CI/CD ผ่านการรับฟังเหตุการณ์หรือ Webhook ซึ่งท้ายที่สุดจะทริกเกอร์การดำเนินการคำสั่งทดสอบโดยอัตโนมัติ
สำหรับวิธีการผสานรวมแพลตฟอร์ม CI/CD เพิ่มเติม โปรดดูส่วน การผสานรวม CI/CD ในเอกสารอย่างเป็นทางการของ Apidog