CI/CD คืออะไร? Continuous Integration และ Delivery อธิบายแบบเข้าใจง่าย

CI/CD คือวิธีการส่งมอบซอฟต์แวร์ที่ทุกการเปลี่ยนแปลงโค้ดถูกสร้าง ทดสอบ และ ถ้าผ่าน ก็เตรียมพร้อมสำหรับการปล่อยหรือปล่อยจริงโดยอัตโนมัติ CI (continuous integration) หมายความว่าการเปลี่ยนแปลงถูกรวมเข้าบ่อยๆ และตรวจด้วยการทดสอบอัตโนมัติทุกครั้ง CD (continuous delivery หรือ deployment) หมายความว่าการเปลี่ยนแปลงที่ผ่านจะถูกจัดแพ็กและส่งไปยังผู้ใช้โดยมีงานด้วยมือน้อยหรือไม่มีเลย

จุดประสงค์เรียบง่าย: จับข้อผิดพลาดภายในไม่กี่นาทีหลังเกิดขึ้น ไม่ใช่สัปดาห์ต่อมาเมื่อลูกค้าเป็นคนพบ

ทำไม CI/CD จึงสำคัญเมื่อสร้างแอปด้วย AI

ตัวสร้างแอปด้วย AI ทำการเปลี่ยนแปลงโค้ดได้รวดเร็ว คำสั่งเดียวอาจแตะหลายไฟล์ ความเร็วนั้นดีจนกระทั่งการเปลี่ยนหน้าชำระเงินแอบทำให้หน้าล็อกอินพัง และไม่มีใครสังเกตจนกว่าผู้ใช้จะส่งอีเมลมาหาคุณ

CI/CD คือตาข่ายนิรภัยสำหรับสถานการณ์นี้ แทนที่จะเชื่อว่าการเปลี่ยนแปลงแต่ละครั้งใช้ได้ pipeline จะรันการตรวจเดิมทุกครั้ง:

• แอปยังสร้าง (build) ได้โดยไม่มีข้อผิดพลาดหรือไม่
• การทดสอบอัตโนมัติยังผ่านอยู่หรือไม่
• โค้ดปฏิบัติตามกฎของโปรเจกต์ (types, การจัดรูปแบบ, การตรวจความปลอดภัย) หรือไม่

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

ตัวอย่างเปรียบเทียบในชีวิตประจำวัน

ลองนึกภาพร้านเบเกอรี่ที่ส่งขนมปังให้ร้านค้าทุกเช้า

• ไม่มี CI/CD ช่างทำขนมแต่ละคนปรับสูตรของตัวเองตลอดสัปดาห์ แล้วทุกคนรวมกันตอนค่ำวันศุกร์และหวังว่าขนมปังจะยังขึ้นฟู เมื่อไม่ขึ้น ไม่มีใครรู้ว่าการเปลี่ยนแปลงของใครเป็นต้นเหตุ
• มี CI การปรับสูตรเล็กๆ ทุกครั้งจะถูกอบเป็นขนมปังทดสอบทันทีและตรวจสอบ ทั้งรสชาติ น้ำหนัก และรูปทรง การเปลี่ยนแปลงที่ไม่ดีจะถูกจับได้ในวันเดียวกัน และคุณรู้ว่าเป็นการเปลี่ยนแปลงไหน
• มี CD ขนมปังที่ผ่านการตรวจจะถูกส่งขึ้นรถส่งของทันที บรรจุและติดฉลากแบบเดียวกันทุกครั้ง แทนที่จะให้ใครบรรจุกล่องด้วยมือตอนตีห้า

การตรวจไม่ได้ทำให้ช่างทำขนมเก่งขึ้น แต่ทำให้ความผิดพลาดของพวกเขาไม่แพง

Pipeline ของ CI/CD ทำงานอย่างไร

Pipeline คือรายการขั้นตอนที่บริการ CI/CD รันโดยอัตโนมัติเมื่อมีเหตุการณ์บางอย่าง โดยทั่วไปคือเมื่อมีคน push โค้ดไปยังที่เก็บอย่าง GitHub pipeline ทั่วไปมีลักษณะดังนี้:

แต่ละขั้นตอนทำงานบนเครื่องที่สะอาด ไม่ใช่แล็ปท็อปของใครคนหนึ่ง ดังนั้น "มันทำงานบนเครื่องของฉัน" จึงไม่เป็นข้อแก้ตัวอีกต่อไป หากขั้นตอนใดล้มเหลว pipeline จะหยุดและแจ้งผู้ที่ทำการเปลี่ยนแปลงนั้น

ขั้นตอนต่างๆ ถูกนิยามในไฟล์การตั้งค่าที่อยู่ร่วมกับโค้ด ตัวอย่างเช่นใน GitHub Actions เป็นไฟล์ YAML ในโฟลเดอร์ .github/workflows ของที่เก็บ

Continuous delivery กับ continuous deployment

คำว่า "CD" คลุมเครือ และคนใช้ทั้งสองความหมาย:

Continuous deployment ทำงานได้ดีก็ต่อเมื่อการทดสอบดีเท่านั้น หากการทดสอบของคุณไม่ครอบคลุมขั้นตอนชำระเงิน continuous deployment จะส่งหน้าชำระเงินที่พังขึ้นระบบอย่างเต็มใจ

ตัวอย่างการทำงาน: แอปจองด้วย pipeline

สมมติคุณมีแอปจองร้านทำผม และโค้ดอยู่ในที่เก็บ GitHub คุณขอให้ตัวสร้างแอปด้วย AI ว่า "เพิ่มส่วนลด 10% สำหรับลูกค้าที่มาครั้งแรก"

