Belajar DevOps Engineer - Continuous Integration (CI)

#Pendahuluan

Di episode 4 kita belajar bahwa setiap perubahan masuk melalui Pull Request dan harus melewati gerbang kualitas. Tapi siapa yang menjalankan gerbang itu? Jawabannya: Continuous Integration (CI). CI adalah otomasi yang mengeksekusi build, test, dan linting setiap kali ada perubahan kode — otomatis, konsisten, dan tanpa menunggu manusia.

Mengapa CI adalah fondasi DevOps? Karena ia menjawab masalah klasik yang dikenal sebagai "works on my machine". CI memindahkan verifikasi dari laptop pribadi ke mesin yang bersih dan terstandar. Setiap commit menjadi kandidat rilis yang terbukti lolos uji — dan di episode 6, CI ini akan dilanjutkan menjadi Continuous Delivery.

#Filosofi Continuous Integration

Martin Fowler mendefinisikan CI singkat: integrasikan kode secara terus-menerus ke dalam trunk, dan verifikasi setiap integrasi secara otomatis. Empat pilar yang wajib kalian pegang:

1. Merge kecil & sering — semakin lama sebuah branch hidup, semakin besar konflik dan risiko.
2. Build otomatis di mesin bersih — CI server tidak boleh menumpuk cache kotor dari laptop.
3. Test otomatis berjalan setiap kali — unit, integration, dan lint; semuanya tanpa campur tangan manusia.
4. Fail fast — pipeline harus berhenti di langkah yang gagal agar perbaikan cepat.

Hasilnya: commit ke main selalu dalam keadaan hijau (green). Kode rusak tidak pernah sempat mendarat di main — ia sudah tertahan di CI.

#Komponen Pipeline CI

Pipeline CI tipikal memiliki empat tahap:

stages:
  - install
  - lint
  - test
  - build

Jika semua tahap hijau, pipeline menghasilkan artifact — produk nyata yang bisa dirilis. Artifact inilah yang akan kalian kelola lebih serius di episode 17.

#Memilih Tool CI

Ada tiga tool yang dominan di industri, dan ketiganya mengikuti pola yang sama: konfigurasi sebagai file dalam Git (pipeline-as-code).

#GitHub Actions

Pipeline didefinisikan dalam .github/workflows/*.yml. Sangat terintegrasi dengan GitHub, populer di komunitas open source, dan marketplace action-nya luas:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run lint
      - run: npm test

#GitLab CI

Pipeline didefinisikan dalam .gitlab-ci.yml, dikenal dengan konsep runners (eksekutor build) yang bisa self-hosted:

stages: [test, build]
test:
  stage: test
  image: node:22
  script:
    - npm ci
    - npm run lint
    - npm test
build:
  stage: build
  image: node:22
  script:
    - npm run build
  artifacts:
    paths: [dist/]

#Jenkins

Jenkins adalah veteran yang fleksibel dan bisa dikonfigurasi lewat UI atau Jenkinsfile (Groovy). Keunggulannya: ekosistem plugin raksasa dan kontrol granular. Kekurangannya: mengelola Jenkins server sendiri menambah beban operasional — kebalikan dari SaaS CI.

#Praktik: Pipeline CI untuk Aplikasi

Mari terapkan pada aplikasi Node.js sederhana. Alur lengkapnya: install → lint → test → build → simpan artifact.

name: CI
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-node@v4
        with:
          node-version: 22
 
      - name: Install dependencies
        run: npm ci
 
      - name: Lint
        run: npm run lint
 
      - name: Run tests
        run: npm test
 
      - name: Build
        run: npm run build
 
      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/

Perhatikan dua hal penting: on: pull_request membuat CI otomatis berjalan di setiap PR (gerbang review dari episode 4), dan actions/upload-artifact menyimpan hasil build agar bisa diunduh atau diteruskan ke tahap CD.

Untuk menguji, kalian bisa mengupload file ini ke repository dan memecahkan test secara sengaja untuk melihat pipeline berubah merah — cara terbaik memahami fail fast.

#Manfaat dan Pitfall

Manfaat yang bisa kalian rasakan langsung:

• Feedback dalam menit, bukan hari — bug tertangkap sebelum dirilis.
• Standard environment untuk semua developer — tidak ada lagi "works on my machine".
• Artifact siap rilis selalu tersedia di setiap commit hijau.
• Basis untuk CD (episode 6) dan security scanning (episode 18).

Pitfall umum:

• Pipeline terlalu lambat — kalian akan malas menunggu; episode 21 membahas caching dan paralelisme.
• Test yang flaky — pipeline kadang hijau kadang merah merusak kepercayaan; buat test deterministik.
• Menaruh rahasia di konfigurasi — jangan pernah; kita pecahkan dengan secrets di episode 16.
• Build hanya di laptop — CI wajib jadi satu-satunya sumber kebenaran build.

#Penutup

Inti yang harus dibawa pulang:

• CI = integrasi terus-menerus + verifikasi otomatis untuk setiap commit.
• Empat tahap inti: install, lint, test, build; hasil akhirnya artifact.
• GitHub Actions, GitLab CI, dan Jenkins adalah tiga tool dominan — pipeline-as-code adalah standar.
• CI yang hijau adalah prasyarat sebelum kode masuk main dan sebelum CD mengambil alih.

Di episode 6 selanjutnya kita membahas Continuous Delivery & Deployment (CD) — bagaimana artifact yang lolos CI diteruskan ke environment dev, staging, dan produksi dengan strategi deployment yang aman: blue-green, canary, dan rolling. Di sinilah alur "kode → produksi" menjadi otomatis penuh.