Apa yang Terjadi Pertama Kali dalam Pipeline CI/CD: Checkout dan Persiapan Lingkungan

Kamu melakukan push sebuah commit. Tool CI/CD-mu mendeteksi perubahan tersebut dan memulai sebuah pipeline baru. Namun sebelum proses build, test, atau deployment terjadi, pipeline perlu menjawab tiga pertanyaan dasar: Kode apa yang sedang saya kerjakan? Tool apa yang saya miliki? Dan apakah workspace saya bersih?

Tahap pertama ini sering diabaikan, padahal di sinilah banyak kegagalan pipeline sebenarnya bermula. Workspace yang kotor, versi tool yang tidak cocok, atau dependensi yang hilang bisa menggagalkan seluruh pipeline bahkan sebelum ia mulai melakukan pekerjaan yang berarti. Mari kita bahas apa yang terjadi selama proses checkout dan persiapan awal, serta mengapa melakukan ini dengan benar sangat penting untuk setiap pipeline selanjutnya.

Langkah Checkout: Mendapatkan Kode yang Tepat

Ketika sebuah pipeline terpicu, ia membawa informasi dari event pemicu: hash commit, nama branch, atau tag. Langkah checkout menggunakan informasi tersebut untuk menarik versi kode yang tepat dari repositori ke dalam workspace pipeline.

Workspace adalah folder sementara di mesin yang menjalankan pipeline. Mesin tersebut biasanya disebut runner atau agent, tergantung pada tool CI/CD yang kamu gunakan. Pipeline mengunduh kode ke dalam folder ini, dan semua aktivitas build, test, dan deployment lainnya terjadi di dalam ruang tersebut.

Anggap saja seperti kamu datang ke meja kerja baru di kantor. Kamu perlu tahu proyek mana yang sedang dikerjakan, versi proyek mana yang harus digunakan, dan tool apa saja yang tersedia di mejamu. Tanpa itu, kamu tidak bisa memulai.

Diagram alir berikut menunjukkan urutan aksi yang terjadi di tahap pertama sebuah pipeline CI/CD:

Berikut adalah contoh praktis menggunakan GitHub Actions:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js 18
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'
flowchart TD A[Trigger Event: commit, branch, atau tag] --> B[Checkout Code: tarik hash commit tepat] B --> C[Bersihkan Workspace: hapus file sisa] C --> D[Identifikasi Build: beri label artefak berdasarkan branch/tag] D --> E[Setup Lingkungan: instal tool dan dependensi] E --> F{Cache Tersedia?} F -- Ya --> G[Pulihkan dependensi dari cache] F -- Tidak --> H[Unduh dependensi baru] G --> I[Siap untuk Tahap Build] H --> I

Mengapa Workspace yang Bersih Itu Penting

Setiap eksekusi pipeline harus dimulai dengan workspace yang bersih. Jika file dari eksekusi sebelumnya masih tersisa, file tersebut dapat mengontaminasi build saat ini. File konfigurasi yang tertinggal, binary kompilasi yang basi, atau dependensi lama dapat menyebabkan pipeline menghasilkan artefak yang tidak sesuai dengan kode saat ini. Debugging masalah seperti ini sangat menyakitkan karena masalahnya bukan pada kode-mu, melainkan pada sampah sisa dari eksekusi sebelumnya.

Kebanyakan tool CI/CD menawarkan opsi workspace bersih. Beberapa mengaktifkannya secara default, yang lain memerlukan konfigurasi manual. Jika kamu sedang menyiapkan pipeline, pastikan fitur ini diaktifkan. Ini adalah pengaturan kecil yang mencegah banyak bug yang sulit ditemukan.

Mengidentifikasi Apa yang Kamu Bangun

Setelah checkout, pipeline perlu tahu branch atau tag mana yang sedang diproses. Informasi ini menentukan bagaimana artefak yang dihasilkan akan diberi label dan ke mana ia akan dikirim selanjutnya.

Sebagai contoh, sebuah commit ke branch main mungkin menghasilkan artefak berlabel latest atau stable. Sebuah commit ke branch fitur mungkin menghasilkan artefak dengan nama branch dan nomor build. Sebuah tag seperti v1.2.3 harus menghasilkan artefak berlabel dengan versi yang tepat tersebut.

Pelabelan ini penting karena membantu tim melacak artefak kembali ke sumbernya. Ketika seseorang bertanya "versi kode mana yang menghasilkan artefak ini?", label tersebut harus memberikan jawaban yang jelas. Tanpa pelabelan yang konsisten, manajemen artefak menjadi tebak-tebakan.

Menyiapkan Lingkungan

Setelah kode berada di tempatnya, pipeline perlu menyiapkan lingkungannya. Lingkungan di sini berarti lebih dari sekadar folder tempat kode berada. Ini mencakup semua tool dan dependensi yang diperlukan untuk membangun, menguji, dan men-deploy aplikasi.

