GitLab CI/CD สำหรับมือใหม่

เขียนโดย

Sirasit Boonklang

บทความนี้ตีพิมพ์ และ เผยแพร่เมื่อ 6 เมษายน 2024

Share Tweet

จากบทความก่อนหน้านี่เราได้รู้จักกับ GitLab เบื้องต้นในการเอาโค้ดขึ้นไปเก็บบน GitLab กันแล้ว สำหรับในบทความนี้เรามารู้จัก GitLab ในฝั่งของการทำหน้าที่ในงาน CI/CD กันบ้าง โดย CI/CD ย่อมาจาก Continuous Integration / Continuous Delivery เป็นแนวทางการพัฒนาซอฟต์แวร์ที่เน้นการทำงานร่วมกัน และส่งมอบงานให้ได้ไวมากยิ่งขึ้น

GitLab CI/CD ทำอะไรได้บ้าง?

GitLab CI/CD เป็นเครื่องมือที่ช่วยให้สามารถ:

รันงาน build และ test โค้ดได้อัตโนมัติ เช่น ทุกครั้งที่มีการ push โค้ดใหม่ GitLab CI/CD จะรันงาน build และ test โค้ดให้ ไม่ต้องมานั่งพิมพ์คำสั่ง build รอ… เทส รอ… หมดปัญหาเรื่องแบบนี้เพียงแค่ push ไปแล้วรอดูผลลัพธ์ นอกจากนี้ยังสามารถใช้ Deploy โค้ดไปบน production ได้ ช่วยลดเวลาและความยุ่งยากในการ deploy โค้ดไปได้เยอะ

แล้ว GitLab CI/CD มันใช้ยังไงละ?

เริ่มจากต้องมีไฟล์ .gitlab-ci.yml ก่อนเพราะไฟล์นี้คือไฟล์ที่บอกว่า GitLab CI/CD ต้องทำงานอะไรบ้าง โดยหากเรามีโปรเจกต์บน GitLab Repository อยู่แล้วให้ทำการโคลนลงมาแล้วเพิ่มไฟล์ .gitlab-ci.yml ไว้ที่ชั้นนอกสุด

ตัวอย่างโปรเจกต์ว่าง ๆ บน GitLab

ทำการโคลนลงมาแล้วเพิ่มไฟล์ .gitlab-ci.yml ไว้ที่ชั้นนอกสุด

เลือก Runners แต่ถ้าเราใช้ GitLab.com อยู่แล้ว ระบบมี Runners พื้นฐานให้ใช้เลย แต่ถ้าไม่ได้ใช้ก็ต้องสร้างหรือลงทะเบียน Runners ใน Server ของตัวเอง โดย Runners เป็นตัวประมวลผลคำสั่งต่างๆ ตามที่เราเขียนไว้ในไฟล์ .gitlab-ci.yml ตัว Runners อาจจะเป็นเครื่อง Server จริงๆ หรือ VM ก็ได้

ต่อมาเราก็ทำการเพิ่มโค้ดการทำงาน หรือที่เรียกว่า Pipeline โดย Pipeline คือลำดับขั้นตอนการทำงาน เช่น ขั้นตอนการ Build โค้ด ขั้นตอนเทส ขั้นตอน deploy โดยแต่ละขั้นตอนจะมี task ย่อยๆ เรียกว่า jobs อยู่ข้างใน

ตัวอย่าง Pipeline ง่าย ๆ สำหรับการ Demo การทำงานของ GitLab CI

สำหรับโค้ดนี้เป็นการกำหนด Pipelineใน GitLab CI/CD ซึ่ง Pipeline นี้จะมีทั้งหมด 4 งาน (job) ที่แบ่งออกเป็น 3 ขั้นตอน (stage)

รายละเอียดแต่ละส่วน

1. build-job

• stage: build : งานนี้จะรันในขั้นตอนที่ชื่อว่า “build” ซึ่งปกติเป็นขั้นตอนสำหรับ Build หรือคอมไพล์โค้ด
• script: คำสั่งที่ Jobs นี้จะต้องทำ
  • echo “Hello, $GITLAB_USER_LOGIN!” : แสดงข้อความ “Hello,” ตามด้วยชื่อผู้ที่สั่งรัน Pipeline (ชื่อผู้ใช้ GitLab) ตัวอย่างเช่น ถ้าชื่อผู้ใช้คือ ‘aef’ ก็จะแสดงเป็น “Hello, aef!”
    

2. test-job1

• stage: test : งานนี้จะรันในขั้นตอน “test” สำหรับการทดสอบโค้ด
• script:
  • echo “This job tests something” : แสดงข้อความว่างานนี้เป็นการทดสอบบางอย่าง (ในตัวอย่างนี้ไม่ได้มีคำสั่งทดสอบจริง)

3. test-job2

• stage: test : เป็น Job ที่อยู่ในขั้นตอนเดียวกับ test-job1 ดังนั้นทั้งสองงานนี้จะรันพร้อมกัน
• script:
  • echo “This job tests something, but takes more time than test-job1.” : แสดงข้อความว่างานนี้ก็ทดสอบเช่นกัน แต่อาจใช้เวลานานกว่า
  • echo “After the echo commands complete, it runs the sleep command for 20 seconds” : แจ้งว่าหลังจากแสดงข้อความเสร็จแล้วจะมีการหน่วงเวลา
  • echo “which simulates a test that runs 20 seconds longer than test-job1” : อธิบายว่าการหน่วงเวลา 20 วินาทีนี้ใช้จำลองสถานการณ์การทดสอบที่ใช้เวลานานกว่า test-job1
  • sleep 20 : คำสั่งหน่วงเวลาจริง 20 วินาที

4. deploy-prod

• stage: deploy : ขั้นตอนนี้เป็นการนำโค้ดไปใช้งาน (deploy)
• script:
  • echo “This job deploys something from the $CI_COMMIT_BRANCH branch.” : แสดงข้อความว่าขั้นตอนนี้จะ deploy โดยดึงโค้ดมาจาก branch ที่ระบุ โดยตัวแปร $CI_COMMIT_BRANCH จะเก็บชื่อ branch ที่เราส่งโค้ดขึ้นไป (commit)
• environment: production : กำหนดว่าสภาพแวดล้อมในการ deploy นี้คือ production หรือสภาวะแวดล้อมที่ใช้งานจริง

หลังจากนั้นทำการเอาโค้ดส่วนที่แก้ไขขึ้นไปยัง GitLab โดยใช้ git add, git commit, git push ตามลำดับ

เมื่อกลับไปที่ GitLab Repository จะเห็นว่า Pipeline ที่เราเพิ่งจะ Push ขึ้นไปกำลังทำงานอยู่

ให้เรามาที่ Build แล้วมาที่ Pipeline

ก็จะเห็นกระบวนการทำงานของ Pipeline โดยเราสามารถจิ้มไปที่แต่ละ Jobs เพื่อดูรายละเอียดการทำงานได้

และนี่ก็จะเป็นตัวอย่างแบบง่ายๆ สำหรับมือใหม่เพิ่งหัดจับ GitLab CI/CD ซึ่งจริง ๆ แล้วมันสามารถทำงานได้มากกว่านี้มากสามารถลุยต่อเพิ่มเติมได้ที่ ➡️ https://docs.gitlab.com/ee/ci/quick_start/tutorial.html