Bash Scripting Automation untuk Developer: Kerja Lebih Cepat

Kamu habiskan berapa menit sehari untuk mengetik perintah yang sama berulang kali? git pull, docker-compose up, npm install, restart service, cek log. Kalau dijumlah seminggu, angkanya bikin mual.

Ini bukan soal malas. Ini soal opportunity cost. Setiap menit yang kamu buang untuk pekerjaan mekanis adalah menit yang tidak kamu pakai untuk memecahkan masalah yang sebenarnya. Bash scripting automation untuk developer bukan topik glamor—tidak ada konferensi besar yang membahasnya dengan slide penuh animasi—tapi dampaknya nyata dan langsung terasa.

Artikel ini bukan pengantar "apa itu bash". Kamu sudah tahu. Ini tentang pola-pola spesifik yang saya pakai sehari-hari sebagai backend engineer yang mengelola beberapa proyek sekaligus, dan bagaimana kamu bisa mengadaptasinya dalam satu sore.

Kenapa Bash, Bukan Python atau Zsh?

Pertanyaan wajar. Python lebih ekspresif, Zsh punya plugin ekosistem yang kaya. Tapi bash punya satu keunggulan yang sering diabaikan: dia ada di mana-mana.

Server Ubuntu 22.04 yang baru kamu spin up? Bash ada. Container Alpine minimal? Bash ada (atau bisa diinstall dalam satu baris). Script yang kamu tulis di laptop macOS akan jalan di VPS tanpa modifikasi—selama kamu tidak pakai fitur bash 5.x yang belum tentu tersedia di semua distro.

Python butuh virtual environment, dependency, versi yang cocok. Bash butuh... bash. Untuk automation task yang sifatnya glue code—menghubungkan tool satu dengan lainnya—bash adalah pilihan paling pragmatis.

Satu catatan: saya pakai bash 5.2 di macOS (via Homebrew) dan bash 5.1 di Ubuntu 22.04. Kalau kamu masih di bash 3.x bawaan macOS, upgrade dulu:

brew install bash
echo '/opt/homebrew/bin/bash' | sudo tee -a /etc/shells
chsh -s /opt/homebrew/bin/bash

Struktur Script yang Tidak Memalukan

Script bash yang ditulis asal-asalan adalah technical debt paling cepat menumpuk. Saya punya template yang saya pakai untuk semua script baru:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# ============================================================
# Nama script  : deploy.sh
# Deskripsi    : Deploy aplikasi ke staging/production
# Penggunaan   : ./deploy.sh [staging|production]
# Dependensi   : git, docker, curl
# ============================================================

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
LOG_FILE="${SCRIPT_DIR}/deploy.log"
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")

log() {
  echo "[${TIMESTAMP}] $*" | tee -a "${LOG_FILE}"
}

error() {
  log "ERROR: $*" >&2
  exit 1
}

check_deps() {
  local deps=("git" "docker" "curl")
  for dep in "${deps[@]}"; do
    command -v "${dep}" &>/dev/null || error "Dependensi tidak ditemukan: ${dep}"
  done
}

main() {
  local env="${1:-staging}"
  [[ "${env}" =~ ^(staging|production)$ ]] || error "Environment tidak valid: ${env}"
  
  check_deps
  log "Memulai deploy ke ${env}..."
  # logic utama di sini
}

main "$@"

Tiga baris paling penting di awal:

set -e: keluar kalau ada perintah yang gagal
set -u: error kalau ada variabel yang belum didefinisikan
set -o pipefail: tangkap kegagalan di tengah pipeline

Tanpa ini, script kamu akan terus jalan meski ada yang salah, dan debugging-nya mimpi buruk.

Pola Automation yang Paling Sering Saya Pakai

1. Git Workflow Automation

Saya punya script gstart yang menggantikan ritual git branch baru:

#!/usr/bin/env bash
set -euo pipefail

