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

คำถามสัมภาษณ์งานเกี่ยวกับ CI/CD pipeline ถือเป็นหนึ่งในหัวข้อที่พบบ่อยที่สุดในกระบวนการสรรหาบุคลากร DevOps ตลอดปี 2026 โดย GitHub Actions ประมวลผลงานมากกว่า 71 ล้าน job ต่อวันและเปิดตัว การรัน step แบบขนาน ในเดือนมิถุนายน 2026, GitLab CI ที่เวอร์ชัน 19 พร้อม Secrets Manager แบบ native และ 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              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    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  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

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

Parallel Steps ใน GitHub Actions

GitHub Actions เปิดตัว การรัน step แบบขนาน เมื่อวันที่ 25 มิถุนายน 2026 ตอบสนองต่อหนึ่งในฟีเจอร์ที่มีการร้องขอมากที่สุด ก่อนหน้านี้ step ทั้งหมดภายใน job จะทำงานตามลำดับ ฟีเจอร์ใหม่นี้แนะนำ keyword สี่ตัวที่ช่วยให้ทำงานพร้อมกันได้ภายใน job เดียว

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

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

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

Keyword background: true เริ่มต้น step แบบ asynchronous และดำเนินต่อไปยัง step ถัดไปทันที Keyword wait-all หยุดการทำงานชั่วคราวจนกว่า background step ทั้งหมดจะเสร็จสิ้น Keyword parallel เป็น shorthand ที่รันหลาย step พร้อมกันและรอให้ทั้งหมดเสร็จก่อนดำเนินต่อ

มี keyword เพิ่มเติมอีกสองตัว: wait กำหนดเป้าหมายไปยัง background step เฉพาะตามชื่อ และ cancel หยุด background step อย่างสุภาพเมื่อไม่จำเป็นแล้ว (มีประโยชน์สำหรับการหยุด long-running service)

การกำหนดค่า 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                   # manual gate
  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 19.0 (พฤษภาคม 2026) เปิดตัว Secrets Manager ในรูปแบบ open beta ให้การจัดเก็บ secret แบบ native โดยไม่ต้องใช้บริการภายนอกเช่น HashiCorp Vault GitLab 19.2 (กรกฎาคม 2026) ทำให้ นโยบายการรัน pipeline ตามกำหนดเวลาพร้อมใช้งานทั่วไป ช่วยให้ทีมบังคับใช้ compliance scan หรือ dependency check ตามตารางเวลาคงที่ในหลายโปรเจกต์จากการกำหนดนโยบายเดียว

ไวยากรณ์ Jenkins Declarative Pipeline

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

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

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

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

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

        stage('Lint & Test') {
            parallel {             // parallel execution
                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 19.0 เปิดตัว Secrets Manager ช่วยให้ทีมจัดเก็บและอ้างอิง secret แบบ native โดยไม่ต้องใช้ vault ภายนอก Secret จะถูก scope ตามโปรเจกต์หรือ group และเข้าถึงได้เฉพาะ job ที่ร้องขออย่างชัดเจน

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 รองรับทั้ง parallel jobs (กลยุทธ์ matrix) และ parallel steps (keyword background/parallel) 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:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact 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 ขององค์กร

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

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

แหล่งข้อมูล

• Actions steps can now be run in parallel (GitHub Changelog, มิถุนายน 2026)
• GitLab 19.0 release notes (GitLab Docs, พฤษภาคม 2026)
• GitLab 19.2 release notes (GitLab Docs, กรกฎาคม 2026)
• Jenkins Changelog (Jenkins.io, สิงหาคม 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

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

ประเด็นสำคัญสำหรับการสัมภาษณ์ CI/CD Pipeline

• GitHub Actions parallel steps (background, wait-all, parallel) เปิดตัวในเดือนมิถุนายน 2026 ช่วยให้ทำงานพร้อมกันได้ภายใน job เดียวโดยใช้ runner, checkout และ workspace ร่วมกัน
• GitLab 19.x เปิดตัว Secrets Manager แบบ native (open beta, พฤษภาคม 2026) และทำให้นโยบายการรัน pipeline ตามกำหนดเวลาพร้อมใช้งานทั่วไป (กรกฎาคม 2026) ลดการพึ่งพาเครื่องมือภายนอก
• Jenkins 2.574+ unbundle ปลั๊กอินหลักรวมถึง JUnit และ Mailer ออกจากไฟล์ WAR ต้องติดตั้งอย่างชัดเจนสำหรับ instance ที่ไม่สามารถเข้าถึง update center
• การจัดการ secret เป็นหัวข้อด้านความปลอดภัยที่ถูกทดสอบมากที่สุดบนทั้งสามแพลตฟอร์ม: ควรแสดงความรู้เกี่ยวกับ scoped secret, protected variable และกลยุทธ์การหมุนเวียน credential
• การเพิ่มประสิทธิภาพ pipeline ผ่านการแคช การทำงานแบบขนาน และการทำงานแบบมีเงื่อนไขใช้ได้บนทุกแพลตฟอร์มและแสดงให้เห็นประสบการณ์ใช้งานจริงในระดับ production ต่อผู้สัมภาษณ์
• เตรียมการกำหนดค่า pipeline ที่ใช้งานได้จริงอย่างน้อยหนึ่งชุดต่อแพลตฟอร์ม โดยเน้นรูปแบบการใช้งานจริงแทนตัวอย่างอย่างง่าย