Tentang Manfaat Opsi `dry-run`

 (henrikwarne.com)
1 poin oleh GN⁺ 2026-02-02 | 1 komentar | Bagikan ke WhatsApp
  • Dalam proses pengembangan aplikasi pembuatan laporan, ditambahkan opsi --dry-run agar hasil eksekusi bisa disimulasikan
  • Opsi ini menampilkan pekerjaan apa yang akan dilakukan tanpa perubahan nyata, sehingga memungkinkan pengujian yang aman dan umpan balik yang cepat
  • Dengan ini, pengembang dapat langsung memeriksa konfigurasi, aksesibilitas, dan status sistem, serta memakainya sebagai alat verifikasi harian
  • Kekurangannya adalah adanya sedikit peningkatan kompleksitas karena perlu memeriksa flag dryRun di dalam kode
  • Pada aplikasi imperatif, fitur --dry-run sangat berguna, dan semakin awal diperkenalkan dalam proyek, semakin tinggi efisiensi pengembangannya

Latar belakang

  • Aplikasi pembuatan laporan yang sedang dikembangkan menghasilkan laporan setiap hari kerja, lalu mengompresnya, mengunggahnya ke server sftp, memeriksa respons error, dan mengirim email notifikasi
    • File yang dihasilkan dan file umpan balik pada tiap tahap dipindahkan ke direktori yang berbeda sesuai tahapnya
  • Pada awal pengembangan, penulis teringat pada Subversion dan berbagai opsi --dry-run pada perintah Linux, lalu menambahkan fungsi yang sama
    • Opsi ini menampilkan apa yang akan terjadi saat dijalankan tanpa melakukan perubahan nyata
  • Saat menjalankan --dry-run, sistem menampilkan per tahap laporan yang akan dibuat dan yang akan dikecualikan, file yang akan dikompres dan dipindahkan, serta file target unggah dan unduh sftp

Penggunaan dan manfaat

  • Fitur ini cukup berguna hingga dipakai setiap hari selama proses pengembangan dan pengujian
  • Jika digunakan untuk memeriksa kondisi sebelum eksekusi, konfigurasi, aksesibilitas, dan status sistem bisa langsung diverifikasi
    • Karena tidak ada perubahan nyata, fitur ini aman untuk dijalankan
  • Setelah mengubah tanggal pada file status laporan, bisa langsung dipastikan apakah laporan tersebut akan dibuat atau tidak
    • Pembuatan laporan nyata memerlukan waktu, tetapi dry-run memberikan umpan balik cepat
  • Bahkan saat pengujian sistem secara menyeluruh, fitur ini menyediakan loop verifikasi yang cepat

Kekurangan

  • Karena perlu berulang kali memeriksa flag dryRun di dalam kode, terjadi sedikit polusi kode
    • Pada tiap tahap utama, flag diperiksa agar alih-alih benar-benar dijalankan, sistem hanya menampilkan log
  • Namun pemeriksaan ini tidak terlalu dalam, dan tidak memerlukan penanganan terpisah di dalam logika pembuatan laporan itu sendiri
    • Pemeriksaan hanya dilakukan pada lapisan atas yang menentukan apakah eksekusi benar-benar dilakukan

Kesimpulan

  • Aplikasi yang dijalankan secara imperatif dan menghasilkan output sangat cocok dengan opsi --dry-run
    • Sebaliknya, fitur ini tidak cocok untuk aplikasi reaktif yang menunggu pesan
  • Menambahkannya sejak awal proyek sangat membantu meningkatkan efisiensi pengembangan
  • Ini bukan fitur yang dibutuhkan di semua situasi, tetapi dalam kasus yang tepat, sangat berguna sebagai alat

Bacaan terkait