gstart() {
  local ticket="${1:?Masukkan nomor tiket, contoh: gstart PROJ-123}"
  local description="${2:?Masukkan deskripsi singkat}"
  local branch_name
  
  # Normalisasi: lowercase, spasi jadi dash
  branch_name=$(echo "${ticket}-${description}" | tr '[:upper:]' '[:lower:]' | tr ' ' '-' | tr -cd '[:alnum:]-')
  
  git checkout main
  git pull origin main
  git checkout -b "${branch_name}"
  
  echo "Branch '${branch_name}' siap. Selamat coding."
}

gstart "$@"

Dipanggil dengan gstart PROJ-123 "fix login bug", hasilnya branch proj-123-fix-login-bug yang sudah sync dengan main.

2. Environment Setup Otomatis

Onboarding developer baru di proyek sering memakan waktu setengah hari. Script ini memotongnya jadi 10 menit:

#!/usr/bin/env bash
set -euo pipefail

BASE_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

setup_env() {
  echo "==> Mengecek dependensi sistem..."
  local required=("node" "docker" "psql")
  for cmd in "${required[@]}"; do
    if ! command -v "${cmd}" &>/dev/null; then
      echo "[SKIP] ${cmd} tidak ditemukan—install manual dulu."
    else
      echo "[OK]   ${cmd} $(${cmd} --version 2>&1 | head -1)"
    fi
  done

  echo "==> Menyalin .env file..."
  [[ -f "${BASE_DIR}/.env" ]] || cp "${BASE_DIR}/.env.example" "${BASE_DIR}/.env"

  echo "==> Menginstall Node dependencies..."
  npm ci --silent

  echo "==> Menjalankan migrasi database..."
  npm run db:migrate

  echo "==> Selesai. Jalankan 'npm run dev' untuk mulai."
}

setup_env

3. Log Monitoring dengan Alert Sederhana

Saya tidak pakai tool monitoring berbayar untuk proyek kecil. Script ini cukup:

#!/usr/bin/env bash
set -euo pipefail

LOG_PATH="/var/log/app/error.log"
WEBHOOK_URL="${SLACK_WEBHOOK_URL:?Set SLACK_WEBHOOK_URL dulu}"
KEYWORD="CRITICAL"

watch_log() {
  tail -F "${LOG_PATH}" | while IFS= read -r line; do
    if echo "${line}" | grep -q "${KEYWORD}"; then
      local payload
      payload=$(printf '{"text": "🚨 *Alert*: %s"}' "${line}")
      curl -s -X POST -H 'Content-type: application/json' \
        --data "${payload}" \
        "${WEBHOOK_URL}" &>/dev/null
    fi
  done
}

watch_log

Jalankan sebagai systemd service atau di dalam tmux, dan kamu dapat notifikasi Slack setiap kali ada log CRITICAL tanpa bayar tool monitoring.

Mengelola Banyak Script: Jangan Taruh di ~/.bashrc

Kesalahan klasik: semua fungsi ditumpuk di ~/.bashrc sampai file itu jadi 800 baris yang tidak ada yang berani disentuh.

Struktur yang lebih waras:

~/.local/bin/
├── gstart          # git workflow
├── deploy          # deployment script
├── dbdump          # backup database
└── logwatch        # log monitoring

~/.config/shell/
├── aliases.sh      # alias pendek
├── functions.sh    # fungsi kompleks
└── env.sh          # environment variables

Di ~/.bashrc atau ~/.bash_profile, cukup satu baris:

