Câu Hỏi Phỏng Vấn CI/CD Pipeline: GitHub Actions, GitLab CI và Jenkins Năm 2026

Câu hỏi phỏng vấn về CI/CD pipeline là một trong những chủ đề xuất hiện thường xuyên nhất trong các vòng tuyển dụng DevOps năm 2026. Với GitHub Actions hiện xử lý hơn 71 triệu job mỗi ngày, GitLab CI ra mắt tính năng tạo pipeline bằng AI, và Jenkins vẫn duy trì tỷ lệ sử dụng 28%, nhà tuyển dụng mong đợi ứng viên thể hiện được khả năng thực hành trên cả ba nền tảng.

Cấu Trúc Workflow và Trigger Trong GitHub Actions

GitHub Actions tổ chức tự động hóa xoay quanh workflow, job và step. Một workflow là file YAML được lưu trong thư mục .github/workflows/, định nghĩa thời điểm và cách thức tự động hóa được chạy. Mỗi workflow chứa một hoặc nhiều job, và mỗi job chạy trên một runner riêng biệt.

Câu hỏi phỏng vấn phổ biến yêu cầu ứng viên giải thích mối quan hệ giữa trigger on, sự phụ thuộc giữa các job và 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              # chờ lint hoàn thành
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # chạy test trên cả hai phiên bản
    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  # yêu cầu phê duyệt
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Workflow trên minh họa ba khái niệm quan trọng: keyword needs tạo ra dependency graph giữa các job, chiến lược matrix cho phép kiểm thử song song trên nhiều phiên bản Node.js, và keyword environment đặt deployment sau cổng phê duyệt thủ công.

Cấu Hình Pipeline GitLab CI Với Stages

GitLab CI sử dụng file .gitlab-ci.yml tại thư mục gốc của repository. Khác với GitHub Actions nơi các job chạy độc lập theo mặc định, GitLab CI tổ chức job thành các stage thực thi tuần tự, trong khi các job trong cùng stage chạy song song.

Nhà tuyển dụng thường yêu cầu ứng viên chuyển đổi workflow GitHub Actions sang pipeline GitLab CI, hoặc ngược lại.

# .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                   # cổng kiểm soát thủ công
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

Những điểm khác biệt chính so với GitHub Actions: stages quy định thứ tự thực thi toàn cục, keyword parallel:matrix xử lý matrix build, và artifacts:reports:junit tích hợp kết quả kiểm thử trực tiếp vào giao diện merge request. GitLab 18.11 cũng giới thiệu CI/CD inputs cho pipeline merge request, cho phép ghi đè tham số động theo từng lần chạy pipeline.

Cú Pháp Jenkins Declarative Pipeline

Jenkins sử dụng Jenkinsfile được lưu tại thư mục gốc của repository. Cú pháp declarative pipeline, được khuyến nghị làm mặc định trong năm 2026, cung cấp xử lý lỗi có cấu trúc và bố cục dựa trên stage rõ ràng.

