DevOps Adalah: Siklus, Metrik, dan Peran DevOps Engineer

Aplikasi di ponsel Anda hampir selalu punya pembaruan setiap minggu. Dua puluh tahun lalu, perangkat lunak umumnya dirilis setahun sekali dalam bentuk CD, dan setiap rilis menjadi proyek besar yang melelahkan. Ritme yang berubah dari tahunan menjadi harian ini tidak lahir karena developer mengetik lebih cepat. Ia lahir dari cara kerja baru antara orang yang menulis kode dan orang yang menjalankannya di server.

DevOps adalah cara kerja yang menyatukan tim pengembangan perangkat lunak dan tim operasional TI, agar perubahan kode cepat sampai ke pengguna tanpa mengorbankan stabilitas. Artikel ini membahas pengertian DevOps, siklus delapan tahapnya, cara mengukur keberhasilannya, hingga tugas DevOps engineer dan cara mulai mempelajarinya.

Apa Itu DevOps?

DevOps adalah pendekatan kerja yang menyatukan tim pengembangan dan tim operasional dalam satu alur, dari kode ditulis sampai aplikasi berjalan dan dipantau. DevOps singkatan dari development (pengembangan) dan operations (operasional). Tim pengembangan menulis dan menguji kode aplikasi, sedangkan tim operasional memasang aplikasi itu di server dan menjaganya tetap hidup. DevOps menghapus sekat di antara keduanya.

Sampai hari ini tidak ada definisi tunggal yang disepakati. Beberapa penelitian akademik pada 2015–2017 bahkan mencatat bahwa setiap orang memakai definisinya sendiri. Rumusan yang paling mudah diuji datang dari Len Bass, Ingo Weber, dan Liming Zhu. Menurut mereka, DevOps adalah sekumpulan praktik untuk memperpendek waktu sejak perubahan di-commit (disimpan ke repositori kode). Waktu itu dihitung sampai perubahan berjalan di production (server yang dipakai pengguna sungguhan), tanpa menurunkan kualitas.

Definisi itu sengaja tidak menyebut alat apa pun. Secara umum, DevOps dicirikan oleh tiga prinsip:

1. Kepemilikan bersama: developer dan tim operasional sama-sama bertanggung jawab atas aplikasi yang berjalan di production, bukan hanya atas bagiannya masing-masing.
2. Otomasi alur kerja: langkah berulang seperti pengujian dan pemasangan aplikasi dijalankan mesin, bukan tangan manusia.
3. Umpan balik cepat: masalah diketahui dalam hitungan menit setelah perubahan, bukan berminggu-minggu kemudian dari keluhan pengguna.

Oleh karena itu, DevOps lebih tepat dipahami sebagai gabungan budaya, praktik, dan alat. Urutannya pun penting: budaya dan praktik lebih dulu, alat menyusul.

Masalah yang Dijawab DevOps: Dua Tim, Dua Ukuran Sukses

Akar masalah yang ingin diselesaikan DevOps adalah ukuran keberhasilan yang saling bertabrakan. Developer dinilai dari seberapa banyak fitur dan perbaikan yang berhasil dirilis. Tim operasional dinilai dari seberapa jarang sistem mati. Bagi tim operasional, setiap perubahan adalah risiko, sehingga wajar kalau mereka cenderung menahan rilis.

Bayangkan sebuah toko online yang merilis pembaruan setiap tiga bulan. Satu rilis membawa 40 perubahan sekaligus dan dipasang Jumat malam supaya tidak mengganggu pembeli. Satu jam kemudian, halaman checkout (pembayaran) gagal dimuat. Pertanyaannya, perubahan mana dari 40 perubahan itu yang menjadi penyebab?

Developer merasa kodenya berjalan normal di laptop, tim operasional merasa server tidak berubah. Sementara keduanya saling menunjuk, pembeli tetap tidak bisa membayar. Semakin sering kejadian ini, semakin ketat aturan rilis, dan semakin besar tumpukan perubahan di rilis berikutnya.

DevOps memutus lingkaran itu dengan dua perubahan. Pertama, kedua tim diberi satu tujuan bersama: perubahan sampai ke pengguna dengan aman. Kedua, 40 perubahan tadi dipecah menjadi puluhan rilis kecil. Kalau satu rilis kecil bermasalah, penyebabnya langsung terlihat dan bisa dibatalkan dalam hitungan menit. Werner Vogels, CTO Amazon, merangkum semangat ini dalam wawancara dengan ACM Queue pada 2006. Kalimatnya, "you build it, you run it": tim yang membangun aplikasi juga ikut menjalankannya.

