Menyiapkan Pipeline CI/CD Pertama Anda: Otomatiskan Build, Tes, dan Deploy

Di dua artikel sebelumnya, kita membahas mengapa source code mentah tak boleh langsung diunggah, lalu menyusun daftar periksa panjang tentang apa saja yang perlu dicek sebelum naik ke produksi. Pertanyaan yang wajar muncul berikutnya: apakah semua pemeriksaan itu harus dilakukan manual setiap kali rilis?

Jawabannya tidak. Di sinilah CI/CD masuk. Sebuah pipeline CI/CD mengubah rangkaian langkah manual yang membosankan dan rawan lupa itu menjadi proses otomatis yang berjalan sendiri setiap kali Anda mengirim kode. Artikel ini — bagian ketiga dari seri deployment Yowisben — mengajak Anda menyiapkan pipeline pertama dengan bahasa yang ramah pemula.

📚 Seri Deployment Yowisben — baca berurutan:

1. Mengapa Source Code Mentah Tidak Boleh Langsung Diunggah
2. Apa yang Perlu Diperiksa Sebelum Naik ke Produksi
3. Menyiapkan Pipeline CI/CD Pertama Anda ← Anda di sini
4. Strategi Rollback & Zero-Downtime Deployment

Apa itu CI/CD, singkatnya

CI/CD adalah singkatan dari Continuous Integration dan Continuous Delivery/Deployment. Kedengarannya rumit, tapi idenya sederhana.

Continuous Integration (CI) berarti setiap kali Anda mengirim (push) perubahan kode ke repository, sistem otomatis langsung menggabungkannya, membangunnya (build), dan mengujinya. Tujuannya menangkap masalah sedini mungkin, bukan menunggu sampai hari rilis.

Continuous Delivery/Deployment (CD) adalah kelanjutannya: setelah kode lolos uji, sistem otomatis menyiapkan — dan bila Anda mau, langsung menayangkan — versi baru ke server. Delivery berarti siap tayang dengan satu persetujuan; deployment berarti tayang sepenuhnya otomatis.

Analogi sederhananya: bayangkan sebuah ban berjalan di pabrik. Anda menaruh bahan mentah (kode) di ujung satu, dan di ujung lain keluar produk jadi yang sudah diperiksa dan dikemas (aplikasi yang tayang) — tanpa Anda menyentuh setiap tahap secara manual.

Kenapa repot menyiapkan pipeline?

Kalau Anda selama ini menayangkan dengan cara manual dan merasa "baik-baik saja", manfaat berikut mungkin mengubah pikiran Anda.

• Menghilangkan kesalahan manusia. Tidak ada lagi "lupa menjalankan tes" atau "tidak sengaja mengunggah file .env". Pipeline menjalankan langkah yang sama, persis, setiap kali.
• Rilis jadi cepat dan sering. Karena prosesnya otomatis, menayangkan perbaikan kecil tidak lagi terasa seperti operasi besar.
• Umpan balik cepat. Bila ada tes yang gagal, Anda tahu dalam hitungan menit setelah push, bukan setelah pengguna mengeluh.
• Riwayat yang jelas. Setiap rilis tercatat — versi mana, kapan, oleh siapa — sehingga mudah dilacak dan diputar balik.

Ingat. Pipeline CI/CD pada dasarnya adalah checklist dari artikel sebelumnya yang diubah menjadi kode. Semua yang tadinya Anda periksa dengan tangan kini dijalankan mesin secara konsisten.

Anatomi sebuah pipeline

Hampir semua pipeline, sesederhana apa pun, terdiri dari tahapan (stages) yang berjalan berurutan. Bila satu tahap gagal, pipeline berhenti dan tidak melanjutkan ke tahap berikutnya.

1. Pemicu (trigger). Apa yang memulai pipeline — biasanya sebuah push ke branch tertentu, atau pembukaan pull request.
2. Build. Mengambil kode, memasang dependensi, lalu membangun aplikasi menjadi artefak siap pakai.
3. Test. Menjalankan rangkaian pengujian — unit, integrasi — dan audit keamanan. Ini penjaga gerbang utama.
4. Deploy. Bila semua tahap sebelumnya lolos, menayangkan hasil build ke server, sering kali ke staging dulu, baru produksi.

Contoh nyata: pipeline dengan GitHub Actions

Salah satu cara termudah memulai adalah GitHub Actions, karena terintegrasi langsung dengan repository GitHub dan gratis untuk penggunaan wajar. Anda cukup membuat berkas di dalam folder .github/workflows/ pada proyek Anda.

Berikut contoh pipeline sederhana untuk aplikasi berbasis Node yang menjalankan build, tes, lalu menayangkan:

name: Deploy ke Produksi

