Apa yang Harus Diperiksa Pipeline Sebelum Deployment

Bayangkan ini: Anda mendorong perubahan, pipeline berubah hijau, dan Anda melakukan deployment. Sepuluh menit kemudian, pengguna mulai melaporkan error. Migrasi database merusak query. Sebuah dependensi memperkenalkan kerentanan yang sudah diketahui. Sebuah file konfigurasi kehilangan field yang wajib ada.

Pipeline mengatakan semuanya baik-baik saja. Padahal tidak.

Ini terjadi ketika pipeline hanya memeriksa apakah kode bisa dikompilasi dan pengujian lulus. Itu memang diperlukan, tetapi belum cukup. Pipeline yang berguna bertindak sebagai gatekeeper: ia menghentikan perubahan yang akan menyebabkan masalah di produksi, sebelum perubahan itu sampai ke sana. Pertanyaannya, apa yang harus diperiksa?

Build Harus Berhasil Terlebih Dahulu

Gate paling dasar adalah apakah kode benar-benar bisa di-build. Ketika developer mendorong perubahan, pipeline mencoba mengompilasi kode atau menghasilkan artifact yang bisa dijalankan. Jika build gagal—kesalahan sintaks, dependensi tidak kompatibel, konfigurasi rusak—tidak ada gunanya melanjutkan. Kode tidak bisa berjalan sama sekali.

Gate ini harus selalu menjadi langkah pertama. Cepat, murah, dan menyaring perubahan yang bahkan belum siap untuk diuji. Jika build gagal, pipeline berhenti. Developer mendapatkan umpan balik langsung dan bisa memperbaiki masalah sebelum orang lain terpengaruh.

Unit Test Memverifikasi Perilaku, Bukan Implementasi

Setelah build berhasil, gate berikutnya adalah unit test. Tapi tidak semua unit test diciptakan sama. Unit test yang baik memeriksa perilaku yang bermakna dari entry point yang relevan. Untuk backend service, itu bisa berupa API endpoint atau use case yang mengalir melalui lapisan internal yang nyata. Untuk frontend app, itu bisa berupa interaksi pengguna seperti mengklik tombol atau mengirim formulir.

Kuncinya adalah unit test tidak boleh rusak ketika Anda melakukan refactor kode internal. Mereka hanya boleh rusak ketika perilaku yang bisa diamati berubah. Jika unit test gagal, itu berarti sistem tidak lagi merespons dengan benar terhadap input yang valid. Itu layak untuk menghentikan pipeline.

Beberapa tim menulis unit test yang sangat terikat pada detail implementasi: menguji method private, menguji setiap class secara terpisah, melakukan mock pada lapisan internal, dan rusak pada setiap refactor. Test semacam itu menciptakan noise dan memperlambat pengiriman. Lakukan mock pada neighbor eksternal jika perlu, tetapi biarkan perilaku internal berjalan melalui jalur yang benar-benar digunakan aplikasi. Gate hanya berguna jika test-nya dapat diandalkan. Jika unit test Anda sering gagal karena alasan non-fungsional, developer akan mulai mengabaikannya, dan gate kehilangan nilainya.

Integration Test Menangkap Masalah Koneksi

Unit test bisa berjalan tanpa dependensi eksternal. Integration test tidak bisa. Mereka memverifikasi bahwa sistem Anda benar-benar dapat berbicara dengan dunia luar: database nyata, message queue, API pihak ketiga.

Contohnya, unit test Anda mungkin melakukan mock pada database dan lulus. Tapi database asli mungkin menolak query karena ketidakcocokan skema, indeks yang hilang, atau error konversi tipe data. Integration test menangkap masalah-masalah itu.

Test ini membutuhkan lingkungan yang lebih lengkap—database test, container, atau service yang berjalan. Mereka lebih lambat dari unit test, tetapi mereka menangkap kelas masalah yang berbeda. Jika integration test gagal, itu biasanya berarti perubahan tidak bekerja dengan infrastruktur aktual yang akan digunakan.

Security Scan Harus Berjalan Otomatis

Keamanan bukanlah sesuatu yang bisa Anda serahkan pada review manual sebelum rilis. Pada saat seseorang melihat kode, dependensi yang rentan mungkin sudah berada di produksi. Security scan otomatis dapat berjalan tanpa campur tangan manusia dan memeriksa beberapa hal:

  • Apakah ada dependensi dengan kerentanan yang diketahui?
  • Apakah kode secara tidak sengaja mengandung kredensial atau API key?
  • Apakah ada pola yang bisa dieksploitasi, seperti SQL injection atau deserialisasi yang tidak aman?

Beberapa tim menjalankan static analysis pada kode sumber. Yang lain menjalankan dynamic scan terhadap aplikasi yang sedang berjalan. Kedua pendekatan menangkap masalah yang berbeda. Yang penting adalah pipeline memeriksa keamanan secara otomatis, setiap saat.

