บทช่วยสอนเกี่ยวกับ CI/CD Pipeline พร้อมตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
ไปป์ไลน์ CI/CD คือเส้นทางอัตโนมัติที่นำการเปลี่ยนแปลงโค้ดจากสถานะการคอมมิตไปสู่การใช้งานจริง โดยจะทำการสร้าง ทดสอบ และปรับใช้ซอฟต์แวร์ผ่านสี่ขั้นตอน ได้แก่ การเขียนโค้ด การสร้าง การทดสอบ และการปรับใช้ ซึ่งช่วยลดข้อผิดพลาดที่เกิดจากมนุษย์และลดระยะเวลาการติดต่อระหว่างนักพัฒนาและผู้ใช้ปลายทาง
CI/CD Pipeline คืออะไร?
A ไปป์ไลน์ CI/CD ระบบนี้จะทำให้กระบวนการเปลี่ยนแปลงโค้ดเป็นไปโดยอัตโนมัติ ตั้งแต่การคอมมิตของนักพัฒนาไปจนถึงการเผยแพร่เวอร์ชันที่ใช้งานจริง โดยจะสร้างโค้ด รันชุดทดสอบ และโปรโมตไบนารีอย่างปลอดภัยไปยังสภาพแวดล้อมหนึ่งหรือหลายสภาพแวดล้อม ไปป์ไลน์ที่ออกแบบมาอย่างดีจะช่วยลดข้อผิดพลาดที่เกิดจากมนุษย์ ให้ผลตอบรับที่รวดเร็วแก่นักพัฒนา และช่วยให้สามารถปรับปรุงผลิตภัณฑ์ได้บ่อยครั้งและในปริมาณน้อย
กระบวนการนี้เชื่อมโยงระบบอัตโนมัติและการตรวจสอบอย่างต่อเนื่องตลอดวงจรชีวิตของซอฟต์แวร์ ตั้งแต่การบูรณาการและการทดสอบ ไปจนถึงการส่งมอบและการใช้งาน กระบวนการที่เชื่อมโยงกันเหล่านี้เรียกรวมกันว่า กระบวนการ CI/CD (Continuous Integration/CD pipeline)
การบูรณาการอย่างต่อเนื่อง การส่งมอบอย่างต่อเนื่อง และการปรับใช้อย่างต่อเนื่องคืออะไร
- การบูรณาการอย่างต่อเนื่อง (CI): แนวทางการพัฒนาซอฟต์แวร์ที่สมาชิกในทีมจะผสานรวมงานของตนอย่างน้อยวันละครั้ง การผสานรวมแต่ละครั้งจะได้รับการตรวจสอบโดยการสร้างและทดสอบอัตโนมัติ ซึ่งจะช่วยค้นหาข้อผิดพลาดได้อย่างรวดเร็ว
- การจัดส่งต่อเนื่อง (ซีดี): เป็นแนวทางปฏิบัติทางวิศวกรรมที่ทีมงานรักษาผลิตภัณฑ์ให้อยู่ในสถานะพร้อมสำหรับการปล่อยใช้งานในตอนท้ายของแต่ละรอบการพัฒนา โดยปกติแล้วการนำไปใช้งานจริงจะต้องได้รับการอนุมัติด้วยตนเอง
- การปรับใช้ต่อเนื่อง (CD): ยกระดับ Continuous Delivery ไปอีกขั้น — ทุกการเปลี่ยนแปลงที่ผ่านการตรวจสอบอัตโนมัติจะถูกนำไปใช้งานจริงโดยอัตโนมัติ โดยไม่ต้องผ่านการตรวจสอบจากมนุษย์
ขั้นตอนต่างๆ ของไปป์ไลน์ CI/CD
ไปป์ไลน์ CI/CD คือข้อกำหนดที่สามารถนำไปปฏิบัติได้จริงของขั้นตอนที่จำเป็นในการเผยแพร่ซอฟต์แวร์เวอร์ชันใหม่ หากเกิดความล้มเหลวในขั้นตอนใด ๆ จะมีการแจ้งเตือน — ผ่านทางอีเมล Slackหรือช่องทางอื่น เพื่อให้วิศวกรผู้รับผิดชอบได้รับแจ้งทันที
ขั้นตอนต่างๆ ของไปป์ไลน์ CI/CD
แหล่งเวที
ไปป์ไลน์จะทำงานเมื่อมีการเปลี่ยนแปลงในที่เก็บโค้ด การคอมมิตใดๆ จะแจ้งให้เครื่องมือ CI/CD เรียกใช้ไปป์ไลน์ที่เกี่ยวข้อง ตัวกระตุ้นอื่นๆ ที่พบบ่อย ได้แก่ เวิร์กโฟลว์ที่ผู้ใช้เริ่มต้น การเรียกใช้ตามกำหนดเวลา และผลลัพธ์จากไปป์ไลน์ต้นทาง
สร้างเวที
ขั้นตอนการสร้าง (Build stage) จะทำการคอมไพล์ซอร์สโค้ดและแก้ไขส่วนประกอบที่จำเป็นต่างๆ ให้เป็นไฟล์ที่สามารถเรียกใช้งานได้ ภาษาที่ใช้การคอมไพล์ เช่น C++, Javaภาษา C และ Go ต้องสร้างไฟล์ไบนารีในที่นี้ ภาษาที่ใช้การตีความ เช่น Javaต้นฉบับ, Pythonและ Ruby ยังคงได้รับประโยชน์จากขั้นตอนนี้ในการจัดแพ็กเกจส่วนประกอบต่างๆ ตรวจสอบไวยากรณ์ และสร้างอิมเมจคอนเทนเนอร์
ความล้มเหลวในขั้นตอนการสร้างมักบ่งชี้ถึงการตั้งค่าโปรเจ็กต์ที่ไม่ถูกต้องในระดับพื้นฐาน ดังนั้นจึงต้องแก้ไขปัญหาโดยทันที
ขั้นตอนการทดสอบ
ขั้นตอนการทดสอบจะดำเนินการชุดทดสอบอัตโนมัติเพื่อตรวจสอบความถูกต้องของโค้ดและพฤติกรรมของซอฟต์แวร์ โดยจะตรวจจับข้อผิดพลาดที่สามารถจำลองได้ง่ายก่อนที่จะถึงมือลูกค้า การเขียนและการบำรุงรักษาการทดสอบเป็นความรับผิดชอบของนักพัฒนา ส่วนกระบวนการทำงานหลัก (pipeline) ทำหน้าที่เพียงแค่บังคับให้การทดสอบทำงานเท่านั้น
ปรับใช้เวที
ขั้นตอนการปรับใช้จะนำเอาสิ่งที่ได้รับการตรวจสอบแล้วไปสู่สภาพแวดล้อมเป้าหมาย เช่น staging, UAT หรือ production เมื่อบิลด์ผ่านการทดสอบที่จำเป็นทั้งหมดแล้ว การปรับใช้สามารถเริ่มต้นได้โดยอัตโนมัติ (การปรับใช้ต่อเนื่อง) หรือหลังจากผ่านขั้นตอนการตรวจสอบด้วยตนเอง (การส่งมอบต่อเนื่อง)
ตัวอย่างของไปป์ไลน์ CI/CD
ขั้นตอนโดยละเอียดด้านล่างนี้แสดงให้เห็นถึงกระบวนการทำงานที่เป็นรูปธรรมโดยใช้ GitHub CircleCIและ AWS
- แหล่ง Code ควบคุม: จัดเก็บโค้ดแอปพลิเคชันไว้ในที่เก็บ GitHub ส่วนตัว เพื่อให้สามารถทำงานร่วมกับบริการสร้าง สแกน และปรับใช้ได้
- บูรณาการอย่างต่อเนื่อง: ต่อ CircleCI ไปยังที่เก็บโค้ดเพื่อให้ทุกครั้งที่มีการพุชโค้ด ระบบจะดึงโค้ดใหม่มา สร้าง และเรียกใช้ชุดทดสอบ
- ปรับใช้ในสภาพแวดล้อม UAT: กำหนดค่า CircleCI เพื่อนำเวอร์ชันที่สร้างสำเร็จไปใช้งานในสภาพแวดล้อม AWS UAT สำหรับการทดสอบโดยผู้มีส่วนได้ส่วนเสีย
- นำไปใช้งานจริงในระบบการผลิต: นำขั้นตอน CI/CD เดิมมาใช้ซ้ำเพื่อนำอาร์ติแฟกต์ไปสู่การใช้งานจริง โดยมีขั้นตอนการอนุมัติด้วยตนเองหากคุณกำลังใช้งาน Continuous Delivery
แนวทางปฏิบัติที่ดีที่สุดของ CI/CD Pipeline
แนวทางปฏิบัติเหล่านี้ช่วยให้กระบวนการทำงานรวดเร็ว เชื่อถือได้ และได้รับความไว้วางใจจากทีม:
- ก่อนที่จะนำระบบอัตโนมัติมาใช้ ควรจัดทำเอกสารขั้นตอนการจัดส่งปัจจุบัน เพื่อให้คุณทราบว่าควรคงไว้ เปลี่ยนแปลง หรือลบส่วนใดบ้าง
- เริ่มต้นด้วยการทดสอบแนวคิดขนาดเล็กก่อนที่จะทำการอัตโนมัติกระบวนการทั้งหมดในคราวเดียว
- จัดโครงสร้างไปป์ไลน์เป็นหลายขั้นตอน เพื่อให้การตรวจสอบขั้นพื้นฐานที่รวดเร็วทำงานก่อน
- เริ่มต้นเวิร์กโฟลว์ทุกขั้นตอนจากสภาพแวดล้อมที่สะอาดและแยกต่างหาก เพื่อให้การสร้างสามารถทำซ้ำได้
- เพิ่มเครื่องมือโอเพนซอร์สที่ครอบคลุมทุกอย่าง ตั้งแต่รูปแบบการเขียนโค้ดไปจนถึงการสแกนความปลอดภัย
- ใช้ศูนย์กลางตรวจสอบคุณภาพโค้ดที่ทำการทดสอบแบบเดียวกันกับทุกสาขา
- ตรวจสอบความถูกต้องของทุก pull request โดยใช้ peer review และถือว่าผลลัพธ์จาก pipeline เป็นส่วนหนึ่งของการตรวจสอบ
- กำหนดตัวชี้วัดความสำเร็จก่อนเริ่มการเปลี่ยนแปลง เพราะตัวชี้วัดเหล่านี้จะช่วยขับเคลื่อนการพัฒนาอย่างต่อเนื่อง
ข้อดีของไปป์ไลน์ CI/CD
กระบวนการ CI/CD ที่มีประสิทธิภาพจะมอบผลประโยชน์ที่วัดผลได้หลายประการ:
- แทนที่กระบวนการสร้างและเผยแพร่ด้วยตนเองที่มีโอกาสเกิดข้อผิดพลาดสูงด้วยระบบอัตโนมัติที่เชื่อถือได้
- ช่วยเพิ่มความสม่ำเสมอและคุณภาพของสินค้าทุกชิ้นที่จัดส่ง
- เพิ่มความยืดหยุ่น — สามารถเพิ่มฟังก์ชันการทำงานใหม่ได้ตามความต้องการ
- ช่วยให้การสื่อสารระหว่างนักพัฒนา ทีม QA และฝ่ายปฏิบัติการมีประสิทธิภาพยิ่งขึ้น
- ช่วยเร่งกระบวนการรับฟังความคิดเห็นจากลูกค้าด้วยการออกเวอร์ชันใหม่บ่อยครั้ง
- เพิ่มการมองเห็นผลิตภัณฑ์ผ่านแดชบอร์ด บันทึก และการแจ้งเตือน
- ขจัดข้อผิดพลาดที่เกิดจากมนุษย์และลดต้นทุนในการปล่อยเวอร์ชันใหม่
- ช่วยลดระยะเวลาของวงจรการพัฒนาซอฟต์แวร์
- ช่วยให้เกิดการตอบรับที่รวดเร็วจากนักพัฒนาไปสู่ผู้ใช้ปลายทาง
- เน้นการเปลี่ยนแปลงที่ทำให้การสร้างล้มเหลว เพื่อให้สามารถย้อนกลับได้อย่างรวดเร็ว
- ใช้การทดสอบอัตโนมัติควบคู่กับการทดสอบแบบสำรวจด้วยตนเองอย่างง่าย ๆ เพื่อรักษาระดับคุณภาพให้สูงอยู่เสมอ
เครื่องมือ CI/CD ที่สำคัญ
ทีมงานสมัยใหม่เลือกใช้เครื่องมือ CI/CD จากระบบนิเวศที่มีประสิทธิภาพ โดยเครื่องมือที่ใช้กันอย่างแพร่หลายที่สุดมีรายละเอียดดังต่อไปนี้
1) Jenkins
Jenkins เป็นเซิร์ฟเวอร์ Continuous Integration แบบโอเพนซอร์สที่ช่วยทำให้กระบวนการสร้าง ทดสอบ และเผยแพร่ซอฟต์แวร์เป็นไปโดยอัตโนมัติ เขียนด้วยภาษาโปรแกรม Java และได้รับการสนับสนุนจากระบบปลั๊กอินขนาดใหญ่ Jenkins ให้พลังงานแก่สถานที่ติดตั้งหลายแสนแห่งทั่วโลก
สิ่งอำนวยความสะดวก:
- สร้างและทดสอบโค้ดหลายครั้งต่อวัน
- ระบบจะทำการสร้างและทดสอบซอฟต์แวร์โดยอัตโนมัติทั้งหมด ช่วยประหยัดเวลาและลดข้อผิดพลาด
- ทำการติดตั้งโค้ดหลังจากการสร้างและทดสอบสำเร็จทุกครั้ง
- ช่วยเร่งวงจรการพัฒนาให้เร็วขึ้นด้วยการรับฟังความคิดเห็นอย่างรวดเร็ว
Link: https://www.jenkins.io/download/
2) Bamboo
Bamboo เป็นเซิร์ฟเวอร์สร้างซอฟต์แวร์แบบบูรณาการอย่างต่อเนื่อง (Continuous Integration) ที่รวมการสร้าง การทดสอบ และการเผยแพร่แบบอัตโนมัติไว้ในเครื่องมือเดียว สามารถทำงานร่วมกับระบบอื่นๆ ได้อย่างราบรื่น Jira Software และ Bitbucket.
สิ่งอำนวยความสะดวก:
- ดำเนินการทดสอบแบบกลุ่มขนาน
- ติดตั้งและตั้งค่าได้รวดเร็ว
- การกำหนดสิทธิ์เฉพาะสภาพแวดล้อมช่วยให้นักพัฒนาและฝ่าย QA สามารถปรับใช้ซอฟต์แวร์ไปยังสภาพแวดล้อมของตนเองได้
- เวิร์กโฟลว์การสร้างสาขา Git ในตัวที่รวมสาขาโดยอัตโนมัติ
Link: https://www.atlassian.com/software/bamboo
3) CircleCI
CircleCI เป็นเครื่องมือ CI ที่ยืดหยุ่นซึ่งใช้ในการสร้างแอปพลิเคชันมือถือแบบข้ามแพลตฟอร์ม Python API, คลัสเตอร์ Docker และอื่นๆ ช่วยลดข้อผิดพลาดและปรับปรุงคุณภาพแอปพลิเคชันผ่านการตอบสนองที่รวดเร็ว
สิ่งอำนวยความสะดวก:
- ตัวเลือกสภาพแวดล้อมการสร้างโปรแกรม
- รองรับหลายภาษารวมทั้ง C++, Javaสคริปต์, .NET, PHP, Pythonและรูบี้
- Docker รองรับการสร้างอิมเมจแบบกำหนดเอง
- ยกเลิกบิลด์ที่อยู่ในคิวหรือกำลังทำงานโดยอัตโนมัติเมื่อมีการเริ่มบิลด์ใหม่
Link: https://circleci.com/
4) GitHub Actions, GitLab CI และ Argo CD
GitHub Actions และ GitLab CI ผสานรวม CI/CD เข้ากับแพลตฟอร์มควบคุมเวอร์ชันโดยตรง ทำให้ไม่จำเป็นต้องใช้เซิร์ฟเวอร์สร้างบิลด์ภายนอก ส่วน Argo CD เพิ่มการปรับใช้แบบต่อเนื่องสไตล์ GitOps สำหรับคลัสเตอร์ Kubernetes โดยปรับสถานะของคลัสเตอร์ให้เป็นไปตามสถานะที่ต้องการซึ่งประกาศไว้ใน Git
เหตุใดไปป์ไลน์ CI/CD จึงมีความสำคัญสำหรับผู้นำด้านไอที
- ช่วยเพิ่มความน่าเชื่อถือและความคาดการณ์ได้ในการปล่อยเวอร์ชันใหม่
- ทำให้องค์กรด้านวิศวกรรมมีประสิทธิภาพมากขึ้นtracเป็นประโยชน์ต่อนักพัฒนา
- ดึงโค้ดจากระบบควบคุมเวอร์ชันและเรียกใช้งานการสร้างด้วยการคลิกเพียงครั้งเดียว
- ย้ายไฟล์ไบนารีไปยังสภาพแวดล้อมเป้าหมายอย่างปลอดภัย
- ช่วยให้หัวหน้าโครงการสามารถจัดการตัวแปรสภาพแวดล้อมและการกำหนดค่าต่างๆ สำหรับแต่ละสภาพแวดล้อมได้
- เผยแพร่ส่วนประกอบของแอปพลิเคชันไปยังเว็บ ฐานข้อมูล API และบริการอื่นๆ
- แสดงข้อมูลบันทึกและแจ้งเตือนเกี่ยวกับสถานะของแต่ละเวอร์ชัน
- ตรวจสอบการเปลี่ยนแปลงโค้ดก่อนดำเนินการต่อไป เพื่อลดข้อผิดพลาดในขั้นตอนการผลิต
ตัวชี้วัดประสิทธิภาพของไปป์ไลน์ CI/CD
- รอบหรือเวลาปรับใช้: ระยะเวลาที่ใช้ในการเปลี่ยนจากขั้นตอนการสร้างไปสู่ขั้นตอนการผลิต แนวโน้มต่างๆ เผยให้เห็นจุดคอขวดในกระบวนการส่งมอบของคุณ
- ความถี่ในการใช้งาน: ความถี่ในการออกเวอร์ชันใหม่ การออกเวอร์ชันใหม่บ่อยครั้งแต่จำนวนน้อย จะช่วยลดความเสี่ยงและทำให้แก้ไขข้อผิดพลาดได้ง่ายขึ้น
- เปลี่ยนระยะเวลารอคอย: ระยะเวลาตั้งแต่เริ่มต้นการพัฒนาจนถึงการใช้งานจริงที่ประสบความสำเร็จ สะท้อนให้เห็นว่าการวางแผน การเขียนโค้ด และการส่งมอบทำงานร่วมกันได้ดีเพียงใด
- เปลี่ยนอัตราความล้มเหลว: เปอร์เซ็นต์ของการปรับใช้ที่ก่อให้เกิดเหตุการณ์ไม่คาดฝันหรือต้องยกเลิกการใช้งาน Tracks คือความปลอดภัยของท่อส่ง
- MTTR (เวลาเฉลี่ยในการฟื้นตัว): เวลาเฉลี่ยในการกู้คืนบริการหลังจากเกิดความล้มเหลว วัดความสามารถในการฟื้นตัว
- MTTF (เวลาเฉลี่ยก่อนเกิดความล้มเหลว): ระยะเวลาเฉลี่ยระหว่างความล้มเหลวแต่ละครั้ง Tracความน่าเชื่อถือในระยะยาว