Asal-Usul Istilah DevOps: Toronto 2008 sampai Ghent 2009

Istilah DevOps lahir dari rangkaian peristiwa kecil. Pada Agustus 2008, Andrew Shafer membuka sesi diskusi bertema "Agile Infrastructure" di Agile Conference, Toronto. Satu-satunya peserta yang datang adalah Patrick Debois, konsultan TI asal Belgia.

Debois kemudian mencari Shafer, dan dari obrolan itu lahir Agile Systems Administration Group. Pertanyaan mereka sederhana: bagaimana tim operasional bisa bergerak selincah developer yang sudah memakai metode Agile (pengembangan dalam iterasi pendek)?

Jawabannya muncul pada Juni 2009 di konferensi Velocity. John Allspaw dan Paul Hammond dari Flickr membawakan presentasi berjudul "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr". Saat itu, sepuluh rilis per hari terdengar mustahil, dan Flickr menunjukkan kuncinya ada pada kerja sama tim.

Terinspirasi presentasi itu, Debois menggelar konferensi devopsdays pertama di Ghent, Belgia, masih di tahun 2009. Nama konferensi itulah yang kemudian dipendekkan menjadi DevOps. Pada 2012, Puppet Labs menerbitkan State of DevOps Report pertama. Riset tahunan ini dilanjutkan tim DORA (DevOps Research and Assessment), yang diakuisisi Google pada Desember 2018.

Siklus DevOps: Delapan Tahap yang Terus Berputar

Siklus DevOps (DevOps lifecycle) biasa digambarkan sebagai angka delapan yang direbahkan, mirip simbol tak hingga (∞). Putaran kiri adalah wilayah pengembangan, putaran kanan wilayah operasional, dan keduanya bersambung tanpa titik akhir.

1. Plan (rencana): tim memilih perubahan kecil berikutnya berdasarkan umpan balik pengguna, data pemantauan, dan laporan bug.
2. Code (menulis kode): developer menulis kode dan menyimpannya di sistem kontrol versi Git, biasanya di layanan seperti GitHub.
3. Build (merakit): kode dirakit menjadi paket yang siap dijalankan, sering dalam bentuk image Docker yang nantinya dijalankan sebagai container (wadah terisolasi berisi aplikasi dan dependensinya).
4. Test (menguji): pengujian otomatis dijalankan, lalu aplikasi dicoba di lingkungan staging yang meniru production.
5. Release (menyiapkan rilis): paket yang lolos uji ditandai siap rilis, lengkap dengan nomor versinya.
6. Deploy (memasang): paket dipasang ke production. Cara memasangnya dengan aman kami bahas di artikel deployment.
7. Operate (menjalankan): aplikasi melayani pengguna, dengan kapasitas yang ditambah atau dikurangi sesuai beban.
8. Monitor (memantau): metrik, log, dan laporan error dikumpulkan, lalu dipakai sebagai bahan tahap Plan berikutnya. Kemampuan membaca kondisi sistem dari data ini disebut observability (observabilitas).

Tahap Build sampai Deploy biasanya dijalankan otomatis oleh pipeline DevOps, yaitu rangkaian langkah yang berjalan sendiri setiap ada perubahan kode. Otomasi inilah yang dikenal sebagai praktik CI/CD. Di artikel tersebut kami menjelaskan beda continuous integration, continuous delivery, dan continuous deployment secara rinci.

Hal yang perlu diperhatikan adalah durasi satu putaran. Pada tim yang menerapkan DevOps dengan baik, satu putaran bisa selesai dalam hitungan jam, sedangkan tim tradisional butuh tiga sampai enam bulan.

CALMS: Lima Pilar Penopang Siklus

Kalau siklus menjelaskan alur pekerjaan, CALMS menjelaskan fondasi yang membuat alur itu bisa berjalan. Kerangka ini awalnya bernama CAMS, dicetuskan Damon Edwards dan John Willis setelah devopsdays pertama di Amerika Serikat pada 2010. Jez Humble kemudian menambahkan huruf L sehingga menjadi CALMS. Banyak tim memakainya sebagai daftar periksa untuk menilai seberapa jauh penerapan metode DevOps mereka.