Jika security scan gagal, pipeline berhenti. Developer mendapatkan laporan yang menunjukkan dengan tepat apa yang salah. Tidak perlu persetujuan manual, tidak perlu menunggu tim keamanan untuk meninjau kode. Gate itu sendiri yang memblokir perubahan.

Policy Compliance Menjaga Konsistensi

Tidak semua pemeriksaan perlu bersifat teknis. Beberapa terkait proses dan konsistensi. Policy compliance gate memeriksa apakah perubahan mengikuti aturan yang telah disepakati oleh tim atau organisasi Anda.

Pemeriksaan kebijakan yang umum meliputi:

  • Apakah kode telah melewati code review?
  • Apakah nama branch mengikuti konvensi (misalnya, feature/ atau fix/)?
  • Apakah pull request terlalu besar? Beberapa tim membatasi perubahan pada sejumlah baris atau file tertentu.
  • Apakah semua dependensi berasal dari registry yang disetujui?

Pemeriksaan ini bersifat administratif, tetapi penting. Mereka mencegah situasi di mana seseorang menggabungkan perubahan 2000 baris tanpa review, atau di mana dependensi dari sumber yang tidak terpercaya masuk. Pipeline menegakkan aturan secara otomatis, sehingga tidak ada yang harus mengingatnya.

Ketika Otomatisasi Tidak Cukup

Lima gate di atas—build, unit test, integration test, security scan, policy compliance—semuanya bisa berjalan otomatis. Pipeline memutuskan lulus atau gagal, dan berhenti jika ada yang salah. Tidak perlu manusia membuat keputusan.

Tetapi tidak semua pemeriksaan harus diotomatisasi. Beberapa keputusan membutuhkan penilaian manusia. Misalnya, perubahan yang memengaruhi alur bisnis kritis, atau deployment yang menyentuh beberapa service sekaligus, mungkin memerlukan seseorang untuk meninjau risiko dan memutuskan apakah akan melanjutkan. Di sinilah persetujuan manual berperan.

Kuncinya adalah mengotomatiskan apa yang bisa diukur secara objektif, dan meninggalkan keputusan subjektif kepada manusia. Jika sebuah pemeriksaan dapat dinyatakan sebagai aturan yang selalu berlaku, otomatiskan. Jika membutuhkan konteks, pengalaman, atau trade-off, biarkan manual.

Daftar Periksa Praktis untuk Gate Pipeline Anda

Jika Anda sedang menyiapkan atau meninjau gate pipeline, berikut adalah daftar periksa singkat untuk dipertimbangkan:

Diagram alir berikut menunjukkan bagaimana gate ini bekerja bersama secara berurutan:

flowchart TD A([Mulai]) --> B{Build Berhasil?} B -- Ya --> C{Unit Test Lulus?} B -- Tidak --> X[Berhenti dan Beri Tahu] C -- Ya --> D{Integration Test Lulus?} C -- Tidak --> X D -- Ya --> E{Security Scan Lulus?} D -- Tidak --> X E -- Ya --> F{Policy Compliance Lulus?} E -- Tidak --> X F -- Ya --> G{Perlu Review Manual?} F -- Tidak --> X G -- Tidak --> H([Deploy]) G -- Ya --> I{Review Disetujui?} I -- Ya --> H I -- Tidak --> X
  • Build gate: Apakah pipeline berhenti jika kode tidak bisa dikompilasi atau menghasilkan artifact?
  • Unit test gate: Apakah test memverifikasi perilaku yang bermakna dari entry point yang relevan, bukan implementasi internal?
  • Integration test gate: Apakah pipeline menguji terhadap dependensi nyata (database, queue, service eksternal)?
  • Security scan gate: Apakah dependensi dipindai untuk kerentanan? Apakah kode diperiksa untuk secrets dan pola berisiko?
  • Policy compliance gate: Apakah aturan seperti code review, penamaan branch, dan sumber dependensi ditegakkan secara otomatis?

Tidak semua tim membutuhkan kelima gate sejak hari pertama. Mulailah dengan build dan unit test. Tambahkan integration test ketika Anda memiliki dependensi eksternal. Tambahkan security scan ketika Anda mulai peduli dengan kerentanan. Tambahkan policy check ketika Anda membutuhkan konsistensi di seluruh tim.

Tujuan Gate Adalah Menghentikan Masalah, Bukan Memperlambat Anda

Gate yang dirancang dengan baik tidak menambah gesekan tanpa alasan. Ia menangkap masalah sejak awal, ketika biaya perbaikannya murah. Build yang gagal yang tertangkap di pipeline memakan waktu menit. Deployment yang gagal yang tertangkap di produksi memakan waktu berjam-jam, kadang berhari-hari.

Tujuannya bukan membuat pipeline semakin sulit untuk dilewati. Tujuannya adalah memastikan bahwa ketika pipeline lulus, Anda bisa melakukan deployment dengan percaya diri. Jika pipeline Anda hijau tetapi produksi tetap rusak, gate Anda memeriksa hal yang salah. Perbaiki gate terlebih dahulu, baru perbaiki pipeline.