for f in ~/.config/shell/*.sh; do source "$f"; done

Semua script di ~/.local/bin/ bisa langsung dipanggil kalau direktori itu ada di $PATH:

export PATH="$HOME/.local/bin:$PATH"

Rapi, mudah di-version control, dan tidak ada yang takut edit.

Bash Scripting Automation untuk Developer: Testing Script Kamu

Ini bagian yang paling sering dilewati. Script tanpa test adalah bom waktu.

Saya pakai bats-core (versi 1.10.0 saat artikel ini ditulis) untuk testing bash script:

# Install
npm install -g bats
# atau
brew install bats-core

Contoh test untuk fungsi gstart:

#!/usr/bin/env bats

setup() {
  # Buat repo git temporary untuk testing
  TEST_DIR=$(mktemp -d)
  cd "${TEST_DIR}"
  git init -q
  git commit --allow-empty -m "init" -q
}

teardown() {
  rm -rf "${TEST_DIR}"
}

@test "gstart membuat branch dengan format yang benar" {
  source "${BATS_TEST_DIRNAME}/../scripts/gstart.sh"
  run gstart "PROJ-123" "fix login bug"
  [ "$status" -eq 0 ]
  run git branch --show-current
  [ "$output" = "proj-123-fix-login-bug" ]
}

@test "gstart gagal tanpa argumen" {
  source "${BATS_TEST_DIRNAME}/../scripts/gstart.sh"
  run gstart
  [ "$status" -ne 0 ]
}

Jalankan dengan bats tests/. Kalau kamu sudah setup CI, tambahkan ini ke pipeline GitHub Actions:

- name: Test bash scripts
  run: |
    npm install -g bats
    bats tests/

Perbandingan: Bash vs Alternatif untuk Automation Task

Kriteria	Bash	Python	Makefile	Just
Ketersediaan	✅ Ada di mana-mana	⚠️ Perlu install + venv	✅ Hampir universal	❌ Perlu install
Kurva belajar	Sedang	Rendah	Rendah	Rendah
Debugging	❌ Menyebalkan	✅ Mudah	⚠️ Terbatas	✅ Mudah
Cocok untuk	Glue code, sysadmin	Data processing, complex logic	Task runner	Task runner modern
Interop dengan shell	✅ Native	⚠️ Via subprocess	✅ Native	✅ Native
Testing	⚠️ bats-core	✅ pytest	❌ Sulit	❌ Sulit

Kesimpulan dari tabel ini: bash untuk glue code dan sysadmin task, Python kalau logic-nya sudah kompleks dan butuh library eksternal. Jangan pakai bash untuk parsing JSON yang rumit—pakai jq atau pindah ke Python.

Tiga Kebiasaan yang Bikin Script Bash Kamu Tidak Jadi Sampah

Pertama, selalu validasi input. Jangan asumsikan user (termasuk diri sendiri di masa depan) akan memanggil script dengan benar.

# Buruk
rm -rf "${DIR}/"

# Baik
[[ -n "${DIR}" ]] || error "DIR tidak boleh kosong"
[[ -d "${DIR}" ]] || error "${DIR} bukan direktori yang valid"
rm -rf "${DIR}/"

Kedua, gunakan shellcheck. Tool ini gratis, bisa diinstall via brew install shellcheck atau apt install shellcheck, dan menangkap 90% kesalahan umum sebelum script dijalankan. Integrasi ke editor kamu sekarang juga.

Ketiga, log semuanya. Script yang jalan di background tanpa log adalah misteri yang tidak menyenangkan untuk di-debug jam 2 pagi.

exec > >(tee -a /var/log/myscript.log) 2>&1
echo "Script dimulai: $(date)"

Satu baris itu di awal script, dan semua output—termasuk stderr—masuk ke log file sekaligus tetap tampil di terminal.

Kesimpulan: Mulai dari Satu Script Besok

Bash scripting automation untuk developer bukan tentang menulis script yang canggih dan kompleks. Ini tentang mengidentifikasi satu task yang kamu lakukan berulang minggu ini, dan mengautomasi-nya sekarang.

Besok pagi, sebelum mulai kerja: buka terminal, ketik which bash, pastikan versinya 5.x, lalu tulis satu script kecil dengan template yang ada di artikel ini. Mulai dari yang paling sering kamu lakukan—mungkin git workflow, mungkin restart service, mungkin deploy ke staging.

Kalau kamu mau lihat bagaimana saya mengorganisir dotfiles dan script-script ini dalam setup self-hosted yang lebih lengkap, cek artikel tentang manajemen dotfiles dengan GNU Stow.

Install shellcheck sekarang. Tidak ada alasan untuk tidak.