CI/CD Pipeline: GitHub Actions dan Jenkins

Bayangin hari Jumat, jam empat sore. Ada perbaikan kecil yang harus naik ke server sebelum akhir pekan, jadi kamu buka FileZilla, pilih file yang berubah, lalu upload satu per satu ke folder public_html. Lima menit kemudian website-nya error 500. Ternyata ada satu file yang kelupaan, dan file konfigurasi di server masih versi lama. Kamu bolak-balik membandingkan isi folder di laptop dengan isi folder di server, sementara pesan dari pengguna mulai masuk.

Kode perbaikannya sendiri sudah benar. Yang bermasalah adalah proses yang bergantung pada ingatan orang, dan proses seperti itu cepat atau lambat pasti kelewatan satu langkah. CI/CD adalah cara untuk memindahkan langkah-langkah itu ke mesin: setiap perubahan di-build, dites, dan dikirim dengan urutan yang sama, setiap kali, tanpa ada yang kelupaan. Di tulisan ini kita bahas konsepnya, lalu mempraktikkannya dengan dua alat yang paling sering kamu temui, yaitu GitHub Actions dan Jenkins.

CI, continuous delivery, dan continuous deployment

Tiga istilah ini sering dicampur, padahal artinya berbeda.

Continuous integration (CI) adalah kebiasaan menggabungkan perubahan ke branch utama sesering mungkin, dan setiap penggabungan itu otomatis di-build dan dites. Kalau tesnya merah, yang menulis perubahan langsung tahu, selagi kodenya masih segar di kepala.

Continuous delivery melanjutkan CI sampai ke tahap siap rilis. Setiap perubahan yang lolos tes otomatis dibungkus jadi artifact yang bisa di-deploy kapan saja, biasanya sudah dicoba di staging. Yang tersisa untuk naik ke produksi hanyalah satu keputusan manusia, misalnya satu tombol persetujuan.

Continuous deployment menghapus tombol terakhir itu. Perubahan yang lolos semua tahap langsung naik ke produksi tanpa campur tangan manusia. Ini butuh tes yang benar-benar bisa dipercaya, karena nggak ada lagi orang yang menahan rilis.

Kalau dirangkum, pipeline ada supaya proses rilis bisa diulang dengan hasil yang sama. Bonusnya, setiap rilis punya catatan: commit mana yang naik, siapa yang menyetujui, dan tes apa yang dijalankan.

Anatomi sebuah pipeline

Hampir semua pipeline, apa pun alatnya, tersusun dari empat bagian.

Stage adalah tahapan berurutan, misalnya build, test, scan, package, lalu deploy. Tiap stage berisi beberapa langkah, dan stage berikutnya baru jalan kalau stage sebelumnya berhasil.

Gate adalah syarat untuk lewat ke tahap berikutnya. Gate bisa otomatis (semua tes hijau, nggak ada temuan keamanan berat) atau manual (ada yang menekan tombol setuju).

Artifact adalah hasil build yang dibawa ke tahap selanjutnya, misalnya folder dist, file .jar, atau image Docker. Prinsip pentingnya adalah build sekali saja, lalu artifact yang sama itulah yang dites, dibawa ke staging, dan akhirnya di-deploy ke produksi, sehingga yang naik ke server benar-benar barang yang sudah diuji.

Environment adalah tempat artifact itu dijalankan, misalnya staging dan production. Tiap environment punya konfigurasi dan secret sendiri.

Panah balik di gambar itu sama pentingnya dengan panah maju. Begitu satu stage gagal, pipeline berhenti dan memberi tahu pembuat commit. Karena kabarnya datang beberapa menit setelah push, perbaikannya biasanya juga cepat.

GitHub Actions

GitHub Actions adalah layanan CI/CD yang menempel di GitHub. Konfigurasinya berupa file YAML di folder .github/workflows, dan mesin yang menjalankannya disediakan GitHub.

Beberapa istilah yang perlu dikenal dulu:

