Proyek Akhir

Bab 27 menutup dengan checklist keputusan kapan sebuah toolkit Bash layak "naik kelas" ke Python atau Go, lalu studi kasus laporan.py yang disambungkan ke ops.sh lewat pola orchestrator. Bab ini menutup seluruh series, bukan dengan materi baru, tapi dengan menyatukan kembali apa yang sudah ditulis di 27 bab sebelumnya jadi dua proyek utuh. Bagian 1 (Bab 1-12) membangun fondasi dari variabel sampai argumen script, Bagian 2 (Bab 13-16) menuntun otomatisasi harian di desktop pribadi milik User, Bagian 3 (Bab 17-24) menuntun administrasi server milik Sysadmin dari monitoring sampai DevOps, dan Bagian 4 (Bab 25-27) merapikan semuanya lewat kebiasaan debugging, struktur proyek, sampai kapan saatnya berpindah bahasa. Bab ini merangkai kembali script-script yang sudah tersebar di keempat bagian itu jadi dua proyek akhir: automation suite untuk desktop pribadi (28.1), dan toolkit administrasi server mini yang mengikutsertakan logging, alerting, dan keamanan sekaligus (28.2), sebelum ditutup checklist "siap produksi" yang bisa dipakai ulang untuk proyek Bash apa pun (28.3) dan penutup series berisi sumber belajar lanjutan (28.4).

28.1 Proyek End-User: Automation Suite untuk Desktop Pribadi

User yang mengikuti Bagian 2 dari awal sekarang punya lebih dari lima script tersebar di $HOME: rapikan-downloads.sh (Bab 13.3.2), organizer-media.sh (Bab 14.3.2), potongan rsync/tar untuk backup (Bab 13.2), reminder lewat notify-send (Bab 15.1), dan script setup laptop (Bab 15.4.2), belum termasuk dotfiles/ yang dikelola terpisah lewat Git dan stow (Bab 15.3, 16.4). Masalahnya bukan lagi menulis script baru, tapi mengingat script mana melakukan apa dan di mana lokasinya. Sub-bab ini menyatukan semuanya jadi satu automation suite dengan satu titik masuk, persis prinsip wrapper script yang dibahas Bab 24.3.1 untuk tim Sysadmin, cuma kali ini manfaatnya dirasakan satu User yang bekerja sendirian mengingat perintah favoritnya sendiri.

28.1.1 Rancangan Automation Suite

Rancangannya meniru pola toolkit-ops/ dari Bab 26.1.4: satu lib.sh berisi fungsi bersama, satu dispatcher sebagai titik masuk tunggal mengikuti pola case dari Bab 24.3.2, dan script-script yang sudah ada tinggal dipanggil dari dispatcher itu tanpa perlu ditulis ulang isinya. Perbedaan utama dari toolkit-ops/ ada di sisi notifikasi: server memakai alert-notifikasi.sh (Bab 20.4.2) yang mengirim pesan lewat email, Telegram, atau Slack, sementara notifikasi yang relevan untuk User di desktop cukup lewat notify-send (Bab 15.1.1), sudah langsung terlihat di layar tanpa perlu koneksi ke layanan luar. Dotfiles di ~/dotfiles/ sengaja tetap dibiarkan terpisah, bukan digabung ke dalam automation suite ini, karena keduanya menyelesaikan masalah yang berbeda: dotfiles mempersonalisasi shell itu sendiri, automation suite menjalankan tugas di atas shell yang sudah dipersonalisasi itu.

28.1.2 Struktur Direktori dan Modul Bersama

Struktur direktorinya mengikuti pola Bab 26.1.4, disesuaikan untuk kebutuhan desktop.

automation-suite/
├── lib.sh
├── suite.sh
├── rapikan-downloads.sh
├── organizer-media.sh
├── backup-dokumen.sh
└── README.md

rapikan-downloads.sh dan organizer-media.sh disalin persis dari Bab 13.3.2 dan Bab 14.3.2 tanpa perlu diubah, hanya dipindah lokasi. backup-dokumen.sh adalah pembungkus baru di sekitar teknik sinkronisasi rsync dari Bab 13.2.2, sebelumnya masih berupa potongan perintah lepas, kali ini dirapikan jadi satu script permanen. lib.sh memakai pola persis Bab 26.1.2, cuma menambah satu fungsi baru, notify(), yang membungkus notify-send dengan pengecekan command -v seperti kebiasaan Bab 27.2.3, supaya automation suite ini tetap berjalan tanpa error di mesin yang kebetulan belum memasang paket libnotify yang sesuai distronya (Bab 15.1.1), cuma kehilangan notifikasi popup-nya saja.

