# Pertanyaan Wawancara CI/CD Pipeline: GitHub Actions, GitLab CI, dan Jenkins di Tahun 2026 > Kumpulan pertanyaan wawancara CI/CD pipeline beserta jawaban untuk tahun 2026. Membahas workflow GitHub Actions, pipeline GitLab CI, Jenkins declarative pipeline, dan keamanan supply chain. - Published: 2026-05-18 - Updated: 2026-05-18 - Author: SharpSkill - Tags: ci-cd, github-actions, gitlab-ci, jenkins, devops, interview - Reading time: 10 min --- Pertanyaan wawancara seputar CI/CD pipeline menjadi salah satu topik paling sering muncul dalam proses rekrutmen DevOps sepanjang tahun 2026. Dengan [GitHub Actions](https://docs.github.com/en/actions) yang kini memproses lebih dari 71 juta job per hari, [GitLab CI](https://docs.gitlab.com/ee/ci/) yang menghadirkan fitur pembuatan pipeline berbasis AI, serta [Jenkins](https://www.jenkins.io/) yang masih mempertahankan tingkat adopsi sebesar 28%, pewawancara mengharapkan kandidat mampu menunjukkan kemampuan praktis di ketiga platform tersebut. > **Fokus utama pewawancara** > > Sebagian besar pertanyaan wawancara CI/CD termasuk dalam tiga kategori: desain pipeline (cara menyusun stage dan job), keamanan (manajemen secret dan penguatan supply chain), serta troubleshooting (debugging build yang gagal dan optimasi pipeline yang lambat). Kandidat sebaiknya mempersiapkan setidaknya satu contoh konfigurasi pipeline secara langsung. ## Struktur Workflow dan Trigger pada GitHub Actions GitHub Actions mengorganisasi otomasi melalui workflow, job, dan step. Sebuah workflow merupakan file YAML yang disimpan di direktori `.github/workflows/` dan mendefinisikan kapan serta bagaimana otomasi dijalankan. Setiap workflow dapat memiliki satu atau lebih job, dan setiap job berjalan pada runner yang terpisah. Pertanyaan wawancara yang umum meminta kandidat menjelaskan hubungan antara trigger `on`, dependensi antar-job, dan keyword `needs`. ```yaml # .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 # menunggu lint selesai runs-on: ubuntu-latest strategy: matrix: node: [20, 22] # menjalankan test di kedua versi 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 # memerlukan persetujuan steps: - uses: actions/checkout@v4 - run: ./deploy.sh ``` Workflow di atas mendemonstrasikan tiga konsep penting: keyword `needs` membentuk dependency graph antar-job, strategi `matrix` memungkinkan pengujian paralel di berbagai versi Node.js, dan keyword `environment` menempatkan deployment di balik persetujuan manual. ## Konfigurasi Pipeline GitLab CI dengan Stages GitLab CI menggunakan file `.gitlab-ci.yml` pada root repository. Berbeda dengan GitHub Actions di mana job berjalan secara independen secara default, [GitLab CI mengorganisasi job ke dalam stages](https://docs.gitlab.com/ee/ci/yaml/) yang dieksekusi secara berurutan, sementara job dalam stage yang sama berjalan secara paralel. Pewawancara sering meminta kandidat untuk mengonversi workflow GitHub Actions menjadi pipeline GitLab CI, atau sebaliknya. ```yaml # .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 # gerbang manual environment: name: production url: https://app.example.com script: - ./deploy.sh ``` Perbedaan utama dengan GitHub Actions: stages mengatur urutan eksekusi secara global, keyword `parallel:matrix` menangani matrix build, dan `artifacts:reports:junit` mengintegrasikan hasil pengujian langsung ke tampilan merge request. GitLab 18.11 juga memperkenalkan [CI/CD inputs untuk pipeline merge request](https://docs.gitlab.com/releases/18/gitlab-18-11-released/), yang memungkinkan override parameter secara dinamis per pipeline run. ## Sintaks Jenkins Declarative Pipeline Jenkins menggunakan `Jenkinsfile` yang disimpan di root repository. Sintaks declarative pipeline, yang direkomendasikan sebagai standar di tahun 2026, menyediakan penanganan error yang terstruktur dan tata letak berbasis stage yang jelas. Pertanyaan wawancara yang sering muncul: jelaskan perbedaan antara declarative dan scripted pipeline, serta kapan masing-masing digunakan. ```groovy // Jenkinsfile pipeline { agent any tools { nodejs 'node-22' // dikonfigurasi di Jenkins Global Tool } environment { CI = 'true' DEPLOY_ENV = credentials('deploy-env-secret') } stages { stage('Install') { steps { sh 'npm ci' } } stage('Lint & Test') { parallel { // eksekusi paralel 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 menerapkan struktur melalui blok wajib `pipeline`, `agent`, dan `stages`. Direktif `parallel` di dalam stage menjalankan lint dan test secara bersamaan. Direktif `input` menjeda eksekusi untuk persetujuan manual, serupa dengan environment GitHub Actions dan manual gate GitLab. Perlu diperhatikan bahwa Jenkins kini membutuhkan Java 21 sejak Januari 2026, sehingga environment pipeline harus memperhitungkan dependensi runtime ini. ## Manajemen Secret di Berbagai Platform CI/CD Setiap wawancara CI/CD pasti mencakup pertanyaan tentang manajemen secret. Setiap platform menangani credential dengan cara berbeda, dan pemahaman terhadap implikasi keamanannya sangatlah penting. **GitHub Actions** menyimpan secret pada level repository, environment, atau organization. Secret secara otomatis disembunyikan dalam log, namun model scoping saat ini memiliki keterbatasan. [Roadmap keamanan 2026](https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/) memperkenalkan scoped secret yang mengikat credential ke konteks eksekusi tertentu, mengatasi risiko akses yang terlalu luas. **GitLab CI** menyediakan CI/CD variable dengan aturan proteksi. Variable yang dilindungi hanya diinjeksi ke dalam pipeline yang berjalan pada branch atau tag yang dilindungi. GitLab 18.3 menambahkan izin fine-grained untuk CI/CD job token yang menerapkan prinsip least-privilege. **Jenkins** menggunakan plugin Credentials dengan berbagai tipe credential (username/password, SSH key, secret text, sertifikat). Helper `credentials()` dalam declarative pipeline mengikat secret ke variabel environment, dan credential tingkat Folder membatasi akses ke proyek tertentu. Jawaban wawancara yang krusial: jangan pernah meng-hardcode secret dalam file pipeline, selalu gunakan manajemen secret bawaan platform, rotasi credential secara berkala, dan utamakan token berjangka pendek dibandingkan API key berjangka panjang. ## Optimasi Pipeline dan Strategi Caching Pipeline yang lambat berdampak langsung pada produktivitas developer. Pewawancara menguji apakah kandidat mampu mendiagnosis dan memperbaiki bottleneck performa dalam sistem CI/CD. Tiga teknik optimasi universal berlaku di ketiga platform: **Dependency caching** menghindari pengunduhan ulang package pada setiap run. GitHub Actions menggunakan `actions/cache` atau dukungan cache bawaan pada setup action. GitLab CI menggunakan `cache` dengan strategi key. Jenkins mengandalkan persistensi workspace atau perintah `stash`/`unstash`. **Eksekusi paralel** membagi pekerjaan ke beberapa runner. GitHub Actions menggunakan strategi `matrix`, GitLab CI menggunakan `parallel:matrix`, dan Jenkins menggunakan direktif `parallel`. Granularitas pembagian yang tepat bergantung pada proyek: terlalu banyak job paralel membuang waktu startup runner, terlalu sedikit membiarkan kapasitas tidak terpakai. **Eksekusi kondisional** melewati stage yang tidak diperlukan. Ketiga platform mendukung hal ini: GitHub Actions dengan ekspresi `if`, GitLab CI dengan `rules`, dan Jenkins dengan direktif `when`. Pipeline yang dirancang dengan baik melewati stage deployment pada feature branch dan melewati perubahan khusus lint agar tidak memicu seluruh test suite. ## Keamanan Pipeline CI/CD dan Perlindungan Supply Chain Serangan supply chain yang menargetkan sistem CI/CD meningkat secara signifikan pada tahun 2025, dengan insiden yang memengaruhi [tj-actions/changed-files dan GitHub Actions populer lainnya](https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/). Pertanyaan wawancara kini secara rutin menguji kandidat tentang strategi penguatan keamanan. Pin versi action ke commit SHA tertentu, bukan tag, untuk mencegah serangan tag-hijacking: ```yaml # .github/workflows/secure.yml steps: # Rentan: tag dapat dipindahkan ke commit berbahaya - uses: actions/checkout@v4 # Aman: di-pin ke commit SHA yang tepat - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 ``` GitLab CI menangani masalah supply chain melalui [CI/CD components dengan attestasi SLSA Level 1](https://docs.gitlab.com/ee/ci/components/) (tersedia sejak GitLab 18.1), memberikan provenance yang lebih jelas saat merangkai pipeline dari komponen yang dapat digunakan kembali. Tag container yang immutable (GitLab 18.2) mencegah penggantian image setelah dipublikasikan. Untuk Jenkins, mekanisme Shared Library sebaiknya menggunakan repository khusus dengan branch protection, persyaratan code review, dan signed commit. Komisi Eropa baru-baru ini meluncurkan [Jenkins Bug Bounty Program](https://www.jenkins.io/blog/tags/announcement/) melalui YesWeHack, mencerminkan peran kritis platform ini dalam supply chain enterprise. ## Perbandingan Lintas Platform untuk Persiapan Wawancara | Fitur | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | File konfigurasi | `.github/workflows/*.yml` | `.gitlab-ci.yml` | `Jenkinsfile` | | Model eksekusi | Berbasis job (paralel secara default) | Berbasis stage (stage berurutan) | Berbasis stage (fleksibel) | | Hosting runner | GitHub-hosted + self-hosted | GitLab.com shared + self-hosted | Self-hosted saja | | Penyimpanan secret | Secret repository/org/environment | CI/CD variable (dilindungi) | Plugin Credentials | | Matrix build | `strategy.matrix` | `parallel:matrix` | `matrix` (plugin) | | Gerbang manual | `environment` + required reviewers | `when: manual` | Direktif `input` | | Marketplace | 20.000+ Actions di Marketplace | CI/CD Components Catalog | 1.800+ plugin | | Fitur AI | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | Plugin komunitas | | Harga | Gratis untuk repo publik, per-menit untuk privat | 400 menit CI/CD gratis, lalu bertingkat | Gratis (open source), self-managed | Tabel perbandingan ini mencakup perbedaan yang paling sering diujikan dalam wawancara. Pertanyaan lanjutan yang biasanya muncul: "Platform mana yang akan dipilih untuk proyek baru, dan mengapa?" Jawabannya bergantung pada tooling yang sudah ada, ukuran tim, persyaratan compliance, dan apakah organisasi lebih memilih infrastruktur terkelola (GitHub/GitLab) atau kontrol penuh (Jenkins). Latih pertanyaan-pertanyaan ini secara langsung dengan modul wawancara [CI/CD fundamentals](/technologies/devops/interview-questions/ci-cd-fundamentals) dan [GitHub Actions](/technologies/devops/interview-questions/github-actions), atau pelajari lebih dalam pertanyaan khusus [GitLab CI](/technologies/devops/interview-questions/gitlab-ci) dan [Jenkins](/technologies/devops/interview-questions/jenkins). Untuk persiapan DevOps yang lebih luas, panduan [pertanyaan wawancara DevOps esensial](/blog/devops/essential-devops-interview-questions) mencakup cakupan topik lengkap di luar CI/CD. ## Kesimpulan - GitHub Actions unggul untuk workflow berbasis GitHub dengan ekosistem marketplace-nya dan fitur parallel steps yang akan datang, namun pin action ke commit SHA untuk memitigasi risiko supply chain - GitLab CI menyediakan integrasi paling erat antara CI/CD dan pemindaian keamanan, dengan attestasi SLSA untuk komponen dan izin fine-grained job token sejak versi 18.3 - Jenkins tetap menjadi opsi paling fleksibel untuk organisasi yang membutuhkan kontrol penuh atas infrastruktur, meskipun memerlukan Java 21 sejak Januari 2026 dan membawa beban pemeliharaan yang lebih tinggi - Manajemen secret merupakan topik keamanan yang paling sering diujikan di ketiga platform: tunjukkan pengetahuan tentang scoped secret, protected variable, dan strategi rotasi credential - Optimasi pipeline melalui caching, paralelisasi, dan eksekusi kondisional berlaku secara universal dan menandakan pengalaman produksi praktis kepada pewawancara - Persiapkan setidaknya satu konfigurasi pipeline yang berfungsi per platform, dengan fokus pada pola dunia nyata daripada contoh sederhana --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/id/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins