คำถามสัมภาษณ์งาน CI/CD Pipeline: GitHub Actions, GitLab CI และ Jenkins ปี 2026

คำถามสัมภาษณ์งานเกี่ยวกับ CI/CD pipeline ถือเป็นหนึ่งในหัวข้อที่พบบ่อยที่สุดในกระบวนการสรรหาบุคลากร DevOps ตลอดปี 2026 โดย GitHub Actions ประมวลผลงานมากกว่า 71 ล้าน job ต่อวัน, GitLab CI เปิดตัวฟีเจอร์การสร้าง pipeline ด้วย AI และ Jenkins ยังคงอัตราการใช้งานอยู่ที่ 28% ผู้สัมภาษณ์คาดหวังให้ผู้สมัครสามารถแสดงทักษะการใช้งานจริงบนทั้งสามแพลตฟอร์มได้

โครงสร้าง Workflow และ Trigger ใน GitHub Actions

GitHub Actions จัดระบบอัตโนมัติผ่าน workflow, job และ step โดย workflow คือไฟล์ YAML ที่เก็บไว้ในไดเรกทอรี .github/workflows/ ซึ่งกำหนดว่าระบบอัตโนมัติจะทำงานเมื่อใดและอย่างไร แต่ละ workflow สามารถมี job ได้หนึ่งหรือหลาย job และแต่ละ job จะทำงานบน runner ที่แยกกัน

คำถามสัมภาษณ์งานที่พบบ่อยจะขอให้ผู้สมัครอธิบายความสัมพันธ์ระหว่าง trigger on การพึ่งพาระหว่าง job และ keyword needs

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # รอให้ lint เสร็จก่อน
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # รันเทสต์บนทั้งสองเวอร์ชัน
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # ต้องได้รับการอนุมัติ
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Workflow นี้แสดงให้เห็นสามแนวคิดสำคัญ: keyword needs สร้าง dependency graph ระหว่าง job ต่างๆ, กลยุทธ์ matrix ช่วยให้ทดสอบแบบขนานบน Node.js หลายเวอร์ชัน และ keyword environment กำหนดให้การ deploy ต้องผ่านการอนุมัติด้วยตนเอง

การกำหนดค่า Pipeline ใน GitLab CI ด้วย Stages

GitLab CI ใช้ไฟล์ .gitlab-ci.yml ที่ root ของ repository ซึ่งแตกต่างจาก GitHub Actions ที่ job ทำงานแบบอิสระโดยค่าเริ่มต้น GitLab CI จัดกลุ่ม job เข้าใน stage ที่ทำงานตามลำดับ ในขณะที่ job ภายใน stage เดียวกันจะทำงานแบบขนาน

ผู้สัมภาษณ์มักขอให้ผู้สมัครแปลง workflow ของ GitHub Actions เป็น pipeline ของ GitLab CI หรือในทางกลับกัน

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # ประตูควบคุมแบบแมนนวล
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

ความแตกต่างหลักจาก GitHub Actions: stages กำหนดลำดับการทำงานทั้งระบบ, keyword parallel:matrix จัดการ matrix build และ artifacts:reports:junit รวมผลการทดสอบเข้ากับหน้า merge request โดยตรง GitLab 18.11 ยังเปิดตัว CI/CD inputs สำหรับ pipeline merge request ที่ช่วยให้กำหนดพารามิเตอร์แบบไดนามิกส์ได้ในแต่ละรอบการรัน pipeline

ไวยากรณ์ Jenkins Declarative Pipeline

Jenkins ใช้ Jenkinsfile ที่เก็บไว้ที่ root ของ repository โดยไวยากรณ์ declarative pipeline ซึ่งเป็นมาตรฐานที่แนะนำในปี 2026 มอบการจัดการข้อผิดพลาดที่มีโครงสร้างชัดเจนและรูปแบบตาม stage ที่ชัดเจน

คำถามสัมภาษณ์ที่พบบ่อย: อธิบายความแตกต่างระหว่าง declarative และ scripted pipeline และเมื่อไรควรใช้แต่ละแบบ

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // กำหนดค่าใน Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // ทำงานแบบขนาน
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}

Declarative pipeline บังคับโครงสร้างผ่านบล็อกที่จำเป็นได้แก่ pipeline, agent และ stages คำสั่ง parallel ภายใน stage จะรัน lint และ test พร้อมกัน คำสั่ง input หยุดการทำงานชั่วคราวเพื่อรอการอนุมัติด้วยตนเอง คล้ายกับ environment ของ GitHub Actions และ manual gate ของ GitLab ทั้งนี้ Jenkins ยังกำหนดให้ใช้ Java 21 ตั้งแต่เดือนมกราคม 2026 ดังนั้นสภาพแวดล้อมของ pipeline ต้องคำนึงถึงความต้องการ runtime นี้ด้วย

การจัดการ Secret บนแพลตฟอร์ม CI/CD ต่างๆ