#!/bin/bash
# lib.sh - fungsi bersama untuk automation-suite, hanya berisi definisi

: "${LOG_FILE:=$HOME/.automation-suite.log}"

log() {
    local level="$1"
    shift
    printf '[%s] [%s] %s\n' "$(date '+%Y-%m-%d %H:%M:%S')" "$level" "$*" >> "$LOG_FILE"
}

error() {
    printf 'Error: %s\n' "$1" >&2
}

die() {
    error "$1"
    exit "${2:-1}"
}

notify() {
    log INFO "$*"
    command -v notify-send &> /dev/null && notify-send "Automation Suite" "$*"
}

Fungsi log(), error(), dan die() di atas sengaja disalin persis dari lib.sh milik toolkit-ops/ (Bab 26.1.2), bukti nyata alasan ketiganya layak dipindah ke satu library sejak awal: pola yang sama berguna baik untuk toolkit server maupun automation suite desktop, tanpa perlu ditulis ulang dari nol. notify() mencatat pesan yang sama ke log lewat log INFO sekaligus menampilkannya sebagai notifikasi popup kalau notify-send tersedia, sehingga riwayat tetap tersimpan di ~/.automation-suite.log meski User kebetulan tidak sempat melihat notifikasi popup-nya saat itu juga.

28.1.3 Implementasi Dispatcher suite.sh

suite.sh menerapkan pola dispatcher case dari Bab 24.3.2 dan pola SCRIPT_DIR/BASH_SOURCE dari Bab 26.1.3, supaya tetap berhasil menemukan lib.sh dan script-script tetangganya berapa pun direktori kerja saat suite.sh dipanggil, termasuk saat dijadwalkan lewat cron di 28.1.4 nanti.

#!/bin/bash
set -uo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "${SCRIPT_DIR}/lib.sh"

tampilkan_bantuan() {
    cat <<'USAGE'
Penggunaan: suite.sh 

Subperintah yang tersedia:
  rapikan     Rapikan folder Downloads berdasarkan ekstensi
  organizer   Rapikan dan konversi folder media (-s FOLDER -a)
  backup      Backup ~/Dokumen ke ~/Backup lewat rsync
  help        Tampilkan pesan ini
USAGE
}

cmd_rapikan() {
    "${SCRIPT_DIR}/rapikan-downloads.sh" && notify "Folder Downloads sudah dirapikan"
}

cmd_organizer() {
    "${SCRIPT_DIR}/organizer-media.sh" "$@" && notify "Folder media sudah diorganisir"
}

cmd_backup() {
    "${SCRIPT_DIR}/backup-dokumen.sh" && notify "Backup Dokumen selesai"
}

case "${1:-help}" in
    rapikan)   cmd_rapikan ;;
    organizer) shift; cmd_organizer "$@" ;;
    backup)    cmd_backup ;;
    help|*)    tampilkan_bantuan ;;
esac

Tanda kutip pada delimiter <<'USAGE' mengikuti kebiasaan Bab 26.2.1: teks bantuan ini murni statis, tidak ada variabel yang perlu di-expand, jadi bentuk berkutip jadi pilihan paling aman. Ketiga fungsi cmd_*() memanggil script yang sudah ada tanpa mengubah isinya sama sekali, lalu memanggil notify() hanya kalau script itu berhasil (operator && dari Bab 6.4.2), supaya notifikasi "selesai" tidak pernah tercetak untuk pekerjaan yang sebenarnya gagal di tengah jalan. Subperintah organizer memakai shift dari Bab 12.1.2 supaya opsi seperti -s ~/Downloads -a milik organizer-media.sh (Bab 14.3.1) tetap diteruskan apa adanya ke script aslinya, bukan ikut tertangkap sebagai argumen dispatcher.