• Event adalah pemicu, misalnya push, pull_request, jadwal (schedule), atau tombol manual (workflow_dispatch).
• Workflow adalah satu file YAML yang berisi satu atau beberapa job.
• Job adalah sekumpulan step yang jalan di satu mesin. Job-job dalam satu workflow jalan paralel, kecuali diberi needs.
• Step adalah satu perintah shell (run) atau satu action (uses).
• Runner adalah mesin yang menjalankan job. Bisa runner milik GitHub (ubuntu-latest) atau runner yang kamu pasang sendiri.
• Action adalah langkah siap pakai buatan orang lain, misalnya actions/checkout untuk mengambil kode.
• Secret adalah nilai rahasia yang disimpan terenkripsi di pengaturan repository, lalu dipanggil dengan ${{ secrets.NAMA }}.
• Environment adalah target deploy, seperti production, yang bisa diberi aturan tambahan dan secret sendiri.

Workflow CI pertama

Misalkan kita punya aplikasi Node.js bernama toko-buku dengan script lint, test, dan build di package.json. Simpan file ini sebagai .github/workflows/ci.yml:

name: CI
 
on:
  pull_request:
  workflow_call:
 
permissions:
  contents: read
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Urutannya sama dengan yang biasa kamu ketik di laptop. actions/checkout mengambil kode, actions/setup-node memasang Node.js, lalu sisanya perintah npm biasa. npm ci dipakai alih-alih npm install karena ia memasang dependency persis sesuai package-lock.json dan gagal kalau lockfile-nya nggak cocok. Blok permissions membatasi token bawaan workflow hanya untuk membaca isi repository. Trigger workflow_call akan kita pakai nanti, supaya workflow ini bisa dipanggil dari workflow lain.

Matrix: satu job, beberapa versi

Kalau aplikasi kamu harus jalan di beberapa versi Node.js, tulis job-nya sekali dan biarkan matrix yang memperbanyaknya:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

GitHub akan membuat dua job paralel, satu untuk Node 22 dan satu untuk Node 24. Dengan fail-fast: false, job yang satu tetap dilanjutkan walaupun yang lain gagal, jadi kamu bisa melihat apakah masalahnya cuma di satu versi.

Cache

Opsi cache: npm di setup-node menyimpan cache unduhan npm berdasarkan isi package-lock.json, jadi run berikutnya nggak perlu mengunduh ulang semua paket. Untuk cache lain, pakai actions/cache. Contohnya cache build Next.js:

      - uses: actions/cache@v6
        with:
          path: .next/cache
          key: nextjs-${{ runner.os }}-${{ hashFiles('package-lock.json') }}-${{ hashFiles('src/**') }}
          restore-keys: |
            nextjs-${{ runner.os }}-${{ hashFiles('package-lock.json') }}-

key adalah kunci yang dicari persis. Kalau nggak ketemu, restore-keys dipakai untuk mengambil cache lama yang awalannya cocok, yang biasanya masih lebih baik daripada mulai dari nol. Satu repository bisa menyimpan cache sampai 10 GB, dan cache yang seminggu nggak dipakai akan dihapus.

Secret dan environment

Secret disimpan lewat Settings, lalu Secrets and variables, lalu Actions, dan nilainya otomatis disamarkan di log serta nggak bisa dibaca lagi lewat antarmuka setelah disimpan.

Environment menambahkan lapisan pengaman di atas secret. Buat environment production di Settings, lalu Environments, kemudian aktifkan Required reviewers. Job yang memakai environment itu akan berhenti dan menunggu salah satu reviewer menyetujuinya, dan secret milik environment baru bisa diakses setelah persetujuan itu. Ada juga opsi Prevent self-review supaya orang yang memicu deploy nggak bisa menyetujui deploy-nya sendiri. Satu catatan: di akun GitHub Free, environment dengan aturan seperti ini hanya tersedia untuk repository publik. Untuk repository privat, kamu butuh GitHub Pro atau Team.

