DevOps untuk Tim Kecil: Git, CI/CD, Container, Monitoring, dan Backup

DevOps sering terdengar seperti urusan perusahaan besar dengan tim khusus. Padahal prinsip dasarnya justru paling terasa manfaatnya di tim kecil, ketika satu orang programmer juga harus mengurus server dan menangani telepon klien saat aplikasi mati. Tujuannya sederhana: mengubah kode menjadi layanan yang berjalan stabil, dengan cara yang bisa diulang dan tidak bergantung pada ingatan satu orang.

1. Semua kode di Git, termasuk konfigurasi

• Simpan kode aplikasi, skrip database (migration), dan konfigurasi server di repository Git.
• Gunakan alur sederhana: branch main selalu siap rilis, dan pekerjaan baru dikerjakan di branch fitur lalu digabung lewat merge request.
• Jangan pernah menyimpan password, API key, atau sertifikat di Git. Gunakan variabel lingkungan (.env) atau fitur secret di platform CI.

2. Pisahkan lingkungan

Minimal ada tiga lingkungan:

Menguji langsung di production, apalagi di sistem kesehatan, adalah resep untuk data pasien yang tercampur dengan data uji coba.

3. CI/CD: otomatiskan yang berulang

Continuous Integration menjalankan test otomatis setiap kali ada kode baru yang di-push. Continuous Deployment mengirim kode yang lolos test ke server secara otomatis. Alatnya tersedia gratis: GitLab CI, GitHub Actions, atau layanan hosting yang otomatis membangun situs dari repository.

Pipeline sederhana untuk tim kecil:

1. Install dependensi.
2. Jalankan linter dan test.
3. Build aplikasi atau image container.
4. Deploy ke staging secara otomatis.
5. Deploy ke production setelah disetujui, dengan satu klik.

Manfaat terbesarnya bukan kecepatan, melainkan konsistensi. Langkah deploy tidak lagi bergantung pada ingatan orang yang biasa melakukannya.

4. Container untuk lingkungan yang seragam

Container (misalnya Docker) membungkus aplikasi beserta versi runtime dan library-nya, sehingga "di laptop saya jalan" juga berarti jalan di server. Untuk tim kecil, Docker Compose sudah cukup untuk menjalankan aplikasi, database, dan layanan pendukung dalam satu file konfigurasi. Kubernetes baru perlu dipertimbangkan ketika skala dan jumlah layanan benar-benar menuntutnya.

5. Monitoring dan log

Anda seharusnya tahu aplikasi bermasalah sebelum klien menelepon. Minimal pantau:

• Uptime: cek otomatis setiap menit dari luar server, lengkap dengan notifikasi ke Telegram, email, atau WhatsApp.
• Sumber daya: CPU, RAM, dan terutama sisa disk.
• Error aplikasi: log terpusat yang bisa dicari, bukan file log yang tersebar di banyak server.
• Integrasi eksternal: respons dari layanan seperti BPJS atau SATUSEHAT, karena gangguan di sana juga akan dilaporkan pengguna sebagai "aplikasi error".

Data uptime ini juga menjadi dasar laporan SLA kepada klien. Hitung batas downtime Anda dengan kalkulator SLA dan uptime.

6. Backup yang benar-benar teruji

• Terapkan aturan 3-2-1: tiga salinan, dua media, satu di lokasi lain.
• Otomatiskan backup, dan kirim notifikasi jika backup gagal.
• Lakukan uji restore secara berkala, misalnya sebulan sekali, ke server terpisah.
• Catat berapa lama proses restore berlangsung. Angka ini menentukan seberapa cepat Anda bisa pulih dari bencana.

Perkirakan ruang yang dibutuhkan dengan kalkulator storage dan backup.

7. Dokumentasikan runbook

Runbook adalah catatan langkah untuk situasi rutin dan darurat: cara deploy, cara rollback, cara restore database, dan siapa yang harus dihubungi. Saat server bermasalah pukul dua pagi, runbook yang jelas jauh lebih berharga daripada ingatan.

Mulai dari mana?

Jangan mencoba menerapkan semuanya sekaligus. Urutan yang masuk akal untuk tim kecil: Git dan pemisahan secret → backup otomatis dan uji restore → monitoring uptime dan disk → pipeline CI sederhana → container. Setiap langkah sudah mengurangi risiko secara nyata.