1. การเปลี่ยนแปลงถูก push ไปยัง branch ใหม่และเปิด pull request
2. Pipeline เริ่มทำงาน ติดตั้งแพ็กเกจและสร้างแอป ขั้นนี้ผ่าน
3. รันการทดสอบ การทดสอบหนึ่งรายการ "ลูกค้าที่กลับมาจ่ายราคาเต็ม" ล้มเหลว เพราะส่วนลดถูกใช้กับทุกคน
4. หน้า pull request แสดงเครื่องหมายกากบาทสีแดง การเปลี่ยนแปลงนี้ merge ไม่ได้
5. คุณขอให้ AI แก้ไข มันพุช การแก้ไขและ pipeline รันอีกครั้ง ทุกอย่างผ่าน
6. การเปลี่ยนแปลงถูก merge pipeline deploy ไปยังสภาพแวดล้อม staging ซึ่งคุณลองจองทดสอบ
7. คุณอนุมัติ และมัน deploy ไปยัง production

หากไม่มี pipeline ขั้นตอนที่ 3 จะเกิดขึ้นกับลูกค้าของคุณจริงๆ

คำศัพท์สำคัญ

ความเข้าใจผิดที่พบบ่อย

• "CI/CD หมายความว่าแอปของฉันได้รับการทดสอบแล้ว" pipeline รันเฉพาะการทดสอบที่คุณมี หากไม่มีการทดสอบ CI พิสูจน์ได้เพียงว่าแอปสร้างได้ เท่านั้น ให้ AI เขียนการทดสอบสำหรับขั้นตอนที่สำคัญที่สุด
• "CI/CD มีไว้สำหรับบริษัทใหญ่เท่านั้น" เครื่องมือโฮสต์อย่าง GitHub Actions ตั้งค่าได้ด้วยไฟล์การตั้งค่าสั้นๆ และทีมเล็กใช้กันบ่อย สิ่งที่ยากคือการทดสอบ ไม่ใช่เครื่องมือ
• "การ deploy อัตโนมัติหมายความว่าไม่มีใครตรวจอะไร" pipeline ที่ดีเพิ่มการตรวจ ไม่ได้ลดการตรวจ ทีมหลายทีมยังคงมีขั้นตอนอนุมัติจากคนก่อนขึ้น production
• "ถ้า pipeline เป็นสีเขียว แอปก็ทำงานได้" หมายความว่าการตรวจอัตโนมัติผ่านเท่านั้น คุณควรลองการเปลี่ยนแปลงด้วยตัวเอง ควรเป็นใน preview หรือบน staging
• "CI/CD แทนการสำรองข้อมูลได้" ไม่ได้ migration ฐานข้อมูลที่ไม่ดีซึ่งผ่านการทดสอบยังทำลายข้อมูลจริงได้ เก็บการสำรองข้อมูลและวิธี rollback ไว้

สิ่งที่ควรขอจากตัวสร้างแอปด้วย AI ของคุณ

• "เขียนการทดสอบอัตโนมัติสำหรับการสมัคร ล็อกอิน และการชำระเงิน และแสดงวิธีรันให้ฉันดู"
• "ตั้งค่า workflow ของ GitHub Actions ที่ติดตั้ง dependencies สร้างแอป และรันการทดสอบทุกครั้งที่มี pull request"
• "เพิ่มการตรวจชนิดข้อมูล (type check) และ linter ใน pipeline และให้ล้มเหลวเมื่อมีข้อผิดพลาด"
• "อธิบายเป็นภาษาอังกฤษง่ายๆ ว่าแต่ละขั้นตอนของ pipeline ทำอะไร"
• "ถ้าการ deploy ล้มเหลวกลางคันจะเกิดอะไรขึ้น และฉัน rollback อย่างไร"
• "ตรวจว่าไม่มี secret ฝังอยู่ในที่เก็บหรือถูกพิมพ์ออกมาในล็อกของ pipeline"

หากแอปของคุณใช้ API key pipeline ก็ต้องใช้มันด้วย โดยเก็บเป็น secret ที่เข้ารหัสไว้ในเครื่องมือ CI ไม่ใช่ในไฟล์การตั้งค่า ดูenvironment variables และ secrets

CI/CD กับ Mythex

Mythex ไม่ได้รัน pipeline CI ให้คุณ แต่ครอบคลุมความต้องการหลายอย่างในรูปแบบของตัวเอง:

• Checkpoints หลังทุก turn ของเอเจนต์ที่สำเร็จ Mythex บันทึก checkpoint ของ git และ Revert to this point จะย้อนโปรเจกต์กลับหากการเปลี่ยนแปลงผิดพลาด ดู แชต
• App Testing พิมพ์ /test เอเจนต์จะคลิกผ่าน preview สดของคุณเหมือนผู้ใช้และรายงานขั้นตอนที่พัง เหมาะก่อนเผยแพร่ทุกครั้ง ดู App Testing
• การเผยแพร่เป็นขั้นตอนที่ตั้งใจ การเปลี่ยนแปลงจะปรากฏใน preview ส่วนตัวก่อน แอปสาธารณะของคุณจะอัปเดตก็ต่อเมื่อคุณเผยแพร่อีกครั้ง ซึ่งใกล้เคียง continuous delivery มากกว่า continuous deployment
• การซิงก์ GitHub (Pro) ซิงก์โปรเจกต์ไปยังที่เก็บ GitHub แล้วคุณจะเพิ่ม GitHub Actions workflow ของคุณเองเพื่อรันการทดสอบทุกครั้งที่ push ดู GitHub และการส่งออก

สำหรับรายการตรวจสิ่งที่ต้องทดสอบด้วยมือก่อนขึ้นระบบจริง ดูวิธีทดสอบแอปก่อนเปิดตัว และสำหรับการทำงานกับ version control ดูวิธีใช้ Git กับแอปที่สร้างด้วย AI

คำถาม