Skip to content

Gerbang Slice yang Membaca Artefak Program Lain

Adityo Guni Waluyo

Satu direktori program tertanam di cmd_slice membuat gerbang validasi lulus dengan bukti milik program lain; pembenahnya satu baris env-override.

Ringkasan

Skrip gerbang slice ternyata ngecek direktori program lama, qa-backfill, bukan program yang lagi jalan, karena lokasinya nempel jadi konstanta di kode. Fix-nya cuma satu baris: baca dari env dulu, kalau kosong baru pakai bawaan. Pelajarannya: begitu alat dipakai di konteks kedua, nilai yang beda antar konteks harus naik kelas ke env.

Gerbang slice dijalankan untuk program baru, dan lulusnya terasa terlalu mulus. Pemeriksaan ternyata membaca direktori program qa-backfill, bukan direktori program yang sedang berjalan. Bukti yang divalidasi bukan milik pekerjaan yang sedang diperiksa. Perintahnya sendiri tampak netral karena hanya menerima nomor slice, sehingga dugaan pertama jatuh ke salah input, bukan ke skripnya.

Skrip gerbang memang dibangun saat program qa-backfill berjalan, dan satu lokasinya tertanam langsung di tubuh cmd_slice. Selama hanya ada satu program, kejumerus itu tidak terasa. Program kedua muncul, dan gerbang yang sama mulai memvalidasi bukti milik orang lain tanpa suara.

Jalur Keras yang Tidak Terlihat

Kode yang menerima parameter sering dikira sudah dikonfigurasi. Padahal parameter yang diterima dan jalur yang diikuti adalah dua hal berbeda: nomor slice dioper ke fungsi, tetapi direktori program tidak berasal dari pemanggil maupun lingkungan, ia konstanta. Alat dengan satu konstanta seperti ini hanya pernah diuji di satu program, dan uji pertamanya selalu hijau.

Gejalanya pun tidak berupa error. Gerbang tetap berjalan, laporan tetap tercetak, angka tetap keluar. Yang salah adalah rujukannya, dan rujukan yang salah pada alat verifikasi jauh lebih mahal daripada crash: kegagalan yang terlihat memaksa perbaikan, kegagalan yang lulus diam-diam menghasilkan putusan berdasarkan bukti yang keliru.

Satu Baris: Env Menang, Bawaan Tetap

Perbaikannya satu baris penggantian. Direktori program dibaca dari variabel lingkungan terlebih dahulu; kalau tidak diset, nilai bawaan dipakai seperti semula. Idiom ini sama dengan yang dipakai variabel REPO_ROOT sejak tugas pertama, jadi skrip kini konsisten memakai satu pola untuk semua lokasi yang bisa berbeda antar program.

The Twelve-Factor App merumuskan dasarnya: konfigurasi adalah segala hal yang kemungkinan berbeda antar deployment, dan menyimpannya sebagai konstanta kode disebut langsung sebagai pelanggaran prinsip [4]. Nama program dan direktori artefaknya memang bukan kredensial, tapi sifatnya sama: nilainya bergantung konteks pemakaian, bukan logika alat. Konstanta yang mengikat alat ke satu program adalah bentuk lain dari config di dalam kode.

Verifikasinya konkret: slice 6 pada program baru kini lulus dengan membaca artefak program itu sendiri. Peninjauan ulang satu baris pada tugas keenam menghasilkan approve tanpa critical maupun major. Tidak ada logika validasi yang berubah; yang berubah hanya asal sebuah nilai.

Cara memeriksa tooling sendiri juga tidak perlu rumit. Jalankan alat yang sama dua kali di dua konteks berbeda, lalu bandingkan rujukan berkas yang dibukanya. Kalau keduanya menunjuk direktori yang sama padahal konteksnya beda, ada konstanta yang belum naik kelas. Pemeriksaan dua pemanggilan ini menemukan kasus serupa lebih cepat daripada membaca ulang seluruh skrip.

Sisa pekerjaan yang disadari: pola ini baru menyentuh direktori program. Konstanta lain yang sifatnya sama kemungkinan masih ada di skrip yang lebih tua, dan naik-kelasnya mengikuti kebutuhan nyata, bukan sekaligus. Yang penting arahnya konsisten: setiap nilai yang membuktikan keberagaman konteks keluar dari kode.

Karakter idiom ini juga mudah diaudit kemundurannya. Grep sederhana pada skrip cukup untuk memastikan tidak ada lokasi program yang tertanam lagi, dan peninjau yang melihat pola REPO_ROOT serta SDD_WORKSPACE langsung tahu pola apa yang diharapkan pada variabel serupa berikutnya. Konsistensi pola menurunkan biaya pemeriksaan setiap orang yang datang belakangan.

Angka dua program terasa sepele sebagai batas, tapi di situlah umumnya pagar pertama retak. Alat yang ditulis saat satu konteks selalu menyimpan satu asumsi; konteks kedua tidak menjebol asumsi itu dengan keras, ia hanya membuat hasilnya pelan-pelan bergeser keluar kebenaran. Perbaikan satu baris kali ini murah justru karena dibayar segera setelah gejala pertama, bukan setelah beberapa putusan terlanjur dibuat dari bukti yang salah program.

Kontrak Alat yang Jujur

Pola env-override punya kontrak yang enak dijelaskan: bawaan untuk kasus umum, penimpaan eksplisit untuk sisanya, tanpa berkas konfigurasi baru dan tanpa flag tambahan. Skrip bash menyediakan idiom ini gratis lewat ekspansi parameter. Biaya perubahannya satu baris; biaya tidak mengubahnya adalah gerbang yang setiap program baru harus diganti kodenya, lengkap dengan risiko lupa.

Pelajarannya untuk perkakas internal apa pun: begitu sebuah alat dipakai konteks kedua, semua nilai yang berbeda di antara konteks itu harus naik kelas jadi lingkungan. Perbaikan paling murah selalu yang dilakukan sebelum ada yang percaya pada laporan yang salah.

Sumber

  1. The Twelve-Factor App — Config [4]

Artikel terkait