| 1 | --- |
| 2 | title: "DevOps" |
| 3 | term: "apa-itu-devops" |
| 4 | category: "Software Development" |
| 5 | tags: ["devops", "ci-cd", "automation", "deployment", "infrastructure", "agile"] |
| 6 | description: "Kombinasi praktik, tools, dan filosofi budaya yang mengintegrasikan development dan operations untuk meningkatkan kecepatan delivery software." |
| 7 | englishTerm: "Development and Operations" |
| 8 | relatedTerms: ["apa-itu-ci-cd", "apa-itu-docker", "apa-itu-kubernetes", "apa-itu-automation", "apa-itu-infrastructure-as-code"] |
| 9 | difficulty: "menengah" |
| 10 | lastmod: 2024-01-15 |
| 11 | published: true |
| 12 | --- |
| 13 | |
| 14 | ## Apa itu DevOps? |
| 15 | |
| 16 | **DevOps** adalah gabungan dari **Development** dan **Operations**. Istilah ini mengacu pada cara kerja yang menyatukan proses pengembangan software dan operasional sistem supaya rilis aplikasi bisa lebih cepat, lebih stabil, dan tidak terlalu bergantung pada banyak langkah manual. |
| 17 | |
| 18 | Sebelum pendekatan DevOps populer, tim development dan operations sering bekerja terpisah. Akibatnya, proses rilis terasa lambat, handoff antartim sering membingungkan, dan saat ada masalah, semua orang sibuk mencari siapa yang salah. |
| 19 | |
| 20 | Beberapa masalah yang umum muncul tanpa praktik DevOps yang baik: |
| 21 | - **Deploy lambat** - Rilis bisa makan waktu berminggu-minggu atau berbulan-bulan |
| 22 | - **Komunikasi buruk** - Tim dev dan ops bekerja di jalur masing-masing |
| 23 | - **Proses manual berulang** - Banyak tugas rutin rawan lupa atau salah |
| 24 | - **Kualitas tidak konsisten** - Testing dan deployment berjalan berbeda-beda di tiap lingkungan |
| 25 | |
| 26 | ## Prinsip-prinsip Utama DevOps |
| 27 | |
| 28 | ### 1. Kolaborasi |
| 29 | Tim development dan operations bekerja lebih dekat, berbagi tanggung jawab atas lifecycle aplikasi. |
| 30 | |
| 31 | ### 2. Otomasi |
| 32 | Tugas yang berulang seperti build, test, deployment, dan provisioning sebaiknya diotomasi. |
| 33 | |
| 34 | ### 3. Perbaikan Berkelanjutan |
| 35 | Proses selalu dievaluasi. Kalau ada bottleneck, prosesnya yang diperbaiki, bukan cuma ditambal. |
| 36 | |
| 37 | ### 4. Fokus pada Pengguna |
| 38 | Tujuannya bukan sekadar rilis cepat, tetapi mengirim nilai ke pengguna dengan cara yang tetap aman dan terukur. |
| 39 | |
| 40 | ### 5. Belajar dari Insiden |
| 41 | Error dan incident tetap bisa terjadi. Yang penting, tim belajar dari penyebabnya dan memperbaiki proses agar tidak terulang dengan cara yang sama. |
| 42 | |
| 43 | ## DevOps Lifecycle |
| 44 | |
| 45 | ### 1. Plan |
| 46 | Merencanakan fitur dan perubahan berdasarkan kebutuhan produk dan feedback pengguna. |
| 47 | |
| 48 | **Tools**: Jira, Trello, Azure Boards, Linear |
| 49 | |
| 50 | ### 2. Code |
| 51 | Developer menulis kode dan menyimpannya di version control. |
| 52 | |
| 53 | **Tools**: Git, GitHub, GitLab, Bitbucket |
| 54 | |
| 55 | ### 3. Build |
| 56 | Kode di-compile atau dipaketkan menjadi artefak yang siap diuji atau dijalankan. |
| 57 | |
| 58 | **Tools**: Maven, Gradle, npm, webpack |
| 59 | |
| 60 | ### 4. Test |
| 61 | Automated testing membantu mengecek apakah perubahan baru merusak perilaku yang sudah ada. |
| 62 | |
| 63 | **Tools**: Jest, Pytest, JUnit, Selenium, Cypress |
| 64 | |
| 65 | ```javascript |
| 66 | // Contoh automated test |
| 67 | describe('User API', () => { |
| 68 | test('should create new user', async () => { |
| 69 | const response = await api.post('/users', { |
| 70 | name: 'Budi', |
| 71 | email: 'budi@example.com' |
| 72 | }); |
| 73 | expect(response.status).toBe(201); |
| 74 | }); |
| 75 | }); |
| 76 | ``` |
| 77 | |
| 78 | ### 5. Release |
| 79 | Aplikasi disiapkan untuk dikirim ke environment tujuan, lengkap dengan artefak build dan konfigurasi yang dibutuhkan. |
| 80 | |
| 81 | **Tools**: Docker, Helm, Artifactory |
| 82 | |
| 83 | ### 6. Deploy |
| 84 | Versi baru aplikasi dirilis ke staging atau production. |
| 85 | |
| 86 | **Tools**: Kubernetes, AWS, smbCloud, Ansible |
| 87 | |
| 88 | ```bash |
| 89 | # Contoh deployment ke smbCloud |
| 90 | $ git push smb main |
| 91 | # Otomatis trigger build dan deploy |
| 92 | ``` |
| 93 | |
| 94 | ### 7. Operate |
| 95 | Aplikasi yang sudah berjalan perlu dikelola: resource, ketersediaan, incident, dan operasional harian. |
| 96 | |
| 97 | **Tools**: Prometheus, Grafana, Datadog, New Relic |
| 98 | |
| 99 | ### 8. Monitor |
| 100 | Tim memantau performa, error, log, dan perilaku sistem setelah aplikasi dirilis. |
| 101 | |
| 102 | **Tools**: ELK Stack, Sentry, LogRocket |
| 103 | |
| 104 | ## CI/CD: Bagian Penting dalam DevOps |
| 105 | |
| 106 | ### Continuous Integration (CI) |
| 107 | Developer menggabungkan perubahan kode ke branch utama secara rutin. Setiap perubahan biasanya memicu proses build dan test otomatis. |
| 108 | |
| 109 | ```yaml |
| 110 | # Contoh GitHub Actions CI |
| 111 | name: CI |
| 112 | on: [push, pull_request] |
| 113 | jobs: |
| 114 | test: |
| 115 | runs-on: ubuntu-latest |
| 116 | steps: |
| 117 | - uses: actions/checkout@v2 |
| 118 | - name: Install dependencies |
| 119 | run: npm install |
| 120 | - name: Run tests |
| 121 | run: npm test |
| 122 | - name: Run linter |
| 123 | run: npm run lint |
| 124 | ``` |
| 125 | |
| 126 | ### Continuous Delivery (CD) |
| 127 | Setelah lolos test, kode disiapkan untuk dirilis ke environment berikutnya, biasanya staging atau production. |
| 128 | |
| 129 | ```yaml |
| 130 | # Contoh CD pipeline |
| 131 | deploy: |
| 132 | runs-on: ubuntu-latest |
| 133 | needs: test |
| 134 | if: github.ref == 'refs/heads/main' |
| 135 | steps: |
| 136 | - name: Deploy to production |
| 137 | run: | |
| 138 | curl -X POST https://api.smbcloud.com/deploy \ |
| 139 | -H "Authorization: Bearer ${{ secrets.SMB_TOKEN }}" \ |
| 140 | -d '{"app": "myapp", "branch": "main"}' |
| 141 | ``` |
| 142 | |
| 143 | ## Infrastructure as Code (IaC) |
| 144 | |
| 145 | Infrastructure as Code berarti infrastruktur dikelola lewat file konfigurasi, bukan lewat klik manual di dashboard. |
| 146 | |
| 147 | ### Terraform Example |
| 148 | ```hcl |
| 149 | # Define infrastructure as code |
| 150 | resource "aws_instance" "web_server" { |
| 151 | ami = "ami-0c55b159cbfafe1f0" |
| 152 | instance_type = "t2.micro" |
| 153 | |
| 154 | tags = { |
| 155 | Name = "WebServer" |
| 156 | Environment = "Production" |
| 157 | } |
| 158 | } |
| 159 | ``` |
| 160 | |
| 161 | ### Docker Example |
| 162 | ```dockerfile |
| 163 | # Dockerfile untuk Node.js app |
| 164 | FROM node:18-alpine |
| 165 | WORKDIR /app |
| 166 | COPY package*.json ./ |
| 167 | RUN npm ci --production |
| 168 | COPY . . |
| 169 | EXPOSE 3000 |
| 170 | CMD ["node", "server.js"] |
| 171 | ``` |
| 172 | |
| 173 | ## DevOps Tools Ecosystem |
| 174 | |
| 175 | ### Version Control |
| 176 | - **Git** - Sistem version control terdistribusi |
| 177 | - **GitHub/GitLab** - Platform hosting kode dan kolaborasi |
| 178 | |
| 179 | ### CI/CD Platforms |
| 180 | - **GitHub Actions** - CI/CD yang terintegrasi dengan GitHub |
| 181 | - **GitLab CI** - CI/CD bawaan GitLab |
| 182 | - **Jenkins** - Automation server open-source |
| 183 | - **CircleCI** - Platform CI/CD berbasis cloud |
| 184 | |
| 185 | ### Containerization |
| 186 | - **Docker** - Platform container untuk memaketkan aplikasi |
| 187 | - **Podman** - Alternatif ke Docker |
| 188 | |
| 189 | ### Orchestration |
| 190 | - **Kubernetes** - Platform orkestrasi container |
| 191 | - **Docker Swarm** - Opsi orkestrasi bawaan Docker |
| 192 | |
| 193 | ### Cloud Platforms |
| 194 | - **AWS** - Amazon Web Services |
| 195 | - **Google Cloud** - Google Cloud Platform |
| 196 | - **Azure** - Platform cloud dari Microsoft |
| 197 | - **smbCloud** - Platform cloud untuk developer Indonesia |
| 198 | |
| 199 | ### Monitoring & Logging |
| 200 | - **Prometheus** - Pengumpulan metrik dan alerting |
| 201 | - **Grafana** - Dashboard dan visualisasi |
| 202 | - **ELK Stack** - Elasticsearch, Logstash, Kibana |
| 203 | - **Datadog** - Monitoring terintegrasi |
| 204 | |
| 205 | ### Configuration Management |
| 206 | - **Ansible** - Otomasi operasional IT |
| 207 | - **Puppet** - Configuration management |
| 208 | - **Chef** - Infrastructure automation |
| 209 | |
| 210 | ## DevOps Best Practices |
| 211 | |
| 212 | ### 1. Mulai dari yang Kecil |
| 213 | Tidak perlu mengadopsi semuanya sekaligus. Banyak tim memulai dari: |
| 214 | - Version control yang rapi |
| 215 | - CI sederhana |
| 216 | - Deployment otomatis untuk satu environment |
| 217 | |
| 218 | ### 2. Otomasi yang Memang Perlu |
| 219 | Proses manual yang sering diulang biasanya layak diotomasi, misalnya: |
| 220 | - Testing |
| 221 | - Deployment |
| 222 | - Provisioning infrastruktur |
| 223 | - Alerting dasar |
| 224 | |
| 225 | ### 3. Ukur Proses, Bukan Cuma Menebak |
| 226 | Beberapa metrik yang sering dipakai: |
| 227 | - **Deployment frequency** - Seberapa sering aplikasi dirilis |
| 228 | - **Lead time** - Waktu dari perubahan kode sampai live |
| 229 | - **MTTR** - Waktu pemulihan saat terjadi incident |
| 230 | - **Change failure rate** - Persentase deploy yang berujung masalah |
| 231 | |
| 232 | ### 4. Gunakan Feature Flags Saat Perlu |
| 233 | Feature flag membantu tim merilis kode tanpa harus langsung mengaktifkan semua fitur ke semua pengguna. |
| 234 | |
| 235 | ```javascript |
| 236 | if (featureFlags.isEnabled('new-checkout')) { |
| 237 | // New checkout flow |
| 238 | } else { |
| 239 | // Old checkout flow |
| 240 | } |
| 241 | ``` |
| 242 | |
| 243 | ### 5. Masukkan Security Sejak Awal |
| 244 | Pendekatan ini sering disebut **DevSecOps**. Intinya sederhana: keamanan tidak ditaruh di akhir, tetapi diperiksa sepanjang proses build sampai deploy. |
| 245 | |
| 246 | ## DevOps Culture: Bagian yang Sering Sulit |
| 247 | |
| 248 | ### Blameless Post-Mortems |
| 249 | Saat incident terjadi, fokus utama seharusnya memahami apa yang terjadi dan bagaimana mencegah kejadian serupa, bukan mencari kambing hitam. |
| 250 | |
| 251 | 1. **Apa yang terjadi?** - Urutan kejadian |
| 252 | 2. **Kenapa bisa terjadi?** - Analisis akar masalah |
| 253 | 3. **Apa yang perlu diubah?** - Action items yang bisa benar-benar dikerjakan |
| 254 | |
| 255 | ### Shared Responsibility |
| 256 | Prinsip seperti *"you build it, you run it"* muncul dari kebutuhan agar tim yang membuat aplikasi juga memahami dampak operasionalnya di production. |
| 257 | |
| 258 | ### Continuous Learning |
| 259 | Praktik DevOps biasanya matang lewat eksperimen, evaluasi, dan kebiasaan memperbaiki proses sedikit demi sedikit. |
| 260 | |
| 261 | ## DevOps untuk Startup & SMB Indonesia |
| 262 | |
| 263 | ### Tantangan |
| 264 | - **Resource terbatas** - Tim kecil sering harus merangkap banyak peran |
| 265 | - **Gap keahlian** - Tidak semua tim punya engineer yang fokus ke DevOps |
| 266 | - **Tooling terasa rumit** - Banyak pilihan, tapi tidak semuanya relevan untuk tahap awal |
| 267 | |
| 268 | ### Solusi dengan smbCloud |
| 269 | smbCloud membantu tim yang ingin punya alur deploy dan operasional yang lebih rapi tanpa harus menyiapkan banyak komponen sendiri. |
| 270 | |
| 271 | ```bash |
| 272 | # No complex setup needed |
| 273 | $ npx smb init |
| 274 | $ git add . |
| 275 | $ git commit -m "Initial commit" |
| 276 | $ git push smb main |
| 277 | |
| 278 | Auto CI/CD configured |
| 279 | SSL certificate provisioned |
| 280 | Monitoring enabled |
| 281 | Live at https://myapp.smbcloud.app |
| 282 | ``` |
| 283 | |
| 284 | **Keuntungan**: |
| 285 | - Setup operasional lebih ringan |
| 286 | - Auto-scaling tersedia sebagai fitur platform |
| 287 | - Monitoring dasar sudah disediakan |
| 288 | - Biaya lebih mudah diperkirakan untuk tim kecil |
| 289 | |
| 290 | ## Metrics DevOps yang Penting |
| 291 | |
| 292 | ### DORA Metrics |
| 293 | (DevOps Research and Assessment) |
| 294 | |
| 295 | 1. **Deployment Frequency** |
| 296 | - Elite: Multiple deploys per day |
| 297 | - High: Once per day to once per week |
| 298 | - Medium: Once per week to once per month |
| 299 | - Low: Less than once per month |
| 300 | |
| 301 | 2. **Lead Time for Changes** |
| 302 | - Elite: Less than 1 hour |
| 303 | - High: 1 day to 1 week |
| 304 | - Medium: 1 week to 1 month |
| 305 | - Low: More than 1 month |
| 306 | |
| 307 | 3. **Mean Time to Recover (MTTR)** |
| 308 | - Elite: Less than 1 hour |
| 309 | - High: Less than 1 day |
| 310 | - Medium: 1 day to 1 week |
| 311 | - Low: More than 1 week |
| 312 | |
| 313 | 4. **Change Failure Rate** |
| 314 | - Elite: 0-15% |
| 315 | - High: 16-30% |
| 316 | - Medium: 31-45% |
| 317 | - Low: 46-60% |
| 318 | |
| 319 | ## Roadmap Menjadi DevOps Engineer |
| 320 | |
| 321 | ### Level 1: Fundamentals (3-6 bulan) |
| 322 | - Linux basics dan command line |
| 323 | - Git dan version control |
| 324 | - Basic networking (DNS, HTTP, TCP/IP) |
| 325 | - Programming atau scripting (Python, Bash, JavaScript) |
| 326 | |
| 327 | ### Level 2: Core DevOps (6-12 bulan) |
| 328 | - CI/CD dengan GitHub Actions atau GitLab CI |
| 329 | - Docker dan containerization |
| 330 | - Basic Kubernetes |
| 331 | - Infrastructure as Code (Terraform) |
| 332 | - Monitoring dan logging |
| 333 | |
| 334 | ### Level 3: Advanced (12+ bulan) |
| 335 | - Advanced Kubernetes (Helm, Operators) |
| 336 | - Service mesh (Istio, Linkerd) |
| 337 | - Advanced networking dan security |
| 338 | - Multi-cloud strategies |
| 339 | - Chaos engineering |
| 340 | |
| 341 | ## Kesalahan Umum dalam DevOps |
| 342 | |
| 343 | 1. **Terlalu fokus ke tools** - Tools penting, tapi cara kerja tim tetap penentu utama |
| 344 | 2. **Membuat silo baru bernama "tim DevOps"** - Kalau semua dilempar ke satu tim, masalah kolaborasi belum selesai |
| 345 | 3. **Mengotomasi proses yang masih kacau** - Rapikan proses dulu, baru otomasi |
| 346 | 4. **Mengabaikan security** - Menambah belakangan biasanya lebih mahal dan lebih merepotkan |
| 347 | 5. **Deploy tanpa monitoring** - Sulit memperbaiki sistem kalau Anda tidak tahu apa yang sedang terjadi |
| 348 | |
| 349 | ## Kesimpulan |
| 350 | |
| 351 | DevOps bukan sekadar kumpulan tools. Intinya adalah membangun alur kerja yang lebih rapi antara penulisan kode, pengujian, deployment, dan operasional aplikasi. |
| 352 | |
| 353 | Kalau Anda baru mulai, cukup fokus pada dasar-dasarnya dulu: version control yang disiplin, test otomatis, deployment yang bisa diulang, dan monitoring yang masuk akal. Setelah itu, baru tambah tool dan proses lain sesuai kebutuhan tim. |