1. Culture (budaya): masalah di production menjadi urusan bersama. Setelah insiden, tim menulis post-mortem (catatan evaluasi) yang mencari penyebab di sistem, bukan mencari orang yang disalahkan.
2. Automation (otomasi): pekerjaan berulang yang rawan salah diserahkan ke mesin. Patokan praktisnya, langkah manual yang sama dan dikerjakan lebih dari dua kali seminggu layak diotomasi.
3. Lean (ramping): pekerjaan dipecah menjadi potongan kecil, dan waktu tunggu dipangkas. Perubahan satu baris yang menunggu persetujuan tiga hari adalah contoh pemborosan yang ingin dihilangkan.
4. Measurement (pengukuran): keputusan diambil dari data, bukan perasaan. Tim tahu berapa lama perubahan sampai ke production dan seberapa sering rilis gagal.
5. Sharing (berbagi): pengetahuan tidak tersimpan di kepala satu orang. Prosedur penanganan masalah ditulis sebagai runbook (panduan langkah demi langkah) yang bisa diikuti anggota tim lain.

Dari kelima pilar, Culture paling sulit dan paling sering dilewati. Tim yang hanya mengejar Automation biasanya berakhir dengan pipeline canggih yang tidak dipercaya siapa pun.

Alat DevOps di Setiap Tahap

Setelah proses jelas, barulah alat dipilih. Tabel berikut merangkum tools DevOps yang lazim dipakai; cukup pilih satu alat per baris.

Kebutuhan	Fungsi	Contoh alat
Kontrol versi	Menyimpan riwayat kode dan konfigurasi	Git, GitHub, GitLab
Pipeline CI/CD	Menjalankan build, uji, dan deploy otomatis	Jenkins, GitHub Actions, GitLab CI
Pengemasan	Membungkus aplikasi beserta dependensinya	Docker, Podman
Orkestrasi	Menjalankan dan menskalakan banyak container	Kubernetes
Infrastruktur sebagai kode	Membuat dan mengatur server lewat berkas konfigurasi	Terraform, OpenTofu, Ansible
Pemantauan	Mengumpulkan metrik, log, dan mengirim peringatan	Prometheus, Grafana, Zabbix, Netdata

Istilah infrastructure as code (infrastruktur sebagai kode) berarti spesifikasi server ditulis dalam berkas teks dan disimpan di Git, sama seperti kode aplikasi. Server bisa dibuat ulang persis sama kapan saja, dan setiap perubahan konfigurasi tercatat riwayatnya.

Untuk pemantauan, Zabbix cocok untuk memantau banyak server sekaligus, sedangkan Netdata lebih praktis untuk melihat kondisi satu server secara langsung. Sementara itu, Kubernetes baru relevan ketika jumlah container Anda sudah puluhan. Tim berisi tiga orang umumnya cukup dengan Git, GitHub Actions, Docker, dan satu alat pemantauan.

Manfaat DevOps Diukur dengan Lima Metrik DORA

Manfaat DevOps sering ditulis sebagai klaim umum: rilis lebih cepat dan kualitas lebih baik. Cara yang lebih jujur adalah mengukurnya, dan ukuran yang paling banyak dipakai berasal dari riset DORA.

Per Januari 2026, DORA memakai lima metrik yang dibagi ke dua kelompok. Kelompok pertama mengukur throughput (seberapa lancar perubahan mengalir):

1. Change lead time: waktu yang dibutuhkan sebuah perubahan sejak di-commit sampai berjalan di production.
2. Deployment frequency: seberapa sering tim melakukan deploy dalam periode tertentu.
3. Failed deployment recovery time: waktu yang dibutuhkan untuk pulih dari deploy yang gagal dan butuh penanganan segera.

Kelompok kedua mengukur instabilitas, yaitu seberapa sering perubahan justru menimbulkan masalah:

1. Change fail rate: persentase deploy yang butuh penanganan segera setelah dipasang.
2. Deployment rework rate: persentase deploy yang tidak direncanakan dan terpaksa dilakukan karena ada insiden di production.

Metrik ini sendiri terus berkembang. Versi awalnya, yang terbit pada 2016, hanya berisi empat metrik. Pada 2023, metrik mean time to recover diganti menjadi failed deployment recovery time karena definisi lamanya membingungkan. Laporan 2024 menambahkan rework rate, dan laporan 2025 berhenti memeringkat tim ke tingkatan elite–rendah, lalu menggantinya dengan tujuh profil tim.