1 komentar

 
GN⁺ 2026-02-02
Komentar Hacker News

  • Saat berinteraksi dengan sistem yang memiliki state, race condition juga bisa terjadi pada --dry-run
    Tool memang menunjukkan “apa yang akan dilakukan” berdasarkan state saat ini, tetapi ketika benar-benar dijalankan, situasinya bisa saja sudah berubah
    Karena itu saya lebih menyukai pendekatan mode “plan” milik Terraform. Mode ini membuat rencana yang bisa dieksekusi, lalu bisa dihentikan atau di-rollback jika asumsi pada saat perencanaan berubah
    Selain itu, kita tidak perlu menaruh if dry_run: di mana-mana di kode, dan bisa menyederhanakan dengan memisahkan perencanaan dan eksekusi menjadi bentuk execute(plan())

    • Insiden gangguan DNS AWS yang pernah terjadi juga disebabkan race condition serupa
      Karena masalah timing antara DNS Planner dan Enactor, rencana lama sempat menimpa rencana terbaru
      Hal ini juga dibahas di thread HN sebelumnya
    • Kalau begitu, pada akhirnya kita seperti mengimplementasikan compiler (spesifikasi → rencana) dan virtual machine (rencana → eksekusi)
    • Ini ideal untuk tool infrastruktur seperti Terraform atau Ansible, tetapi untuk tool pelaporan sederhana bisa menimbulkan kompleksitas berlebihan
      Karena untuk membuat mode perencanaan, kita butuh bahasa khusus domain atau struktur data tertentu
    • Saya juga sedang membuat skrip yang memodifikasi file sensitif, dan sedang menerapkan pendekatan ini
      (1) menangkap state file system lalu menyimpan rencana → (2) memverifikasi bahwa state tidak berubah, lalu mengeksekusi dan mencatat log → (3) membandingkan dengan state sebelumnya untuk memverifikasi ada tidaknya kehilangan data
      Saya memisahkan ketiga tahap ini ke dalam skrip atau flag yang berbeda
    • Jadi saya penasaran bagaimana mode perencanaan seperti ini bisa diterapkan pada perintah rm

  • Jika suatu tool tidak punya --dry-run, kadang saya membuatnya sendiri
    Misalnya sebelum menjalankan perintah sed yang kompleks, saya memakai diff untuk membandingkan perubahan terlebih dahulu
    Dengan cara seperti diff -u <(echo "hello") <(echo "hello" | sed "s/hello/hi/g"), kita bisa melihat perbedaannya terlebih dahulu
    Tulisan terkait saya rangkum di blog saya

  • Saya suka pola --dry-run, tetapi kode pada jalur dry harus berperilaku sama dengan jalur aktual
    Kalau hanya mencetak “apa yang akan dilakukan” lalu melewati logika sebenarnya, bug saat eksekusi nyata bisa terlewat
    Sebaiknya alurnya tetap sama hingga tepat sebelum penulisan database atau pemanggilan API

    • Namun ada juga yang menganggap ini mencampuradukkan integration test dengan dry run
      Dry run bertujuan menunjukkan “apa yang akan terjadi”, sedangkan pengujian nyata adalah ranah yang berbeda

  • Saya justru lebih suka memakai flag --commit atau --execute, dan menjadikan eksekusi default sebagai read-only (dry)
    Dengan begitu kemungkinan memicu perubahan sungguhan secara tidak sengaja jadi lebih kecil

    • Saya sudah memakai pendekatan ini selama 8 tahun terakhir, dan karena perubahan hanya terjadi jika --commit dinyatakan secara eksplisit, rasanya lebih aman
      Sebaliknya, saya lebih sering mengalami insiden karena lupa menambahkan --dry-run
    • Tool deduplikasi direktori saya juga mengikuti pola ini
      Secara default hanya membandingkan, dan baru benar-benar mengganti menjadi hard link jika memakai --execute
    • Ada juga tool yang dulu saya pakai yang mengharuskan memasukkan frasa tertentu sebelum eksekusi nyata
      Prosedur konfirmasi seperti ini efektif untuk mengurangi kesalahan
    • Secara pribadi saya juga suka flag seperti --wet-run. Dalam situasi tertentu, flag dengan makna kebalikan justru terasa lebih intuitif
    • Skrip yang baru saya buat belakangan ini juga default-nya read-only, dan untuk benar-benar menghapus harus mengetik DELETE-ACCOUNT secara manual
      Sampai sekarang saya belum pernah sekali pun menghapus akun secara tidak sengaja

  • Untuk mencegah polusi kode, persistence sebaiknya dipisahkan sebagai strategi yang bisa diinjeksi
    Menaruh if dry_run: di mana-mana bukan pendekatan yang baik
    Bahkan lebih aman jika eksekusi produksi dinyatakan secara eksplisit dengan --wet-run

    • Akan lebih baik jika perilaku aplikasi dimodelkan secara eksplisit dan ditangani secara terpusat
      Dengan begitu keputusan apakah ini dry run cukup dibuat di satu tempat saja — gaya “functional core, imperative shell”
    • Tapi kalau harus selalu mengetik rm --wet-run tempfile.tmp, itu juga merepotkan
      Mungkin lebih baik default-nya tetap eksekusi nyata, tetapi ada opsi --undo untuk membatalkan aksi terakhir
    • Saya tidak terlalu suka nama --wet-run, tetapi saya juga pernah memakai pendekatan yang default-nya dry-run dan perubahan hanya terjadi jika --no-dry-run dinyatakan
      Untuk layanan, idealnya mode aman dipilih otomatis berdasarkan lingkungan eksekusi (dev/prod)
    • Dalam kasus seperti ini, memanfaatkan design pattern bisa membantu menjaga struktur tetap rapi

  • Di artikel disebutkan bahwa “menambahkan --dry-run sejak awal ternyata sangat berguna”,
    tetapi sebenarnya flag seperti ini sering kali otomatis disarankan oleh agen coding AI (misalnya Claude)
    Bisa jadi alasan banyak tool CLI sekarang punya pola mirip adalah karena fenomena konvergensi kode berbasis agen semacam ini

    • Namun penulis juga secara langsung menyebut bahwa inspirasinya berasal dari --dry-run milik Subversion, jadi itu tetap terdengar sebagai alasan yang sangat masuk akal

  • Saya biasanya menambahkan flag --really ke utilitas CLI, sehingga default-nya tetap read-only
    Tujuannya adalah meminta prosedur konfirmasi yang disengaja untuk mencegah kesalahan

    • Dulu saya juga pernah melihat perintah dengan flag --i-meant-that.
      Itu adalah perintah untuk menghapus mesin jarak jauh, dan secara default menunggu 10 detik agar pengguna masih punya kesempatan membatalkan
      Untungnya flag itu tidak pernah disalahgunakan

  • Salah satu hal keren dari PowerShell adalah cukup menambahkan satu baris [CmdletBinding(SupportsShouldProcess)],
    maka fitur dry run -WhatIf langsung bisa digunakan secara otomatis. Ini fitur yang sangat praktis

    • Selain itu -Confirm juga ikut aktif, dan fungsi ShouldProcess bisa berinteraksi dengan ambang konfirmasi pengguna. Desainnya benar-benar keren

  • Di CLI internal yang saya kelola, saya menaruh if not dry_run: di dalam bagian pemanggilan REST API
    Dengan begitu, alih-alih benar-benar memanggil, sistem akan meninggalkan log perintah CURL sehingga kita bisa melihat request seperti apa yang akan dikirim
    Tetapi kalau keterkaitan antar-API makin rumit, simulasi akan jauh lebih sulit dan menjadi jauh lebih kompleks daripada sekadar if not dry_run:

    • Jika memungkinkan, sebaiknya struktur dibuat agar aksi nyata hanya dilakukan di satu tempat untuk mencegah polusi kode
      Saya juga memelihara banyak CLI untuk pipeline otomasi, dan menerapkan pola ini hampir ke semua tool
    • Namun ada juga pendapat bahwa memakai REST secara berlebihan di tool konsol itu tidak efisien
      Argumennya, yang lebih penting adalah membuat tool lokal dengan benar terlebih dahulu

  • Jika flag --dry-run tersebar di seluruh kode, sebaiknya terapkan pola state machine agar tiap tahap terpisah dengan jelas