Job deploy: image Docker ke GHCR, lalu ke server

Sekarang kita gabungkan semuanya. Workflow berikut jalan setiap ada push ke main, memanggil workflow CI tadi, membangun image Docker dan mengirimnya ke GitHub Container Registry (GHCR), lalu men-deploy ke server setelah disetujui. Simpan sebagai .github/workflows/deploy.yml:

name: Deploy
 
on:
  push:
    branches: [main]
 
permissions:
  contents: read
 
env:
  IMAGE: ghcr.io/contoh/toko-buku   # nama image wajib huruf kecil
 
jobs:
  ci:
    uses: ./.github/workflows/ci.yml
 
  image:
    needs: ci
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v7
      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v7
        with:
          context: .
          push: true
          tags: ${{ env.IMAGE }}:${{ github.sha }}
 
  deploy:
    needs: image
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://toko-buku.contoh.id
    concurrency: production
    steps:
      - name: Deploy lewat SSH
        env:
          SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
          KNOWN_HOSTS: ${{ secrets.DEPLOY_KNOWN_HOSTS }}
        run: |
          mkdir -p ~/.ssh
          echo "$SSH_KEY" > ~/.ssh/id_ed25519
          echo "$KNOWN_HOSTS" > ~/.ssh/known_hosts
          chmod 600 ~/.ssh/id_ed25519
          ssh deploy@toko-buku.contoh.id "/srv/toko-buku/deploy.sh $IMAGE:$GITHUB_SHA"

Beberapa hal yang sengaja diatur di situ. Job image meminta izin packages: write hanya untuk dirinya sendiri, karena cuma job itu yang perlu menulis ke GHCR. Login ke GHCR cukup memakai GITHUB_TOKEN bawaan, jadi nggak perlu membuat token pribadi. Image diberi tag berupa SHA commit, sehingga setiap image bisa dilacak ke commit asalnya, dan rollback cukup dengan men-deploy tag lama. Job deploy memakai environment production, jadi ia menunggu persetujuan reviewer. concurrency: production memastikan nggak ada dua deploy yang jalan bersamaan. Script deploy.sh di server isinya bebas, misalnya docker pull lalu docker compose up -d dengan tag yang dikirim.

Begitu jalan, halaman run di tab Actions akan menampilkan ketiga job itu berurutan. Contoh tampilannya kurang lebih seperti ini:

Reusable workflow

Job ci di atas nggak punya steps, cuma uses: ./.github/workflows/ci.yml. Itulah reusable workflow. Workflow yang dipanggil harus punya trigger workflow_call, dan pemanggilannya ditulis di level job. Workflow dari repository lain juga bisa dipanggil dengan format pemilik/repo/.github/workflows/file.yml@ref, dan untuk itu ref sebaiknya berupa SHA commit. Polanya berguna kalau kamu punya banyak repository dengan langkah CI yang sama: cukup rawat satu file.

Kesalahan yang sering terjadi

Memakai action dengan tag seperti @v7 itu praktis, tapi tag bisa dipindah oleh pemilik repository action tersebut, atau oleh siapa pun yang berhasil membobolnya. Dokumentasi keamanan GitHub menyarankan mengunci action ke SHA commit lengkap, dengan komentar versi supaya tetap terbaca:

      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

Dependabot bisa memperbarui SHA ini secara otomatis, jadi kamu nggak perlu mengeceknya manual.

Lupa menulis permissions juga sering terjadi. Tanpa blok itu, GITHUB_TOKEN mendapat izin default dari pengaturan repository atau organisasi, yang bisa saja termasuk izin menulis. Mulai dari contents: read, lalu tambahkan izin per job sesuai kebutuhan.

Soal fork, pull request dari fork nggak menerima secret, dan GITHUB_TOKEN-nya hanya bisa membaca. Pembatasan ini disengaja, karena siapa pun bisa membuat fork lalu mengirim pull request berisi kode yang mencoba membaca secret dan mengirimkannya ke server miliknya sendiri. Godaannya adalah mengganti trigger ke pull_request_target supaya secret tersedia. Trigger itu berjalan dengan hak akses repository utama, jadi jangan pernah dipakai untuk men-checkout dan menjalankan kode dari fork.

