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. Contoh Dockerfile dan file Compose untuk aplikasi web plus database ada di Docker untuk pemula.

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.

Contoh pipeline GitLab CI sederhana

Pipeline berikut menjalankan test di setiap push, lalu deploy ke staging otomatis dan ke production secara manual:

stages: [test, deploy]

test:
  stage: test
  image: php:8.3
  script:
    - composer install --no-interaction
    - php artisan test

deploy_staging:
  stage: deploy
  script: ./deploy.sh staging
  only: [main]

deploy_production:
  stage: deploy
  script: ./deploy.sh production
  only: [main]
  when: manual

Isi deploy.sh bisa sesederhana menarik kode terbaru di server, menjalankan migrasi, lalu me-restart layanan. Yang penting, langkahnya tertulis dan sama setiap kali.

Target ketersediaan dan artinya

Makin tinggi target, makin mahal infrastrukturnya: server cadangan, database replika, dan tim yang siaga. Pilih target yang sesuai kebutuhan pelayanan dan anggaran klien.

Pertanyaan yang sering diajukan

Server sendiri atau cloud? Keduanya bisa dikelola dengan prinsip yang sama. Perbandingan biaya dan risikonya ada di artikel menjelaskan keputusan teknis kepada klien.

Deploy di jam kerja atau malam hari? Untuk sistem pelayanan kesehatan, pilih waktu dengan pengguna paling sedikit, tetapi pastikan ada orang yang siaga bila perlu rollback. Deploy tengah malam tanpa pengawasan justru berisiko.

Berapa lama backup disimpan? Tergantung kebutuhan klien dan regulasi. Pola umum: harian disimpan 7–14 hari, mingguan 1–3 bulan, dan bulanan lebih lama.

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.