Câu hỏi phỏng vấn thường gặp: giải thích sự khác biệt giữa declarative và scripted pipeline, và khi nào sử dụng từng loại.

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // cấu hình trong Jenkins Global Tool
    }

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

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

        stage('Lint & Test') {
            parallel {             // thực thi song song
                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 áp dụng cấu trúc thông qua các khối bắt buộc pipeline, agent và stages. Chỉ thị parallel bên trong stage chạy lint và test đồng thời. Chỉ thị input tạm dừng thực thi để chờ phê duyệt thủ công, tương tự environment của GitHub Actions và manual gate của GitLab. Cần lưu ý rằng Jenkins hiện yêu cầu Java 21 kể từ tháng 1 năm 2026, do đó môi trường pipeline cần tính đến phụ thuộc runtime này.

Quản Lý Secret Trên Các Nền Tảng CI/CD

Mọi buổi phỏng vấn CI/CD đều bao gồm câu hỏi về quản lý secret. Mỗi nền tảng xử lý thông tin xác thực theo cách khác nhau, và việc hiểu rõ các hàm ý bảo mật là rất quan trọng.

GitHub Actions lưu trữ secret ở cấp repository, environment hoặc organization. Secret được tự động ẩn khỏi log, nhưng mô hình scoping hiện tại có những hạn chế. Lộ trình bảo mật 2026 giới thiệu scoped secret ràng buộc thông tin xác thực vào ngữ cảnh thực thi cụ thể, giải quyết rủi ro truy cập quá rộng.

GitLab CI cung cấp CI/CD variable với quy tắc bảo vệ. Biến được bảo vệ chỉ được inject vào pipeline chạy trên branch hoặc tag được bảo vệ. GitLab 18.3 bổ sung quyền fine-grained cho CI/CD job token, áp dụng nguyên tắc least-privilege.

Jenkins sử dụng plugin Credentials với nhiều loại thông tin xác thực (username/password, SSH key, secret text, chứng chỉ). Helper credentials() trong declarative pipeline gắn secret vào biến môi trường, và credential cấp Folder giới hạn quyền truy cập theo dự án cụ thể.

Câu trả lời phỏng vấn then chốt: không bao giờ hardcode secret trong file pipeline, luôn sử dụng hệ thống quản lý secret nguyên bản của nền tảng, xoay vòng credential thường xuyên, và ưu tiên token ngắn hạn thay vì API key dài hạn.

Tối Ưu Pipeline và Chiến Lược Caching

Pipeline chạm ảnh hưởng trực tiếp đến năng suất của lập trình viên. Nhà tuyển dụng kiểm tra xem ứng viên có khả năng chẩn đoán và khắc phục điểm nghẽ cổ chai hiệu năng trong hệ thống CI/CD hay không.

Ba kỹ thuật tối ưu phổ quát áp dụng trên cả ba nền tảng:

Dependency caching tránh tải lại package mỗi lần chạy. GitHub Actions sử dụng actions/cache hoặc hỗ trợ cache tích hợp trong setup action. GitLab CI sử dụng cache với chiến lược key. Jenkins dựa vào tính bền vững của workspace hoặc lệnh stash/unstash.

Thực thi song song chia công việc cho nhiều runner. GitHub Actions sử dụng chiến lược matrix, GitLab CI sử dụng parallel:matrix, và Jenkins sử dụng chỉ thị parallel. Mức độ chia phù hợp phụ thuộc vào dự án: quá nhiều job song song gây lãng phí thời gian khởi động runner, quá ít thì bỏ phí tài nguyên.

Thực thi có điều kiện bỏ qua các stage không cần thiết. Cả ba nền tảng đều hỗ trợ: GitHub Actions với biểu thức if, GitLab CI với rules, và Jenkins với chỉ thị when. Pipeline được thiết kế tốt sẽ bỏ qua stage deployment trên feature branch và bỏ qua thay đổi chỉ liên quan đến lint để không kích hoạt toàn bộ test suite.

Bảo Mật Pipeline CI/CD và Bảo Vệ Supply Chain

Các cuộc tấn công supply chain nhắm vào hệ thống CI/CD gia tăng đáng kể trong năm 2025, với các sự cố ảnh hưởng đến tj-actions/changed-files và các GitHub Actions phổ biến khác. Câu hỏi phỏng vấn hiện nay thường xuyên kiểm tra ứng viên về chiến lược củng cố bảo mật.

Ghim phiên bản action theo commit SHA cụ thể thay vì tag để ngăn chặn tấn công tag-hijacking:

# .github/workflows/secure.yml
steps:
  # Dễ bị tấn công: tag có thể được chuyển sang commit độc hại
  - uses: actions/checkout@v4

  # An toàn: ghim vào commit SHA chính xác
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

GitLab CI giải quyết vấn đề supply chain thông qua CI/CD components với chứng nhận SLSA Level 1 (có sẵn từ GitLab 18.1), cung cấp nguồn gốc rõ ràng hơn khi lắp ráp pipeline từ các component tái sử dụng. Tag container bất biến (GitLab 18.2) ngăn chặn việc thay thế image sau khi đã xuất bản.

Với Jenkins, cơ chế Shared Library nên sử dụng repository chuyên dụng với branch protection, yêu cầu code review và signed commit. Ủy ban Châu Âu gần đây đã khởi động Chương trình Bug Bounty cho Jenkins thông qua YesWeHack, phản ánh vai trò quan trọng của nền tảng này trong supply chain doanh nghiệp.

So Sánh Đa Nền Tảng Để Chuẩn Bị Phỏng Vấn

| Tính năng | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | File cấu hình | .github/workflows/*.yml | .gitlab-ci.yml | Jenkinsfile | | Mô hình thực thi | Dựa trên job (song song mặc định) | Dựa trên stage (stage tuần tự) | Dựa trên stage (linh hoạt) | | Runner hosting | GitHub-hosted + self-hosted | GitLab.com shared + self-hosted | Chỉ self-hosted | | Lưu trữ secret | Secret repository/org/environment | CI/CD variable (được bảo vệ) | Plugin Credentials | | Matrix build | strategy.matrix | parallel:matrix | matrix (plugin) | | Cổng thủ công | environment + required reviewers | when: manual | Chỉ thị input | | Marketplace | 20.000+ Actions trên Marketplace | CI/CD Components Catalog | 1.800+ plugin | | Tính năng AI | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | Plugin cộng đồng | | Giá | Miễn phí cho repo công khai, tính theo phút cho riêng tư | 400 phút CI/CD miễn phí, sau đó theo bậc | Miễn phí (mã nguồn mở), tự quản lý |

Bảng so sánh này bao gồm những điểm khác biệt thường được kiểm tra nhất trong phỏng vấn. Câu hỏi tiếp theo thường là: "Nền tảng nào sẽ được chọn cho dự án mới, và tại sao?" Câu trả lời phụ thuộc vào công cụ hiện có, quy mô đội ngũ, yêu cầu tuân thủ, và việc tổ chức ưu tiên hạ tầng quản lý (GitHub/GitLab) hay kiểm soát toàn diện (Jenkins).

Luyện tập các câu hỏi này thực tế với module phỏng vấn CI/CD fundamentals và GitHub Actions, hoặc tìm hiểu sâu hơn về câu hỏi cụ thể cho GitLab CI và Jenkins. Để chuẩn bị DevOps toàn diện hơn, hướng dẫn câu hỏi phỏng vấn DevOps thiết yếu bao gồm đầy đủ các chủ đề ngoài CI/CD.

Kết Luận

• GitHub Actions vượt trội cho workflow tích hợp GitHub với hệ sinh thái marketplace và tính năng parallel steps sắp ra mắt, nhưng cần ghim action theo commit SHA để giảm thiểu rủi ro supply chain
• GitLab CI cung cấp tích hợp chặt chẽ nhất giữa CI/CD và quét bảo mật, với chứng nhận SLSA cho component và quyền fine-grained job token từ phiên bản 18.3
• Jenkins vẫn là lựa chọn linh hoạt nhất cho tổ chức cần kiểm soát toàn bộ hạ tầng, dù yêu cầu Java 21 từ tháng 1 năm 2026 và đòi hỏi chi phí bảo trì cao hơn
• Quản lý secret là chủ đề bảo mật được kiểm tra nhiều nhất trên cả ba nền tảng: cần thể hiện kiến thức về scoped secret, protected variable và chiến lược xoay vòng credential
• Tối ưu pipeline thông qua caching, thực thi song song và thực thi có điều kiện áp dụng được trên mọi nền tảng và cho thấy kinh nghiệm sản xuất thực tế với nhà tuyển dụng
• Chuẩn bị ít nhất một cấu hình pipeline hoạt động cho mỗi nền tảng, tập trung vào các mẫu thực tế thay vì ví dụ đơn giản