Aplikasi Java membutuhkan JDK versi tertentu. Aplikasi Node.js membutuhkan Node.js runtime dan npm yang tepat. Migrasi database membutuhkan tool migrasi seperti Flyway atau Liquibase. Masing-masing tool ini harus tersedia di lingkungan pipeline, pada versi yang benar.

Masalah "Di Mesin Saya Berhasil"

Salah satu frustrasi paling umum dalam CI/CD adalah ketidakcocokan antara lingkungan lokal pengembang dan lingkungan pipeline. Seorang pengembang menjalankan build di laptopnya, semuanya berhasil, lalu ia push kodenya. Pipeline mengambilnya, menjalankan build yang sama, dan gagal.

Penyebabnya hampir selalu adalah perbedaan lingkungan. Pengembang memiliki JDK 17 terinstal secara lokal, tetapi pipeline menggunakan JDK 11. Pengembang memiliki paket npm global yang tidak dimiliki pipeline. Laptop pengembang memiliki sistem operasi atau arsitektur yang berbeda.

Ini adalah masalah klasik "di mesin saya berhasil", dan ini adalah tanda bahwa lingkungan pipeline tidak didefinisikan secara eksplisit.

Membuat Lingkungan yang Reproducible

Solusinya adalah mendefinisikan lingkungan pipeline secara eksplisit, sehingga dapat direproduksi di mana saja. Ada beberapa pendekatan umum:

  • Docker images: Kemas semua tool yang diperlukan ke dalam sebuah Docker image. Pipeline berjalan di dalam container berdasarkan image tersebut, menjamin lingkungan yang sama setiap saat.
  • File versi tool: Gunakan file seperti .tool-versions (untuk asdf), .nvmrc (untuk Node.js), atau .ruby-version untuk mendeklarasikan versi tool yang tepat. Pipeline membaca file-file ini dan menginstal versi yang ditentukan.
  • Environment managers: Tool seperti Conda untuk Python atau SDKMAN untuk Java dapat mengelola versi tool secara deklaratif.

Tujuannya sama: lingkungan pipeline harus dapat direproduksi di mana pun pipeline berjalan. Jika kamu dapat menjalankan pipeline di laptopmu, di server CI, dan di mesin rekan kerja, dan mendapatkan hasil yang sama, maka kamu telah memecahkan masalah konsistensi lingkungan.

Caching: Kecepatan vs. Kesegaran

Beberapa pipeline menambahkan caching pada tahap ini untuk mempercepat eksekusi berikutnya. Dependensi yang diunduh di eksekusi sebelumnya dapat disimpan dan digunakan kembali. Ini masuk akal untuk kumpulan dependensi yang besar, seperti node_modules Node.js atau venv Python.

Namun caching memperkenalkan trade-off. Cache yang basi dapat menyebabkan pipeline menggunakan dependensi lama yang seharusnya sudah diganti. Jika sebuah dependensi diperbarui di repositori, tetapi cache masih menyimpan versi lama, pipeline mungkin akan membangun kode menggunakan dependensi yang usang.

Jika kamu menggunakan caching, pastikan kunci cache menyertakan informasi yang cukup untuk membatalkannya ketika dependensi berubah. Pendekatan umum adalah dengan melakukan hash pada file dependensi (seperti package-lock.json atau requirements.txt) dan menggunakan hash tersebut sebagai bagian dari kunci cache. Ketika file dependensi berubah, kunci cache berubah, dan unduhan baru akan terjadi.

Apa yang Dimiliki Pipeline Setelah Tahap Ini

Pada saat checkout dan persiapan lingkungan selesai, pipeline telah memiliki:

  • Kode yang tepat dari commit, branch, atau tag pemicu
  • Workspace yang bersih tanpa file sisa
  • Label yang diketahui untuk artefak yang akan dihasilkan
  • Semua tool dan dependensi yang diperlukan untuk tahap selanjutnya

Ini adalah fondasinya. Tanpa ini, setiap tahap selanjutnya (build, test, deploy) dibangun di atas ketidakpastian. Dengan ini, pipeline dapat melangkah maju dengan percaya diri.

Daftar Periksa Cepat untuk Tahap Pertama Pipeline-mu

  • Workspace bersih diaktifkan atau dikonfigurasi
  • Checkout menggunakan hash commit yang tepat dari pemicu
  • Pelabelan artefak sesuai dengan konvensi branch atau tag
  • Versi tool dideklarasikan secara eksplisit (Docker, file versi tool, atau environment manager)
  • Kunci cache menyertakan hash file dependensi jika caching digunakan

Intisari

Beberapa detik pertama dari eksekusi pipeline menentukan apakah sisa pipeline berjalan di atas fondasi yang kokoh. Workspace yang bersih, kode yang tepat, dan lingkungan yang reproducible bukanlah detail opsional. Mereka adalah fondasi yang membuat setiap tahap selanjutnya dapat diprediksi dan mudah di-debug. Investasikan waktu untuk melakukan tahap ini dengan benar, dan kamu akan menghemat lebih banyak waktu untuk memecahkan masalah kegagalan yang ternyata disebabkan oleh masalah lingkungan, bukan masalah kode.