Sebagai patokan, laporan 2024 mencatat sekitar 19% responden masuk kelompok elite. Tim elite bisa deploy kapan pun dibutuhkan, dengan change lead time kurang dari satu hari. Change fail rate mereka sekitar 5%, dan mereka pulih dari deploy gagal dalam waktu kurang dari satu jam.

Temuan terpenting riset DORA ada di balik angka tersebut: tim tercepat justru juga tim yang paling stabil. Rilis kecil yang sering lebih mudah diuji, dilacak, dan dibatalkan. Inilah manfaat DevOps yang paling nyata: tim tidak lagi harus memilih antara cepat atau aman.

Empat Salah Kaprah tentang DevOps

Popularitas istilah DevOps membuat maknanya sering bergeser. Empat salah kaprah berikut paling sering menjebak tim yang baru memulai.

1. DevOps dianggap nama jabatan: merekrut satu orang berjabatan DevOps engineer tidak otomatis membuat perusahaan menerapkan DevOps. Kalau developer tetap melempar kode ke orang tersebut tanpa ikut bertanggung jawab, sekatnya hanya berpindah tempat.
2. DevOps dianggap membeli alat: pipeline paling mahal pun tidak berguna kalau setiap rilis masih harus menunggu rapat persetujuan dua minggu. Alat hanya mempercepat proses yang sudah ada, termasuk proses yang buruk.
3. DevOps dianggap sama dengan CI/CD: pipeline otomatis hanya mencakup separuh siklus. Tanpa pemantauan dan umpan balik, pipeline hanya mengirim bug ke pengguna dengan lebih cepat.
4. DevOps dianggap menghapus tim operasional: pekerjaan operasional tidak hilang, tetapi berubah bentuk. Alih-alih memasang aplikasi dengan tangan, tim operasional membangun sistem yang membuat developer bisa memasang aplikasinya sendiri dengan aman.

Kelemahan DevOps dan Hal yang Perlu Anda Pertimbangkan

DevOps bukan tanpa biaya. Berikut konsekuensi yang perlu Anda pahami sebelum menerapkannya.

1. Perubahan budaya butuh waktu berbulan-bulan: memasang pipeline bisa selesai dalam seminggu. Mengubah kebiasaan saling menyalahkan menjadi tanggung jawab bersama bisa memakan enam bulan sampai lebih dari setahun.
2. Tim DevOps bisa menjadi sekat baru: banyak perusahaan membentuk "tim DevOps" terpisah yang menerima semua urusan pipeline dan server. Akibatnya, tim itu menjadi perantara baru antara developer dan operasional, persis masalah yang ingin dihapus.
3. Jumlah alat mudah membengkak: setiap masalah kecil terasa layak diselesaikan dengan alat baru, sampai tim kecil harus merawat belasan alat sekaligus.
4. Beban jaga berpindah ke developer: prinsip you build it, you run it berarti developer ikut jadwal on-call (siaga menangani insiden di luar jam kerja). Rotasi yang sehat butuh minimal empat sampai lima orang, sehingga tiap orang siaga satu minggu dalam setiap empat sampai lima minggu.
5. AI mempercepat sekaligus menambah risiko: laporan DORA 2025 tentang pemakaian AI dalam DevOps mencatat 90% responden sudah memakai AI dalam pekerjaannya. Throughput memang naik, tetapi instabilitas ikut naik. DORA menyimpulkan bahwa AI memperkuat kondisi tim yang sudah ada, termasuk kelemahannya.
6. Tidak semua proyek butuh DevOps penuh: website profil perusahaan yang diubah sebulan sekali tidak memerlukan Kubernetes dan pipeline berlapis. Cukup Git, pencadangan rutin, dan satu lingkungan staging sederhana.

DevOps, DevSecOps, SRE, dan Platform Engineering

Seiring berkembangnya DevOps, muncul beberapa istilah turunan yang sering tertukar.

DevSecOps Adalah DevOps dengan Keamanan Sejak Awal