Supaya suite.sh bisa dipanggil dari mana pun tanpa mengetik path lengkapnya, tambahkan satu alias baru ke ~/dotfiles/shell/common.sh yang sudah dibangun di Bab 16.4.2, menyatukan dua proyek Bagian 2 lewat satu baris konfigurasi.

alias suite="$HOME/automation-suite/suite.sh"

28.1.4 Verifikasi dan Pengembangan Lanjutan

Beri izin eksekusi ke seluruh script sekaligus, lalu jalankan setiap subperintah satu per satu sebelum menjadwalkannya otomatis.

chmod +x automation-suite/*.sh
suite rapikan
suite backup
suite organizer -s ~/Downloads -a

cat ~/.automation-suite.log

Isi ~/.automation-suite.log seharusnya menunjukkan satu baris INFO untuk tiap subperintah yang berhasil dijalankan, konsisten dengan format log() di 28.1.2. Jalankan juga shellcheck (Bab 25.4.1) ke seluruh file sebelum dipakai rutin, kebiasaan yang sama pentingnya untuk script pribadi seperti untuk toolkit tim.

shellcheck automation-suite/*.sh

Setelah yakin ketiga subperintah berjalan benar, jadwalkan suite rapikan dan suite backup lewat cron memakai teknik Bab 15.1.2, dan inisialisasi automation-suite/ sebagai repository Git tersendiri mengikuti Bab 26.3.2, terpisah dari repository dotfiles/. Pengembangan wajar berikutnya: menambah opsi --dry-run ke backup-dokumen.sh mengikuti kebiasaan Bab 13.1.4, atau menambah subperintah setup yang memanggil script setup laptop dari Bab 15.4.2 begitu automation suite ini perlu dipindahkan ke laptop baru yang benar-benar kosong. Sub-bab berikutnya menerapkan pola yang persis sama untuk kebutuhan yang jauh lebih berisiko: administrasi server produksi milik Sysadmin.

28.2 Proyek Sysadmin: Toolkit Administrasi Server Mini

toolkit-ops/ dari Bab 26.1.4 sudah menyatukan lima script inti (lib.sh, ops.sh, deploy-pipeline.sh, provision-server.sh, toolkit-keamanan.sh, alert-notifikasi.sh) plus laporan.py yang ditambahkan Bab 27.3.2. Tiga script sysadmin lain masih tertinggal di luar struktur ini: audit-server.sh (Bab 17.4.2), dashboard-server.sh (Bab 19.4.2), dan cek-konektivitas.sh (Bab 22.4.2), ketiganya ditulis sebelum lib.sh bersama ada di Bab 26, jadi logging-nya masih berdiri sendiri lewat printf langsung. Sub-bab ini menuntaskan penyatuan itu, sekaligus menghubungkan hasil audit dan cek konektivitas ke kirim_alert() (Bab 20.4.2), sesuatu yang baru sekadar disarankan di troubleshooting Bab 23.4.4 tapi belum pernah benar-benar diimplementasikan.

28.2.1 Rancangan Cakupan Toolkit

Dari tiga script yang tertinggal, dua di antaranya, audit-server.sh dan cek-konektivitas.sh, cocok dipindah jadi subperintah baru di ops.sh karena sifatnya sekali jalan (satu eksekusi, satu laporan, lalu selesai), persis pola cmd_*() yang sudah ada di Bab 24.3.3. dashboard-server.sh sengaja tidak dipindah: script itu berjalan sebagai tampilan langsung yang terus menyegarkan diri sampai ditekan Ctrl+C (Bab 19.4.1), sifat interaktif yang tidak cocok dipanggil lewat jalankan_jauh() milik ops.sh (Bab 24.3.3), yang memakai ssh tanpa alokasi pseudo-terminal. Dashboard ini tetap dijalankan langsung lewat ssh -t saat memang dibutuhkan tampilan interaktif, dan cukup didokumentasikan sebagai tool terpisah di README.md milik toolkit-ops/, bukan dipaksakan masuk ke pola dispatcher yang sebenarnya tidak cocok untuknya. Kejujuran soal batas pola desain semacam ini lebih berguna daripada memaksakan satu pola ke semua kasus.

28.2.2 Menyatukan Logging dan Keamanan

audit-server.sh versi Bab 17.4.2 mencetak hasil audit lewat printf langsung ke stdout atau file output manual (opsi -o), tanpa pernah melewati log() milik lib.sh. Menyatukannya ke toolkit-ops/ berarti menambahkan satu baris di akhir fungsi cek_disk(): begitu status pengembaliannya bukan nol (disk sudah melewati ambang batas), panggil kirim_alert() dari Bab 20.4.2, bukan cuma mencetak baris [PERINGATAN] yang gampang terlewat kalau tidak ada yang sedang menonton terminal saat itu juga.

cek_disk() {
    local status=0
    local fs pct target angka_pct kunci

    while read -r fs pct target; do
        [[ "$fs" == "Filesystem" ]] && continue
        angka_pct=${pct%\%}
        if (( angka_pct >= THRESHOLD )); then
            kunci="disk_${fs//\//_}"
            kirim_alert "$kunci" "Disk $fs di $(hostname) tersisa $((100 - angka_pct))%"
            status=1
        fi
    done < <(df -h --output=source,pcent,target)

    return "$status"
}

Dua detail wajib diperhatikan supaya pemanggilan ini benar. Pertama, kirim_alert() menerima dua argumen menurut Bab 20.4.2, kunci untuk pelacakan cooldown lewat sudah_cooldown() (Bab 20.4.3), baru argumen kedua berupa pesannya, jadi cukup satu baris kirim_alert saja tanpa perlu log WARN terpisah, karena kirim_alert() sendiri sudah memanggil log WARN "$pesan" persis di baris pertama isinya. Kedua, sudah_cooldown() memakai kunci apa adanya sebagai nama file di $STATE_DIR/$kunci, sementara $fs hasil df lazimnya berbentuk path seperti /dev/sda1, kalau dipakai langsung sebagai kunci tanda garis miringnya akan diartikan sebagai pemisah direktori dan gagal dibuat sebagai satu file. Substitusi ${fs//\//_} dari Bab 9.4 (mengganti setiap / jadi _) menghindari jebakan ini, sesuatu yang tidak perlu dipikirkan di versi awal Bab 20.4.2 karena contohnya cuma memeriksa satu partisi root dengan kunci tetap disk_root, bukan berulang untuk banyak filesystem sekaligus seperti di sini.

Perubahan yang sama diterapkan ke cek-konektivitas.sh (Bab 22.4.2): begitu cek_port() atau cek_endpoint() (Bab 22.2) melaporkan kegagalan untuk satu server, panggil kirim_alert() dengan kunci unik per server (misalnya conn_app1) supaya cooldown-nya tidak saling menimpa antar server, bukan cuma mencetak status merah di terminal. toolkit-keamanan.sh sendiri (Bab 23.4.3) tidak perlu perubahan apa pun, karena sejak awal sudah ditulis memakai lib.sh dan sudah terhubung ke kirim_alert() persis seperti disinggung Bab 23.4.4. Menyatukan ketiganya lewat jalur alert yang sama berarti Sysadmin cukup memantau satu kanal notifikasi (Telegram atau Slack, Bab 20.3) untuk tiga sumber masalah berbeda: disk penuh, service tidak merespons, dan port mencurigakan.

28.2.3 Implementasi Dispatcher Diperluas

Struktur direktori toolkit-ops/ bertambah dua file yang sudah direfactor di 28.2.2, plus direktori tests/ dari Bab 26.4.

toolkit-ops/
├── lib.sh
├── ops.sh
├── deploy-pipeline.sh
├── provision-server.sh
├── toolkit-keamanan.sh
├── alert-notifikasi.sh
├── audit-server.sh
├── cek-konektivitas.sh
├── laporan.py
├── tests/
└── README.md

ops.sh sendiri tinggal menambah tiga baris di case statement-nya, melanjutkan persis dari versi Bab 24.3.3 yang sudah kedatangan subperintah report di Bab 27.3.2. SCRIPT_DIR, source lib.sh, dan fungsi jalankan_jauh() tetap sama seperti Bab 26.1.3 dan 24.3.3, tidak ada yang berubah selain case-nya. Path yang dipanggil ketiga fungsi baru ini sengaja menunjuk /usr/local/bin/ di server tujuan, bukan /opt/toolkit-ops/: /opt/toolkit-ops/ adalah lokasi repository ini sendiri di mesin operator yang menjalankan ops.sh, sedangkan /usr/local/bin/ adalah lokasi standar di server tujuan untuk script kustom yang dipakai luas di seluruh sistem, persis konvensi yang sudah dipakai audit-server.sh sejak Bab 18.4.1. Ketiga script itu perlu disalin dulu ke lokasi ini di server tujuan sebagai bagian dari provision-server.sh (Bab 24.4.2), sebelum subperintah barunya bisa dipanggil.

cmd_audit() {
    jalankan_jauh "/usr/local/bin/audit-server.sh"
}

cmd_cek() {
    jalankan_jauh "/usr/local/bin/cek-konektivitas.sh"
}

cmd_keamanan() {
    jalankan_jauh "sudo /usr/local/bin/toolkit-keamanan.sh -h $HOST"
}

case "${1:-help}" in
    deploy)   cmd_deploy ;;
    rollback) cmd_rollback ;;
    status)   cmd_status ;;
    logs)     cmd_logs "${2:-50}" ;;
    audit)    cmd_audit ;;
    cek)      cmd_cek ;;
    keamanan) cmd_keamanan ;;
    report)   python3 "${SCRIPT_DIR}/laporan.py" --minggu-ini | jq -r '.ringkasan' ;;
    help|*)   tampilkan_bantuan ;;
esac

cmd_keamanan() sengaja menambahkan sudo di depan pemanggilan jarak jauhnya, konsisten dengan toolkit-keamanan.sh yang menurut Bab 23.4.3 wajib dijalankan sebagai root untuk bisa mengubah aturan iptables. Satu syarat wajib dipenuhi dulu supaya baris ini tidak macet: jalankan_jauh() memanggil ssh tanpa opsi -t, sehingga tidak ada pseudo-terminal yang dialokasikan (28.2.1) dan sudo tidak punya cara menampilkan prompt password sama sekali kalau sampai dibutuhkan. Baris sudoers baru wajib ditambahkan di server, mengikuti prinsip hak akses minimal yang sama seperti Bab 23.3.4.

deploy ALL=(root) NOPASSWD: /usr/local/bin/toolkit-keamanan.sh -h app.example.com

Argumen -h app.example.com sengaja dituliskan eksplisit, bukan dibiarkan kosong, memakai nilai $HOST yang memang sudah tetap sejak dideklarasikan di ops.sh (Bab 24.3.3). Menurut dokumentasi resmi sudoers, entri tanpa argumen sama sekali membolehkan perintah itu dijalankan dengan argumen apa pun, jadi kalau baris di atas ditulis tanpa -h app.example.com, deploy bisa saja menjalankan toolkit-keamanan.sh sebagai root ke hostname sembarang, bukan cuma ke server yang memang dikelola ops.sh ini, pelanggaran kecil terhadap prinsip hak akses minimal yang persis sama seperti alasan cmd_rollback() di Bab 24.3.3 mengunci argumen systemctl-nya sampai ke nama service-nya. Tanpa baris sudoers ini sama sekali, ops.sh keamanan akan tampak macet tanpa pesan error yang jelas, menunggu password yang memang tidak pernah bisa diketik lewat sesi ssh non-interaktif semacam ini. Setelah baris ini aktif, tim yang memanggil ops.sh keamanan tidak perlu ingat detail hak akses ini sama sekali, persis prinsip wrapper script Bab 24.3.1: kompleksitasnya disembunyikan di balik satu subperintah yang gampang diingat.

28.2.4 Verifikasi, Pengujian, dan Penjadwalan

Uji tiap subperintah baru satu per satu dari direktori mana pun, mengulang kebiasaan verifikasi SCRIPT_DIR di Bab 26.1.3.

cd /tmp && /opt/toolkit-ops/ops.sh audit
/opt/toolkit-ops/ops.sh cek
/opt/toolkit-ops/ops.sh keamanan

Jalankan ulang bats tests/ (Bab 26.4.3) untuk memastikan perubahan di audit-server.sh dan cek-konektivitas.sh tidak mematahkan test yang sudah ada, lalu tambahkan test case baru khusus untuk memastikan kirim_alert() benar-benar terpanggil saat cek_disk() mendeteksi disk melewati ambang batas, memakai pola run yang sama seperti Bab 26.4.2. Jalankan shellcheck (Bab 25.4.1) ke seluruh file yang berubah, idealnya lewat pipeline CI/CD yang sudah dibahas Bab 24.1 dan 25.4.3, supaya pengecekan ini berjalan otomatis setiap kali ada perubahan baru, bukan diingat-ingat manual oleh satu orang saja.

shellcheck toolkit-ops/*.sh
bats tests/

Setelah lolos, jadwalkan ops.sh audit lewat systemd timer harian mengikuti pola Bab 18.4.2, commit seluruh perubahan dengan pesan yang jelas (Bab 26.3.3), lalu beri tag rilis baru seperti v1.1.0 mengikuti kebiasaan Bab 26.3.4, menandai titik toolkit ini resmi mengikutsertakan audit, cek konektivitas, dan alerting terpadu. Dua proyek di 28.1 dan 28.2 ini membuktikan satu hal: seluruh series sebenarnya sudah menyiapkan komponennya sejak jauh-jauh hari, bab-bab terakhir ini cuma merangkainya jadi satu kesatuan yang benar-benar siap dipakai sehari-hari.

28.3 Checklist "Siap Produksi" untuk Script Bash

Dua proyek di 28.1 dan 28.2 menggabungkan puluhan teknik dari 27 bab sebelumnya, cukup banyak sampai gampang lupa satu-dua kebiasaan penting saat menulis toolkit baru dari nol. Sub-bab ini merangkumnya jadi satu checklist siap pakai, dikelompokkan jadi lima kategori: keamanan dan validasi input, reliabilitas dan penanganan error, observabilitas lewat logging dan alerting, dokumentasi dan kolaborasi, serta testing dan otomatisasi CI/CD. Checklist ini bukan daftar wajib yang harus seratus persen dipenuhi setiap script kecil, tapi rujukan cepat untuk menilai seberapa siap sebuah script dilepas ke produksi tanpa pengawasan penuh.

28.3.1 Keamanan dan Validasi Input

• Setiap variabel yang menampung path atau argumen dikutip ganda, dan pemanggilan perintah dinamis memakai array, bukan eval atau interpolasi string (Bab 23.1)
• Input dari luar (argumen, environment variable, response API) divalidasi lewat regex atau case sebelum dipakai, bukan dipercaya begitu saja (Bab 23.2.1)
• Script yang mengubah state sistem aman dijalankan berulang kali tanpa efek samping ganda, lewat pengecekan kondisi sebelum bertindak (Bab 23.2.3) dan flock untuk mencegah eksekusi ganda bersamaan (Bab 23.2.4)
• Kredensial dan secret disimpan di luar repository script, bukan ditulis langsung di dalam kode (Bab 23.4.3, 24.1.4)

28.3.2 Reliabilitas dan Penanganan Error

• set -euo pipefail aktif di baris awal, dengan pengecualian yang disadari sengaja kalau memang ada (Bab 25.1.5)
• trap ... EXIT membersihkan file sementara atau melepas lock sebelum script benar-benar berhenti, termasuk saat berhenti karena sinyal (Bab 25.2)
• Pesan error menyebut apa yang gagal dan konteks yang relevan (nama file, host, exit code), bukan sekadar "gagal" atau "error" polos (Bab 25.3.1)
• Exit code yang dipakai bermakna dan konsisten, mengacu ke konvensi yang sama di seluruh toolkit (Bab 25.3.3, Lampiran B)

28.3.3 Observabilitas: Logging dan Alerting

• Seluruh script dalam satu toolkit memakai fungsi log() yang sama dari satu lib.sh bersama, bukan implementasi berbeda-beda di tiap file (Bab 19.2.2, 26.1.2)
• Kegagalan yang butuh perhatian manusia terhubung ke jalur alert (email, Telegram, atau Slack), lengkap dengan mekanisme cooldown supaya tidak membanjiri notifikasi (Bab 20.4.3)
• Log rutin dirotasi supaya tidak memenuhi disk dari waktu ke waktu (Bab 19.2.4)

28.3.4 Dokumentasi dan Kolaborasi

• Setiap script punya komentar header berisi deskripsi, dependency, dan contoh pemakaian (Bab 26.2.2), plus opsi -h/--help yang konsisten (Bab 26.2.3)
• README.md di root proyek menjelaskan prasyarat, instalasi, dan daftar script yang tersedia, diperbarui di komit yang sama dengan perubahan perilakunya (Bab 26.2.4)
• Proyek dikelola lewat Git dengan pesan commit yang jelas dan .gitignore yang mencegah secret ikut ter-commit (Bab 26.3.2, 26.3.3)

28.3.5 Testing dan Otomatisasi CI/CD

• shellcheck berjalan bersih tanpa warning yang diabaikan tanpa alasan jelas (Bab 25.4.2)
• Fungsi-fungsi kritis punya test case bats yang mencakup jalur sukses maupun jalur gagal (Bab 26.4.2)
• shellcheck dan bats berjalan otomatis di pipeline CI/CD setiap ada perubahan, bukan diingat-ingat manual (Bab 24.1, 25.4.3, 26.4.3)

Tabel berikut merangkum kelima kategori di atas jadi satu pertanyaan kunci per kategori, cara cepat menilai kesiapan sebuah script tanpa perlu membuka checklist lengkapnya setiap kali.

28.4 Penutup dan Sumber Belajar Lanjutan

Series ini dimulai dari pertanyaan paling dasar, apa itu shell dan Bash (Bab 1.1), dan berakhir di toolkit administrasi server yang menyatukan deployment, monitoring, alerting, dan keamanan dalam satu dispatcher yang aman dipakai tim (Bab 28.2). Jarak antara keduanya bukan cuma soal bertambahnya sintaks yang dikuasai, tapi perubahan cara berpikir: dari sekadar mengetik perintah satu per satu di terminal, jadi merancang toolkit yang aman divalidasi (Bab 23), jelas errornya saat gagal (Bab 25), dan bisa dipercaya orang lain karena terdokumentasi serta teruji (Bab 26). Checklist di 28.3 adalah ringkasan cara berpikir itu, layak dibuka ulang setiap kali memulai proyek Bash baru, bukan cuma sekali dibaca lalu dilupakan.

28.4.1 Melangkah Setelah Series Ini

Empat lampiran di akhir series ini dirancang sebagai rujukan cepat sehari-hari setelah seluruh materi utama selesai dibaca: cheat sheet perintah dan syntax penting (Lampiran A), daftar exit code dan artinya (Lampiran B), kumpulan snippet siap pakai (Lampiran C), dan glosarium istilah yang sudah dipakai sepanjang series (Lampiran D). Keempatnya lebih cocok dibuka sambil menulis script sungguhan, dibanding dibaca berurutan seperti bab-bab sebelumnya.

Untuk pendalaman lebih jauh, kebiasaan yang sudah dipraktikkan sepanjang series ini tetap berlaku: rujuk GNU Bash Reference Manual dan spesifikasi POSIX Shell Command Language sebagai sumber utama setiap kali ragu soal perilaku sebuah builtin, silang-cek dengan man page tool terkait, dan pakai ShellCheck wiki untuk memahami alasan di balik setiap peringatan lint yang muncul. Daftar lengkap sumber yang jadi rujukan penyusunan series ini ada di bagian Referensi, layak dibaca lagi bagi yang ingin menelusuri topik tertentu lebih dalam dari sumber aslinya. Begitu toolkit yang kita rawat mulai menyentuh sinyal-sinyal di Bab 27.1, struktur data bersarang, kebutuhan unit test granular, atau distribusi ke banyak mesin tak terkontrol, checklist keputusan di Bab 27.3.3 sudah siap dipakai ulang untuk menimbang langkah berikutnya, entah itu tetap di Bash atau mulai menulis sebagian toolkit dalam Python maupun Go.

Bash sendiri jarang berubah drastis antar rilis, tapi ekosistem di sekitarnya terus bergerak, distro baru, versi systemd baru, kebiasaan tim yang berubah. Kebiasaan paling tahan lama yang bisa dibawa dari series ini bukan hafalan sintaks, tapi cara memverifikasi klaim teknis lewat dokumentasi resmi, cara menulis script yang jujur soal risikonya sendiri, dan cara merancang toolkit yang tetap bisa dirawat orang lain setelah kita tidak lagi ada di sana untuk menjelaskannya. Selamat merawat toolkit masing-masing, dan sampai jumpa di proyek Bash berikutnya.