# Pemicu: setiap push ke branch main
on:
  push:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Ambil kode
        uses: actions/checkout@v4

      - name: Siapkan Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Pasang dependensi
        run: npm ci

      - name: Audit keamanan
        run: npm audit --production

      - name: Jalankan tes
        run: npm test

      - name: Build aplikasi
        run: npm run build

  deploy:
    needs: build-and-test   # hanya jalan bila tahap sebelumnya lolos
    runs-on: ubuntu-latest
    steps:
      - name: Tayangkan ke server
        run: echo "Menayangkan artefak build ke produksi..."

Perhatikan bagian needs: build-and-test pada job deploy. Baris ini memastikan penayangan hanya terjadi bila build dan tes berhasil. Bila ada satu tes yang gagal, deploy tidak akan pernah dijalankan — persis seperti penjaga gerbang yang Anda inginkan.

Menyimpan rahasia dengan aman

Pipeline sering butuh akses ke hal sensitif — kunci server, token deploy, kredensial. Jangan pernah menuliskannya langsung di berkas workflow, karena berkas itu tersimpan di repository.

Sebagai gantinya, gunakan fitur secrets yang disediakan platform CI/CD. Di GitHub, Anda menyimpannya di pengaturan repository, lalu memanggilnya di workflow tanpa pernah memaparkan nilainya:

      - name: Deploy via SSH
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
        run: ./deploy.sh

Dengan cara ini, rahasia tetap tersembunyi bahkan dari orang yang bisa membaca kode workflow Anda.

Strategi penayangan yang lebih aman

Begitu pipeline dasar berjalan, Anda bisa menambah lapisan kehati-hatian.

• Tayangkan ke staging dulu. Buat pipeline menayangkan ke lingkungan staging secara otomatis, lalu ke produksi hanya setelah Anda memverifikasi staging.
• Tambahkan persetujuan manual. Untuk produksi, banyak tim menambahkan langkah "tunggu persetujuan" agar seorang manusia menekan tombol akhir. Ini memadukan kecepatan otomatisasi dengan kendali manusia.
• Pisahkan per branch. Misalnya, push ke branch develop tayang ke staging, push ke main tayang ke produksi.

Tips. Jangan langsung mengincar pipeline yang sempurna. Mulai dari satu yang hanya menjalankan tes otomatis saja. Setelah itu terasa nyaman, tambahkan build, lalu deploy staging, lalu produksi. Bertahap jauh lebih mudah daripada membangun semuanya sekaligus.

Kesalahan umum pemula

Beberapa jebakan yang sering ditemui saat pertama kali menyiapkan CI/CD:

1. Menaruh rahasia di berkas workflow. Selalu pakai fitur secrets, tanpa kecuali.
2. Tidak menguji pipeline di branch terpisah. Uji dulu perubahan pipeline di branch percobaan sebelum menerapkannya ke alur utama.
3. Membuat pipeline terlalu rumit sejak awal. Kompleksitas yang tidak perlu membuatnya sulit dirawat dan didebug.
4. Melewatkan tahap tes. Pipeline tanpa tes hanya memindahkan file lebih cepat — ia tidak melindungi Anda dari bug.
5. Tidak menyiapkan rollback. Otomatisasi mempercepat penayangan, termasuk mempercepat penayangan bug. Pastikan Anda tetap bisa mundur cepat.

Langkah memulai

Kalau Anda ingin mencoba hari ini, urutan paling gampang:

1. Pilih platform yang terintegrasi dengan tempat kode Anda berada — GitHub Actions untuk GitHub, GitLab CI untuk GitLab.
2. Buat workflow minimal yang hanya menjalankan tes setiap kali ada push.
3. Setelah nyaman, tambahkan tahap build.
4. Tambahkan penayangan otomatis ke staging.
5. Terakhir, tambahkan penayangan ke produksi dengan persetujuan manual.

Penutup

Menyiapkan pipeline CI/CD pertama mungkin terasa seperti pekerjaan ekstra di awal, tapi ia membayar dirinya sendiri dengan sangat cepat. Semua kedisiplinan yang kita bahas sepanjang seri ini — tidak mengunggah kode mentah, memeriksa keamanan dan konfigurasi sebelum tayang — menjadi otomatis, konsisten, dan bebas dari lupa.

Kalau hanya satu prinsip yang ingin Anda bawa dari seri deployment ini secara keseluruhan: biarkan mesin menjalankan hal yang berulang, agar Anda bisa fokus pada hal yang butuh penilaian manusia. Mulai dari pipeline yang kecil dan sederhana, lalu kembangkan seiring kepercayaan diri Anda tumbuh. Rilis yang tadinya menegangkan akan pelan-pelan berubah menjadi rutinitas yang membosankan — dan dalam urusan produksi, membosankan adalah pujian tertinggi.

Ini bagian ketiga dari seri deployment Yowisben. Bila Anda melewatkan awalnya, mulailah dari mengapa source code mentah tak boleh langsung diunggah dan checklist sebelum naik ke produksi. Terakhir, pelajari strategi rollback dan zero-downtime deployment untuk menutup seri ini.