Pipeline Pertama Anda Bukan Soal Alat. Ini Soal Konsistensi.

Bayangkan ini: tim Anda sudah berbulan-bulan melakukan deployment secara manual. Setiap rilis, seseorang SSH ke server, menarik kode terbaru, dan me-restart service. Cara ini memang berhasil, tapi penuh tekanan. Suatu hari, seorang developer lupa menjalankan tes sebelum deploy. Keesokan harinya, orang lain deploy dari branch yang belum sepenuhnya di-merge. Tidak ada yang yakin apa yang sebenarnya berjalan di production.

Inilah momen ketika sebagian besar tim memutuskan bahwa mereka membutuhkan pipeline. Namun insting pertama biasanya adalah memilih alat: Jenkins, GitLab CI, GitHub Actions. Masalahnya bukan pada alat. Masalahnya adalah setiap deployment adalah peristiwa yang unik. Tidak ada yang bisa memprediksi apa yang akan terjadi selanjutnya.

Perbaikan yang sesungguhnya bukanlah alat. Melainkan proses yang dapat diulang.

Mulai dengan Satu Jalur

Sebelum Anda menstandarisasi apa pun, pilih satu rute yang akan diikuti oleh setiap perubahan. Bukan dua rute. Bukan "tergantung situasi." Satu jalur dari kode ke production.

Untuk sebagian besar aplikasi, jalur tersebut terlihat seperti ini:

Berikut adalah representasi visual dari golden path tersebut:

flowchart TD A[Build artifact] --> B[Run unit tests] B --> C[Deploy to development] C --> D[Run integration tests] D --> E[Deploy to staging] E --> F[Deploy to production]
  • Build artifact
  • Jalankan unit tests
  • Deploy ke environment development
  • Jalankan integration tests
  • Deploy ke staging
  • Deploy ke production

Tim Anda mungkin menyebut tahapan-tahapan ini dengan nama yang berbeda. Itu tidak masalah. Intinya adalah setiap perubahan melewati urutan yang sama, dalam urutan yang sama, setiap saat.

Berikut adalah tampilan golden path tersebut sebagai workflow GitHub Actions minimal:

name: Golden Path
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Build artifact"

  unit-tests:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: echo "Run unit tests"

  deploy-dev:
    needs: unit-tests
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to development"

  integration-tests:
    needs: deploy-dev
    runs-on: ubuntu-latest
    steps:
      - run: echo "Run integration tests"

  deploy-staging:
    needs: integration-tests
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to staging"

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production"

Ini adalah golden path Anda. Tidak harus sempurna. Yang penting ada. Begitu ada, Anda bisa memperbaikinya. Tapi jika tidak memiliki satu jalur pun, Anda tidak memiliki baseline untuk melakukan perbaikan.

Konsistensi adalah Tujuan, Bukan Kecepatan

Saat pertama kali menyiapkan pipeline, rasanya akan lebih lambat dibandingkan deployment manual. Itu wajar. Deployment manual terasa cepat karena melewatkan langkah-langkah. Melewatkan tes. Melewatkan verifikasi. Melewatkan bagian-bagian yang mencegah bencana.

Pipeline tidak lebih cepat dalam jangka pendek. Pipeline lebih dapat diprediksi. Dan prediktabilitas adalah yang memungkinkan Anda bergerak cepat nantinya.

Inilah yang diberikan konsistensi kepada Anda:

  • Setiap perubahan dibangun dengan cara yang sama. Tidak ada lagi "di mesin saya berhasil."
  • Setiap perubahan diuji dengan cara yang sama. Tidak ada lagi suite tes yang dilewati.
  • Setiap perubahan menuju ke environment yang sama. Tidak ada lagi "saya lupa deploy ke staging."

Ketika pipeline konsisten, tim berhenti menebak-nebak. Mereka berhenti bertanya "Apa ada yang menjalankan tes?" Mereka berhenti mengecek Slack untuk instruksi deployment. Pipeline menjawab pertanyaan-pertanyaan itu secara otomatis.

Tambahkan Risk Gate, Bukan Penghambat