DevSecOps adalah penerapan DevOps yang memasukkan keamanan ke setiap tahap siklus, bukan hanya diperiksa di akhir. Pendekatan ini dikenal sebagai shift left, yaitu menggeser pemeriksaan ke tahap yang lebih awal. Tugas DevSecOps antara lain memasang pemindai di pipeline untuk menangkap celah seperti SQL injection dan XSS sebelum kode sampai ke production. Jadi, bedanya DevOps dan DevSecOps ada pada penekanan: DevSecOps menjadikan keamanan tanggung jawab setiap anggota tim, bukan tugas tim keamanan di ujung proses.

SRE: Cara Google Menjalankan Prinsip DevOps

SRE (site reliability engineering) dikembangkan Google sejak 2003. Buku SRE terbitan Google menyebut DevOps dapat dipandang sebagai generalisasi beberapa prinsip inti SRE untuk organisasi yang lebih luas. SRE membawa aturan yang lebih konkret. Contohnya, porsi pekerjaan operasional manual seorang SRE dibatasi maksimal 50%, sisanya untuk membangun otomasi.

SRE juga memperkenalkan error budget (jatah gangguan). Kalau target ketersediaan layanan 99,99%, berarti ada jatah gangguan 0,01%, atau sekitar 4 menit 19 detik dalam sebulan 30 hari. Selama jatah itu belum habis, tim boleh terus merilis fitur baru. Begitu habis, fokus beralih ke perbaikan stabilitas.

Platform Engineering

Platform engineering adalah praktik membangun layanan swalayan internal untuk developer. Tanpa membuka tiket ke tim lain, developer bisa membuat lingkungan uji, memasang aplikasi, atau melihat log sendiri. Pengalamannya mirip memakai Heroku, tetapi dibangun dan dikelola di dalam perusahaan. Praktik ini menjawab kelemahan nomor dua di atas: alih-alih menjadi perantara, tim operasional membangun jalan tol bagi semua developer.

Bedanya dengan Agile

Agile adalah cara membangun perangkat lunak dalam iterasi pendek bersama pengguna. Fokusnya berhenti ketika fitur selesai dibuat. DevOps meneruskan semangat itu sampai fitur berjalan di production dan dipantau. Tidak heran kalau sesi diskusi 2008 yang menjadi cikal bakal DevOps berjudul "Agile Infrastructure".

DevOps Engineer Adalah Apa, dan Apa Tugasnya?

DevOps engineer adalah peran yang membangun dan merawat jalur dari kode ke production. Mereka memastikan developer bisa merilis perubahan dengan cepat, sementara sistem tetap stabil dan terpantau. Dalam pembagian peran brainware, DevOps engineer berdiri di antara programmer dan administrator sistem.

Tugas DevOps engineer sehari-hari biasanya meliputi:

1. Merancang dan merawat pipeline CI/CD: memastikan setiap perubahan kode otomatis dirakit, diuji, dan dipasang.
2. Menulis infrastruktur sebagai kode: membuat dan mengubah server, jaringan, dan basis data lewat berkas konfigurasi.
3. Menyiapkan pemantauan dan peringatan: menentukan metrik apa yang dipantau dan kapan tim harus dibangunkan.
4. Menangani insiden: memimpin pemulihan saat layanan bermasalah, lalu menulis post-mortem.
5. Mengurangi hambatan developer: mencari langkah manual yang memperlambat rilis, lalu mengotomasinya.

Apakah DevOps Engineer Harus Bisa Coding?

Ya, setidaknya untuk menulis skrip otomasi dengan Bash atau Python dan membaca kode aplikasi saat menelusuri masalah. Mereka tidak harus membangun fitur, tetapi tidak bisa bekerja hanya dengan mengklik antarmuka.

Berapa Gaji DevOps Engineer di Indonesia?

Data Jobstreet per September 2026 menunjukkan kisaran umum Rp7,25–10,25 juta per bulan untuk DevOps engineer di Indonesia. Di DKI Jakarta kisarannya Rp8,5–11,5 juta, sedangkan rata-rata di Jakarta Selatan sekitar Rp17 juta. Angka ini berasal dari iklan lowongan, dan posisi senior jarang mencantumkan gaji, sehingga batas atas sebenarnya lebih tinggi.

Cara Mulai Belajar dan Menerapkan DevOps

Titik awalnya berbeda, tergantung apakah Anda belajar sendiri atau menerapkannya di tim.

Roadmap Belajar DevOps untuk Individu

Urutan berikut mengikuti ketergantungan antarkonsep: Docker sulit dipahami tanpa Linux, pipeline sulit dipahami tanpa Git. Durasinya mengasumsikan waktu belajar satu sampai dua jam per hari.

