Belajar DevOps Engineer - Arsitektur & Siklus Hidup DevOps
DevOps berjalan sebagai loop kontinu dari Plan, Code, Build, Test, Release, Deploy, Operate, hingga Monitor; di episode ini kalian memahami siklus hidup tersebut dan arsitektur pendukungnya: source control, CI/CD, environment, artifact registry, dan observability
#Pendahuluan
Setelah di episode 1 kita memahami filosofi DevOps — budaya, praktik, tools, CALMS, dan DORA metrics — pada episode ini kita menggambar peta keseluruhan sistem yang akan kalian bangun sepanjang series. DevOps bukan kumpulan tool yang berdiri sendiri; ia adalah sistem yang saling terhubung, dan setiap tool mengisi slot tertentu dalam siklus hidup software.
Mengapa penting memahami arsitektur ini lebih dulu? Karena di episode-episode berikutnya kalian akan belajar komponen demi komponen: Git (episode 4), CI (episode 5), CD (episode 6), container (episode 7), Kubernetes (episode 8), dan seterusnya. Tanpa peta ini, kalian akan belajar tool tanpa tahu di mana ia duduk dan mengapa ia dibutuhkan di sana.
#Siklus Hidup DevOps: Loop Kontinu
Siklus hidup DevOps bukan garis lurus sekali jalan, melainkan loop yang terus berputar. Setiap iterasi memperpendek feedback loop — dan semakin pendek loop-nya, semakin cepat tim belajar dan beradaptasi.
Mari kita bedah satu per satu:
| Fase | Aktivitas | Tool Representatif |
|---|---|---|
| Plan | Merencanakan fitur, backlog, dan prioritas | Jira, Linear, GitHub Issues |
| Code | Menulis dan mereview kode | Git, IDE, pull request |
| Build | Mengompilasi kode menjadi artifact | GitHub Actions, GitLab CI, Jenkins |
| Test | Menguji otomatis: unit, integration, E2E | Jest, Playwright, k6 |
| Release | Menyiapkan dan memvalidasi rilis | Pipeline CD, approval gate |
| Deploy | Menempatkan versi ke environment | Argo CD, Docker, Kubernetes |
| Operate | Menjalankan dan mengelola layanan | Kubernetes, Ansible, Terraform |
| Monitor | Mengamati metrik, log, dan alert | Prometheus, Grafana, Loki |
Setiap fase menghasilkan umpan balik: monitoring menemukan bug → kembali ke Plan; test menemukan masalah → kembali ke Code. Inilah yang membuat DevOps disebut loop, bukan pipeline.
#Arsitektur DevOps: Lima Komponen Inti
Di balik loop tersebut ada lima pilar arsitektur yang wajib kalian kenali. Semua akan dibahas mendalam di episode masing-masing.
#1. Source Control (Git)
Segala sesuatu dimulai dari satu sumber kebenaran: repository Git. Kode, konfigurasi infrastruktur, bahkan pipeline itu sendiri disimpan di sini. Konsekuensinya: semua perubahan bisa ditelusuri, direview, dan di-rollback. Inilah fondasi yang dibahas di episode 4 dan menjadi mental model GitOps di episode 14.
#2. CI/CD Pipeline
Pipeline mengubah perubahan kode menjadi artifact yang bisa dirilis. CI (episode 5) menangani build, test, dan linting secara otomatis; CD (episode 6) menangani delivery ke environment dan deployment. Pipeline adalah jalur produksi software — semakin mulus, semakin cepat lead time (metrik DORA kedua).
#3. Environment dan Infrastruktur
Aplikasi berjalan di environment yang konsisten: dev, staging, dan production. Konsistensi dicapai lewat Infrastructure as Code — Terraform (episode 9) untuk provision, Ansible (episode 10) untuk konfigurasi — serta container (episode 7) dan Kubernetes (episode 8) sebagai standar eksekusi.
#4. Artifact Registry
Setiap versi yang lolos build disimpan sebagai artifact yang immutable dan bisa dilacak: image container, package, atau binary. Registry adalah jembatan antara "berhasil dibangun" dan "siap dirilis", dan menjadi fokus episode 17 tentang artifact & environment management.
#5. Observability
Tanpa observability, siklus DevOps buta. Logging, metrics, dan tracing (episode 11) memberi data untuk Monitor → Plan. Data inilah yang menggerakkan perbaikan: error budget, alert, dan keputusan kapan harus rilis.
Note
Kelima pilar ini tidak bisa dipisahkan. Kalian bisa membangun CI/CD yang sempurna, tetapi tanpa artifact registry yang baik versi rilis tidak bisa dilacak; tanpa observability keputusan rilis jadi tebakan. Anggap arsitektur ini seperti rantai — kekuatan sistem ada di mata rantai terlemahnya.
#Siapa Memegang Apa: Ownership dalam Arsitektur
Di tim DevOps yang sehat, setiap komponen punya pemilik yang jelas:
- Developer bertanggung jawab atas kode hingga staging (CI + build + test).
- Platform/DevOps bertanggung jawab atas pipeline produksi, infrastruktur, dan observability.
- SRE (jika ada) memegang SLA/SLO, error budget, dan on-call untuk layanan kritis.
Pembagian ini bukan silo baru — tujuannya justru shared responsibility: developer paham operasi, operator paham kode. Di episode 15 kita lihat bagaimana pembagian ini melebur ke dalam platform engineering.
#Pitfall Umum: Menganggap DevOps sebagai Proyek Sekali Jadi
Kesalahan paling umum di lapangan: memperlakukan DevOps sebagai proyek dengan tanggal selesai. Padahal DevOps adalah sistem yang hidup. Arsitektur yang kalian bangun di episode 2 sampai 27 ini akan terus berevolusi — ada tool baru, ada standar baru, ada beban baru. Mental model yang benar: kalian membangun dan memelihara sebuah mesin yang harus selalu berputar.
#Penutup
Inti yang harus dibawa pulang:
- DevOps adalah loop kontinu: Plan → Code → Build → Test → Release → Deploy → Operate → Monitor.
- Setiap fase menghasilkan umpan balik yang memicu iterasi berikutnya.
- Lima pilar arsitektur: source control, CI/CD, environment, artifact registry, observability.
- Kepemilikan yang jelas + shared responsibility menjaga sistem tetap sehat.
Di episode 3 selanjutnya kita mulai fase praktik dari fondasi: Linux & scripting dengan Bash dan Python — karena semua komponen arsitektur ini dijalankan, diotomasi, dan di-troubleshoot melalui terminal. Pastikan environment dari episode 0 sudah siap, karena kita akan banyak mengetik!