ทุกการสัมภาษณ์งาน CI/CD จะมีคำถามเกี่ยวกับการจัดการ secret อยู่เสมอ แต่ละแพลตฟอร์มจัดการข้อมูลประจำตัวแตกต่างกัน และการเข้าใจผลกระทบด้านความปลอดภัยถือเป็นสิ่งสำคัญ

GitHub Actions เก็บ secret ในระดับ repository, environment หรือ organization โดย secret จะถูกซ่อนจาก log โดยอัตโนมัติ แต่รูปแบบ scoping ปัจจุบันยังมีข้อจำกัด แผนงานด้านความปลอดภัยปี 2026 ได้เปิดตัว scoped secret ที่ผูกข้อมูลประจำตัวกับบริบทการทำงานเฉพาะ ลดความเสี่ยงจากสิทธิ์การเข้าถึงที่กว้างเกินไป

GitLab CI มอบ CI/CD variable พร้อมกฎการป้องกัน โดยตัวแปรที่ถูกป้องกันจะถูก inject เข้าไปใน pipeline ที่รันบน branch หรือ tag ที่ได้รับการป้องกันเท่านั้น GitLab 18.3 เพิ่มสิทธิ์แบบ fine-grained สำหรับ CI/CD job token โดยใช้หลักการ least-privilege

Jenkins ใช้ปลั๊กอิน Credentials ที่รองรับข้อมูลประจำตัวหลายรูปแบบ (username/password, SSH key, secret text, ใบรับรอง) helper credentials() ใน declarative pipeline จะผูก secret กับตัวแปรสภาพแวดล้อม และ credential ระดับ Folder จำกัดสิทธิ์การเข้าถึงเฉพาะโปรเจกต์

คำตอบสัมภาษณ์ที่สำคัญ: ห้าม hardcode secret ในไฟล์ pipeline โดยเด็ดขาด ใช้ระบบจัดการ secret ดั้งเดิมของแพลตฟอร์มเสมอ หมุนเวียน credential อย่างสม่ำเสมอ และเลือกใช้ token ระยะสั้นแทน API key ระยะยาว

การเพิ่มประสิทธิภาพ Pipeline และกลยุทธ์การแคช

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

เทคนิคการเพิ่มประสิทธิภาพที่ใช้ได้ทั่วไปบนทั้งสามแพลตฟอร์มมีสามวิธี:

Dependency caching หลีกเลี่ยงการดาวน์โหลด package ซ้ำในทุกรอบการรัน GitHub Actions ใช้ actions/cache หรือการรองรับแคชที่มีมาใน setup action GitLab CI ใช้ cache พร้อมกลยุทธ์ key Jenkins อาศัยการคงอยู่ของ workspace หรือคำสั่ง stash/unstash

การทำงานแบบขนาน แบ่งงานไปยังหลาย runner GitHub Actions ใช้กลยุทธ์ matrix, GitLab CI ใช้ parallel:matrix และ Jenkins ใช้คำสั่ง parallel ระดับความละเอียดของการแบ่งงานที่เหมาะสมขึ้นอยู่กับโปรเจกต์: job ขนานมากเกินไปจะเสียเวลาเริ่มต้น runner แต่น้อยเกินไปจะทำให้ทรัพยากรเหลือใช้

การทำงานแบบมีเงื่อนไข ข้าม stage ที่ไม่จำเป็น ทั้งสามแพลตฟอร์มรองรับ: GitHub Actions ด้วยนิพจน์ if, GitLab CI ด้วย rules และ Jenkins ด้วยคำสั่ง when Pipeline ที่ออกแบบมาดีจะข้าม stage deployment บน feature branch และข้ามการเปลี่ยนแปลงเฉพาะ lint ไม่ให้รัน test suite ทั้งหมด

ความปลอดภัย Pipeline CI/CD และการป้องกัน Supply Chain

การโจมตี supply chain ที่พุ่งเป้าระบบ CI/CD เพิ่มขึ้นอย่างมากในปี 2025 โดยมีเหตุการณ์ที่ส่งผลกระทบต่อ tj-actions/changed-files และ GitHub Actions ยอดนิยมอื่นๆ คำถามสัมภาษณ์ในปัจจุบันจึงทดสอบผู้สมัครเกี่ยวกับกลยุทธ์การเสริมความแข็งแกร่งเป็นประจำ

ตรึงเวอร์ชันของ action ด้วย commit SHA เฉพาะแทน tag เพื่อป้องกันการโจมตีแบบ tag-hijacking:

# .github/workflows/secure.yml
steps:
  # เสี่ยง: tag สามารถถูกย้ายไปยัง commit ที่เป็นอันตราย
  - uses: actions/checkout@v4

  # ปลอดภัย: ตรึงด้วย commit SHA ที่แน่นอน
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

GitLab CI จัดการปัญหา supply chain ผ่าน CI/CD components พร้อมการรับรอง SLSA Level 1 (มีให้ใช้ตั้งแต่ GitLab 18.1) ซึ่งมอบแหล่งที่มาที่ชัดเจนยิ่งขึ้นเมื่อประกอบ pipeline จาก component ที่ใช้ซ้ำได้ container tag แบบ immutable (GitLab 18.2) ป้องกันการเปลี่ยน image หลังเผยแพร่แล้ว