Pipeline yang konsisten itu bagus. Pipeline yang tahu kapan harus berhenti itu lebih baik.

Risk gate adalah titik dalam pipeline di mana ia bisa menjeda atau berhenti berdasarkan suatu kondisi. Tujuannya bukan untuk memperlambat. Tujuannya adalah menangkap masalah sebelum mencapai pengguna.

Mulailah dengan gate yang paling mudah: tes otomatis. Jika unit tests gagal, pipeline berhenti. Jika integration tests gagal, pipeline berhenti. Gate ini tidak memerlukan keputusan manusia. Anda menulis tes, dan pipeline yang menegakkannya.

Gate kedua adalah persetujuan manual untuk production. Perubahan bisa mengalir secara otomatis ke development dan staging. Tapi untuk mencapai production, seseorang perlu menyetujui secara eksplisit. Ini berguna ketika tes otomatis Anda belum cukup komprehensif, atau ketika perubahan production memiliki dampak tinggi pada pengguna. Pilih siapa yang bisa menyetujui dengan hati-hati. Harus seseorang yang memahami aplikasi dan risikonya, bukan sembarang orang yang memiliki akses.

Gate ketiga adalah pemindaian keamanan dasar. Pindai dependensi untuk kerentanan yang diketahui. Pindai kode untuk pola berbahaya. Ini tidak harus sempurna. Mulailah dengan masalah yang paling umum. Tambahkan pemeriksaan lebih banyak seiring waktu.

Risk Gate Bukanlah Tembok

Kesalahan umum adalah memperlakukan risk gate sebagai penghalang permanen. Jika sebuah gate terus-menerus menghentikan pipeline karena alasan sepele, tim akan mulai melewatinya. Jika sebuah gate selalu diabaikan, ia menjadi noise.

Risk gate harus dievaluasi secara berkala. Ajukan pertanyaan-pertanyaan ini:

  • Apakah gate ini menangkap masalah nyata?
  • Apakah ia menghentikan pipeline karena alarm palsu?
  • Apakah tim mempercayainya?

Jika sebuah gate tidak berguna, hapus atau sesuaikan. Gate yang tidak dihormati siapa pun lebih buruk daripada tidak ada gate sama sekali. Setidaknya tanpa gate, tim tahu bahwa mereka tidak memiliki jaring pengaman.

Ketika Satu Jalur Berhasil, Kembangkan

Setelah golden path Anda stabil dan risk gate berfungsi, Anda akan melihat sebuah pola. Tahapan yang sama yang berhasil untuk satu aplikasi dapat bekerja untuk aplikasi lain dengan penyesuaian kecil. Gate yang sama yang menangkap masalah di satu service dapat menangkap masalah di service lain.

Inilah saatnya untuk menstandarisasi lebih lanjut. Bukan dengan memaksa setiap tim menggunakan alat yang sama, tetapi dengan menyediakan template pipeline bersama. Tim dapat menggunakan kembali langkah build yang sama, test runner yang sama, script deployment yang sama. Mereka hanya menyesuaikan apa yang unik untuk aplikasi mereka.

Dari sini, Anda dapat memperluas pola yang sama ke perubahan database dan perubahan infrastruktur. Tapi itu adalah topik untuk artikel lain.

Checklist Praktis untuk Pipeline Standar Pertama Anda

  • Tentukan satu golden path dari kode ke production
  • Buat setiap perubahan melewati tahapan yang sama dalam urutan yang sama
  • Tambahkan gate tes otomatis (unit, integration)
  • Tambahkan persetujuan manual untuk production jika diperlukan
  • Tambahkan pemindaian keamanan dasar
  • Evaluasi gate setelah satu bulan. Hapus atau sesuaikan yang tidak berfungsi

Intisari

Pipeline pertama Anda bukan tentang memilih alat yang tepat. Ini tentang membuat setiap deployment dapat diprediksi. Mulailah dengan satu jalur. Buatlah konsisten. Tambahkan gate yang menangkap masalah nyata. Kemudian perluas pola tersebut ke seluruh sistem Anda. Alat akan mengikuti. Proseslah yang utama.