Terakhir, jangan menaruh input dari luar langsung di perintah shell, misalnya run: echo "${{ github.event.pull_request.title }}". Judul pull request bisa berisi perintah shell. Pindahkan dulu ke variabel environment (env: TITLE: ...), lalu pakai "$TITLE" di script.

Jenkins

Jenkins adalah server otomasi open source yang sudah dipakai sejak jauh sebelum GitHub Actions ada. Bedanya yang paling terasa, Jenkins kamu jalankan sendiri di server yang kamu urus sendiri, dan hampir semua fiturnya datang dari plugin yang dipasang terpisah.

Arsitektur

Controller adalah server utama Jenkins. Controller menyimpan konfigurasi, menampilkan antarmuka web, menjadwalkan build, dan menyimpan credential. Agent (di antarmuka disebut node) adalah mesin yang benar-benar menjalankan build. Setiap agent punya sejumlah executor, yaitu slot untuk menjalankan satu build sekaligus, jadi agent dengan dua executor bisa menjalankan dua build bersamaan. Plugin menambah kemampuan, mulai dari integrasi Git, Docker, sampai notifikasi.

Controller juga punya executor sendiri (built-in node), tapi dokumentasi Jenkins menyarankan nggak menjalankan build di sana. Build yang jalan di controller bisa membaca file konfigurasi dan credential milik controller.

Memasang Jenkins dengan Docker

Image resminya jenkins/jenkins, dengan tag LTS seperti lts-jdk21. Image itu belum berisi Docker CLI, jadi dokumentasi resmi menyarankan setup Docker-in-Docker: satu container docker:dind sebagai daemon, dan satu image Jenkins yang ditambah Docker CLI. Ringkasnya, buat network dan jalankan daemon-nya dulu:

docker network create jenkins
docker run --name jenkins-docker --rm --detach \
  --privileged --network jenkins --network-alias docker \
  --env DOCKER_TLS_CERTDIR=/certs \
  --volume jenkins-docker-certs:/certs/client \
  --volume jenkins-data:/var/jenkins_home \
  --publish 2376:2376 \
  docker:dind --storage-driver overlay2

Lalu buat Dockerfile untuk image Jenkins-nya:

FROM jenkins/jenkins:2.580.2-jdk21
USER root
RUN apt-get update && apt-get install -y lsb-release ca-certificates curl && \
    install -m 0755 -d /etc/apt/keyrings && \
    curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc && \
    chmod a+r /etc/apt/keyrings/docker.asc && \
    echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
    https://download.docker.com/linux/debian $(. /etc/os-release && echo \"$VERSION_CODENAME\") stable" \
    | tee /etc/apt/sources.list.d/docker.list > /dev/null && \
    apt-get update && apt-get install -y docker-ce-cli && \
    apt-get clean && rm -rf /var/lib/apt/lists/*
USER jenkins
RUN jenkins-plugin-cli --plugins "docker-workflow json-path-api"

Build dan jalankan:

docker build -t myjenkins:2.580.2-1 .
docker run --name jenkins --restart=on-failure --detach \
  --network jenkins --env DOCKER_HOST=tcp://docker:2376 \
  --env DOCKER_CERT_PATH=/certs/client --env DOCKER_TLS_VERIFY=1 \
  --publish 8080:8080 --publish 50000:50000 \
  --volume jenkins-data:/var/jenkins_home \
  --volume jenkins-docker-certs:/certs/client:ro \
  myjenkins:2.580.2-1

Buka http://localhost:8080. Jenkins akan meminta password admin awal, yang bisa kamu ambil dengan:

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Setelah itu pilih Install suggested plugins dan buat akun admin. Port 50000 hanya diperlukan kalau nanti kamu memasang agent yang terhubung ke controller.

Job Pipeline pertama dari SCM

Di Jenkins, pipeline sebaiknya ditulis di file Jenkinsfile yang ikut tersimpan di repository, bukan diketik di form web. Caranya: klik New Item, pilih Pipeline, lalu di bagian Pipeline ubah Definition menjadi Pipeline script from SCM. Pilih Git, isi URL repository, pilih credential kalau repository-nya privat, isi Branch Specifier dengan */main, dan biarkan Script Path berisi Jenkinsfile. Kalau proyekmu punya banyak branch dan pull request, jenis job Multibranch Pipeline akan membuat job otomatis untuk setiap branch yang punya Jenkinsfile.