สำหรับ Jenkins กลไก Shared Library ควรใช้ repository เฉพาะที่มี branch protection การกำหนดให้มี code review และ signed commit คณะกรรมาธิการยุโรปได้เปิดตัวโครงการ Bug Bounty สำหรับ Jenkins ผ่าน YesWeHack เมื่อไม่นานมานี้ สะท้อนให้เห็นถึงบทบาทสำคัญของแพลตฟอร์มนี้ใน supply chain ขององค์กร

ตารางเปรียบเทียบข้ามแพลตฟอร์มสำหรับการเตรียมสัมภาษณ์

| คุณสมบัติ | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | ไฟล์กำหนดค่า | .github/workflows/*.yml | .gitlab-ci.yml | Jenkinsfile | | รูปแบบการทำงาน | ตาม job (ขนานโดยค่าเริ่มต้น) | ตาม stage (stage ตามลำดับ) | ตาม stage (ยืดหยุ่น) | | Runner hosting | GitHub-hosted + self-hosted | GitLab.com shared + self-hosted | Self-hosted เท่านั้น | | การเก็บ secret | Secret ระดับ repository/org/environment | CI/CD variable (มีการป้องกัน) | ปลั๊กอิน Credentials | | Matrix build | strategy.matrix | parallel:matrix | matrix (ปลั๊กอิน) | | ประตูแมนนวล | environment + required reviewers | when: manual | คำสั่ง input | | Marketplace | 20,000+ Actions บน Marketplace | CI/CD Components Catalog | 1,800+ ปลั๊กอิน | | ฟีเจอร์ AI | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | ปลั๊กอินจากชุมชน | | ราคา | ฟรีสำหรับ repo สาธารณะ, คิดตามนาทีสำหรับ repo ส่วนตัว | 400 นาที CI/CD ฟรี, จากนั้นเป็นขั้นบันได | ฟรี (โอเพนซอร์ส), ดูแลเอง |

ตารางเปรียบเทียบนี้ครอบคลุมความแตกต่างที่มักถูกทดสอบบ่อยที่สุดในการสัมภาษณ์ คำถามต่อยอดที่มักตามมาคือ: "จะเลือกแพลตฟอร์มใดสำหรับโปรเจกต์ใหม่ และเพราะอะไร?" คำตอบขึ้นอยู่กับเครื่องมือที่มีอยู่ ขนาดทีม ข้อกำหนดด้าน compliance และว่าองค์กรต้องการโครงสร้างพื้นฐานแบบจัดการให้ (GitHub/GitLab) หรือควบคุมทั้งหมด (Jenkins)

ฝึกฝนคำถามเหล่านี้ด้วยโมดูลสัมภาษณ์ CI/CD fundamentals และ GitHub Actions หรือศึกษาเพิ่มเติมกับคำถามเฉพาะของ GitLab CI และ Jenkins สำหรับการเตรียมตัว DevOps ที่ครอบคลุมยิ่งขึ้น คู่มือคำถามสัมภาษณ์งาน DevOps ที่จำเป็นครอบคลุมหัวข้อทั้งหมดนอกเหนือจาก CI/CD

สรุป

• GitHub Actions โดดเด่นสำหรับ workflow ที่ใช้งานกับ GitHub โดยตรงด้วยระบบนิเวศ marketplace และฟีเจอร์ parallel steps ที่กำลังจะมา แต่ควรตรึง action ด้วย commit SHA เพื่อลดความเสี่ยงจาก supply chain
• GitLab CI มอบการรวม CI/CD และการสแกนความปลอดภัยที่แน่นแฟ้นที่สุด พร้อมการรับรอง SLSA สำหรับ component และสิทธิ์ fine-grained job token ตั้งแต่เวอร์ชัน 18.3
• Jenkins ยังคงเป็นตัวเลือกที่ยืดหยุ่นที่สุดสำหรับองค์กรที่ต้องการควบคุมโครงสร้างพื้นฐานทั้งหมด แม้ว่าจะต้องการ Java 21 ตั้งแต่เดือนมกราคม 2026 และมีภาระการดูแลที่สูงกว่า
• การจัดการ secret เป็นหัวข้อด้านความปลอดภัยที่ถูกทดสอบมากที่สุดบนทั้งสามแพลตฟอร์ม: ควรแสดงความรู้เกี่ยวกับ scoped secret, protected variable และกลยุทธ์การหมุนเวียน credential
• การเพิ่มประสิทธิภาพ pipeline ผ่านการแคช การทำงานแบบขนาน และการทำงานแบบมีเงื่อนไขใช้ได้บนทุกแพลตฟอร์มและแสดงให้เห็นประสบการณ์ใช้งานจริงในระดับ production ต่อผู้สัมภาษณ์
• เตรียมการกำหนดค่า pipeline ที่ใช้งานได้จริงอย่างน้อยหนึ่งชุดต่อแพลตฟอร์ม โดยเน้นรูปแบบการใช้งานจริงแทนตัวอย่างอย่างง่าย