1. Linux dan command line (4–6 minggu): mulai dari salah satu distro Linux, koneksi SSH, izin berkas, dan Bash script sederhana.
2. Git (1–2 minggu): commit, branch, merge, dan pull request.
3. Satu alat CI (2 minggu): GitHub Actions paling mudah dimulai karena gratis untuk repositori publik.
4. Docker (2–3 minggu): membuat image, menjalankan container, dan menyusun beberapa layanan dengan Docker Compose.
5. Server dan infrastruktur sebagai kode (3–4 minggu): sewa satu VPS dengan akses root, lalu atur konfigurasinya lewat Ansible atau Terraform.
6. Pemantauan (2 minggu): pasang satu alat pemantauan dan buat peringatan saat server kehabisan memori.

Totalnya sekitar 14–19 minggu, atau 3,5–4,5 bulan. Tutup jalur ini dengan satu proyek utuh: aplikasi sederhana yang setiap perubahannya otomatis diuji lalu dipasang ke server, lengkap dengan dasbor pemantauan. Untuk server latihan, VPS Indonesia dengan RAM 1–2 GB sudah memadai untuk proyek seperti ini.

Langkah Awal untuk Tim Kecil

DevOps tidak hanya untuk perusahaan besar. Tim berisi dua sampai lima orang justru lebih mudah memulainya, cukup empat sampai enam minggu tanpa alat mahal:

1. Minggu 1: pindahkan seluruh kode dan konfigurasi ke satu repositori Git. Mulai minggu ini, tidak ada lagi perubahan yang diketik langsung di server.
2. Minggu 2–3: pasang pipeline yang menjalankan pengujian otomatis setiap kali ada pull request.
3. Minggu 3–4: buat proses deploy yang cukup dijalankan dengan satu perintah, termasuk perintah untuk membatalkannya.
4. Minggu 5–6: mulai ukur dua metrik DORA, yaitu deployment frequency dan change lead time. Tambahkan change fail rate setelah datanya terkumpul satu bulan.

Hindari memulai dari Kubernetes. Alat itu menyelesaikan masalah skala yang belum dimiliki kebanyakan tim kecil, dan justru menambah beban perawatan di awal.

Pertanyaan yang Sering Muncul

Apa bedanya DevOps dan Azure DevOps?

DevOps adalah cara kerja, sedangkan Azure DevOps adalah produk Microsoft untuk menjalankan cara kerja tersebut. Azure DevOps berisi layanan papan tugas (Boards), repositori kode (Repos), pipeline (Pipelines), pengujian (Test Plans), dan penyimpanan paket (Artifacts). Layanan ini gratis untuk tim hingga lima pengguna. Anda tetap bisa menerapkan DevOps tanpa Azure DevOps, misalnya dengan GitHub atau GitLab.

Kapan sebuah tim bisa dikatakan sudah menerapkan DevOps?

Tidak ada garis akhir resmi, tetapi tandanya bisa diamati. Deploy tidak lagi memerlukan rapat khusus, perubahan kecil sampai ke production dalam kurang dari seminggu, dan insiden ditangani tanpa saling menyalahkan.

Apakah perlu sertifikasi untuk menjadi DevOps engineer?

Sertifikasi tidak wajib. Perusahaan umumnya lebih menilai proyek nyata yang bisa Anda tunjukkan, misalnya repositori berisi pipeline dan konfigurasi server. Kalau ingin menambah nilai, sertifikasi seperti AWS Certified DevOps Engineer – Professional atau Certified Kubernetes Administrator (CKA) cukup dikenal.

Kesimpulan

DevOps adalah cara kerja yang menyatukan developer dan tim operasional di bawah satu tujuan: perubahan sampai ke pengguna dengan cepat dan aman. Intinya ada pada rilis kecil yang sering, otomasi langkah berulang, dan umpan balik dari production. Keberhasilannya bisa diukur, bukan sekadar dirasakan, lewat lima metrik DORA.

Untuk tim yang merilis perubahan setiap minggu atau lebih sering, praktik DevOps hampir selalu sepadan dengan usahanya. Untuk proyek yang jarang berubah, cukup ambil sebagian praktiknya, seperti Git, pengujian otomatis, dan pencadangan rutin. Mulailah dari budaya dan proses, lalu pilih alat yang mendukungnya.

Semoga artikel ini membantu.