Jenkinsfile deklaratif

Ini versi Jenkins dari pipeline toko-buku tadi:

pipeline {
    agent none
 
    options {
        timeout(time: 30, unit: 'MINUTES')
        buildDiscarder(logRotator(numToKeepStr: '20'))
        disableConcurrentBuilds()
    }
 
    triggers {
        pollSCM('H/5 * * * *')
    }
 
    environment {
        IMAGE = 'ghcr.io/contoh/toko-buku'
    }
 
    stages {
        stage('Lint dan test') {
            parallel {
                stage('Lint') {
                    agent { docker { image 'node:24-alpine' } }
                    steps {
                        sh 'npm ci'
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    agent { docker { image 'node:24-alpine' } }
                    steps {
                        sh 'npm ci'
                        sh 'npm test'
                    }
                }
            }
        }
 
        stage('Build image') {
            agent any
            environment {
                GHCR = credentials('ghcr-login')
            }
            steps {
                sh 'docker build -t $IMAGE:$BUILD_NUMBER .'
                sh 'echo $GHCR_PSW | docker login ghcr.io -u $GHCR_USR --password-stdin'
                sh 'docker push $IMAGE:$BUILD_NUMBER'
            }
        }
 
        stage('Persetujuan') {
            input {
                message 'Deploy build ini ke produksi?'
                ok 'Deploy'
                submitter 'admin,dosen'
            }
            steps {
                echo 'Deploy disetujui'
            }
        }
 
        stage('Deploy') {
            agent any
            steps {
                withCredentials([sshUserPrivateKey(credentialsId: 'server-ssh', keyFileVariable: 'SSH_KEY', usernameVariable: 'SSH_USER')]) {
                    sh 'ssh -i "$SSH_KEY" "$SSH_USER@toko-buku.contoh.id" "/srv/toko-buku/deploy.sh $IMAGE:$BUILD_NUMBER"'
                }
            }
        }
    }
 
    post {
        success {
            echo 'Pipeline selesai tanpa masalah.'
        }
        failure {
            echo 'Ada stage yang gagal, cek log-nya.'
        }
    }
}

agent none di level atas artinya pipeline nggak memegang executor apa pun secara default, dan tiap stage memilih agent-nya sendiri. Ini penting untuk stage Persetujuan. Stage dengan input bisa menunggu berjam-jam, dan kalau pipeline memegang executor selama itu, build lain ikut antre. Stage Lint dan Test jalan bersamaan di dalam blok parallel, masing-masing di container node:24-alpine (fitur ini datang dari plugin Docker Pipeline yang tadi ikut dipasang).

credentials('ghcr-login') mengambil credential bertipe Username with password yang kamu simpan di Manage Jenkins, lalu Credentials. Jenkins otomatis membuat variabel GHCR_USR dan GHCR_PSW, dan nilainya disamarkan di log. Perintah sh sengaja memakai tanda kutip tunggal, sehingga variabel $GHCR_PSW baru dibaca oleh shell saat perintah jalan dan password-nya nggak ikut tertanam di string perintah yang disusun Groovy. Untuk tipe credential lain, seperti SSH key, pakai withCredentials seperti di stage Deploy. Blok post menjalankan langkah sesuai hasil akhir, misalnya success, failure, atau always.

Kalau dibuka di Jenkins, stage-stage itu tampil berurutan, lengkap dengan durasi tiap stage:

Webhook atau polling

pollSCM('H/5 * * * *') membuat Jenkins mengecek repository kira-kira tiap lima menit. Huruf H menyebar jadwal antar-job supaya nggak semuanya mengecek di menit yang sama. Polling gampang dipasang, tapi selalu ada jeda dan membebani server Git.

Cara yang lebih rapi adalah webhook. Di job Jenkins, centang GitHub hook trigger for GITScm polling (dari plugin GitHub). Di repository GitHub, buka Settings, lalu Webhooks, dan tambahkan URL https://jenkins.kampus-kamu.id/github-webhook/ untuk event push. Syaratnya, Jenkins harus bisa dijangkau dari internet, jadi kalau Jenkins kamu cuma ada di jaringan kampus atau di laptop, polling tetap pilihan yang paling masuk akal.

Plugin dan keamanan

Hampir semua fitur Jenkins datang dari plugin, dan setiap plugin adalah kode pihak ketiga yang jalan dengan hak akses penuh di controller. Pasang seperlunya, hapus yang nggak dipakai, dan perbarui secara rutin lewat Manage Jenkins, lalu Plugins. Jenkins menampilkan peringatan kalau ada plugin terpasang yang punya celah keamanan yang sudah diumumkan, jadi jangan diabaikan.

Beberapa kebiasaan lain yang perlu dibangun sejak awal. Pakai rilis LTS. Atur jumlah executor built-in node jadi 0 setelah agent tersedia. Simpan semua password dan token sebagai credential, jangan ditulis di Jenkinsfile. Atur hak akses per pengguna, misalnya dengan plugin Matrix Authorization. Jangan membuka Jenkins ke internet tanpa HTTPS dan login.

GitHub Actions atau Jenkins

Kalau kode kamu sudah di GitHub dan proyeknya proyek kuliah, tugas akhir, atau tim kecil, GitHub Actions hampir selalu jadi pilihan paling cepat. Nggak ada server yang harus dirawat, dan pipeline-nya ikut ter-review bersama kode di pull request yang sama.

Jenkins masuk akal ketika kode tersimpan di beberapa tempat sekaligus (GitLab internal, Bitbucket, server Git kampus), ketika build harus jalan di jaringan internal yang nggak boleh dijangkau layanan luar, atau ketika organisasinya sudah punya Jenkins dengan ratusan job yang berjalan. Banyak perusahaan di Indonesia masih memakai Jenkins, jadi kemampuan membaca Jenkinsfile tetap berguna saat magang atau kerja. Harganya ada di perawatan: update controller, update plugin, dan menjaga agent tetap sehat adalah pekerjaan rutin yang harus ada pemiliknya.

Konsep yang kamu pelajari di salah satunya bisa dipakai di yang lain. Stage, gate, artifact, environment, secret, dan approval ada di keduanya dengan nama yang sedikit berbeda.

Mulai dari yang kecil

Pipeline yang berguna nggak harus langsung lengkap. Mulai dari CI yang menjalankan npm ci, lint, dan test di setiap pull request, lalu jadikan job itu wajib lulus sebelum merge lewat branch protection. Setelah tim terbiasa melihat tanda hijau dan merah, baru tambahkan build image, deploy ke staging, dan persetujuan manual untuk produksi.

Latihan kecil untuk minggu ini: ambil satu repository tugas kamu yang punya tes, tambahkan file ci.yml di atas, lalu buat pull request yang sengaja merusak satu tes. Pastikan pull request itu merah dan nggak bisa di-merge. Setelah itu perbaiki tesnya dan lihat pull request-nya berubah hijau. Kalau sempat, tulis ulang pipeline yang sama sebagai Jenkinsfile dan jalankan di Jenkins lokal, lalu bandingkan sendiri mana yang lebih nyaman untuk kebutuhanmu.