Pelajari bagaimana alat HashiCorp dari Mitchell Hashimoto—Terraform dan Vagrant—membantu tim menstandarkan infrastruktur dan menciptakan alur pengiriman yang dapat diulang.
Pengiriman yang dapat diulang bukan hanya soal mengirim kode. Ini soal bisa menjawab, dengan percaya diri: Apa yang akan berubah? Mengapa akan berubah? Dan bisakah kita mengulangnya besok? Ketika infrastruktur dibangun secara manual—atau mesin pengembang mengalami drift seiring waktu—pengiriman menjadi permainan tebak: lingkungan berbeda, hasil berbeda, dan banyak “berfungsi di laptop saya”.
Terraform dan Vagrant tetap relevan karena mereka mengurangi ketidakpastian itu dari dua arah: infrastruktur bersama dan lingkungan pengembangan bersama.
Terraform menggambarkan infrastruktur (resource cloud, jaringan, layanan terkelola, dan kadang konfigurasi SaaS) sebagai kode. Alih-alih mengklik di konsol, Anda mendefinisikan apa yang Anda inginkan, meninjau rencana, dan menerapkan perubahan secara konsisten.
Tujuannya bukan “tampil keren”. Ini membuat perubahan infrastruktur terlihat, bisa ditinjau, dan dapat diulang.
Vagrant membuat lingkungan pengembangan yang konsisten. Ia membantu tim menjalankan setup dasar yang sama—OS, paket, dan konfigurasi—baik mereka di macOS, Windows, atau Linux.
Meski Anda tak menggunakan mesin virtual setiap hari lagi, gagasan inti Vagrant tetap penting: pengembang harus memulai dari lingkungan yang sudah teruji yang sesuai dengan bagaimana perangkat lunak sebenarnya berjalan.
Ini adalah panduan praktis yang ditujukan untuk non-spesialis yang membutuhkan lebih sedikit jargon dan lebih banyak kejelasan. Kita akan membahas:
Pada akhir, Anda seharusnya bisa mengevaluasi apakah Terraform, Vagrant, atau keduanya cocok untuk tim Anda—dan bagaimana mengadopsinya tanpa menambah lapisan kompleksitas baru.
Mitchell Hashimoto paling dikenal karena membuat Vagrant dan ikut mendirikan HashiCorp. Kontribusi yang bertahan bukan hanya satu produk—melainkan gagasan bahwa tooling bisa menyandi alur kerja tim menjadi sesuatu yang dapat dibagikan, ditinjau, dan diulang.
Saat orang berkata “tooling adalah jembatan,” maksudnya menutup celah antara dua kelompok yang menginginkan hasil yang sama tapi berbicara bahasa sehari-hari berbeda:
Sudut pandang Hashimoto—yang tercermin di alat HashiCorp—adalah bahwa jembatan itu adalah alur kerja yang bisa dilihat semua orang. Alih-alih meneruskan instruksi lewat tiket atau pengetahuan tribal, tim mengabadikan keputusan dalam file konfigurasi, memeriksanya ke version control, dan menjalankan perintah yang sama dengan urutan yang sama.
Alat menjadi wasit: menstandardisasi langkah, merekam apa yang berubah, dan mengurangi argumen “bekerja di mesin saya”.
Alur kerja bersama mengubah infrastruktur dan lingkungan menjadi antarmuka seperti produk:
Pembingkaian ini menjaga fokus pada pengiriman: alat bukan hanya untuk automasi, tetapi untuk kesepakatan. Terraform dan Vagrant cocok dengan pola pikir ini karena mereka menjadikan state yang diinginkan eksplisit dan mendorong praktik (versioning, review, run yang dapat diulang) yang melampaui ingatan satu orang.
Sebagian besar rasa sakit pengiriman bukan disebabkan oleh “kode buruk.” Itu disebabkan oleh lingkungan yang tidak cocok dan langkah manual tak terlihat yang tak seorang pun bisa menjelaskan sepenuhnya—sampai sesuatu rusak.
Tim sering mulai dengan setup yang bekerja lalu melakukan perubahan kecil yang wajar: upgrade paket di sini, tweak firewall di sana, hotfix sekali saja di server karena “mendesak.” Minggu kemudian, laptop dev, VM staging, dan produksi semua sedikit berbeda.
Perbedaan itu muncul sebagai kegagalan yang sulit direproduksi: tes lulus di lokal tapi gagal di CI; staging bekerja tapi produksi mengembalikan 500; rollback tidak mengembalikan perilaku sebelumnya karena sistem yang mendasari berubah.
Saat lingkungan dibuat dengan tangan, proses nyata hidup dalam memori tribal: paket OS mana yang diinstal, layanan mana yang dinyalakan, pengaturan kernel mana yang diubah, port mana yang dibuka—dan dalam urutan apa.
Orang baru kehilangan hari untuk merakit mesin yang “cukup mirip”. Insinyur senior menjadi bottleneck untuk pertanyaan setup dasar.
Kegagalan sering banal:
.env lokal, tapi produksi mengambil dengan cara berbeda—deploy gagal atau, lebih buruk, rahasia bocor.Masalah ini berujung pada onboarding yang lebih lambat, lead time lebih panjang, outage kejutan, dan rollback yang menyakitkan. Tim merilis jarang, dengan kepercayaan yang lebih rendah, dan menghabiskan lebih banyak waktu mendiagnosis “mengapa lingkungan ini berbeda” daripada memperbaiki produk.
Terraform adalah Infrastructure as Code (IaC): alih-alih mengklik di konsol cloud dan berharap Anda mengingat semua pengaturan nanti, Anda menggambarkan infrastruktur Anda dalam file.
File-file itu biasanya disimpan di Git, sehingga perubahan terlihat, bisa ditinjau, dan diulang.
Anggap konfigurasi Terraform sebagai “resep build” untuk infrastruktur: jaringan, database, load balancer, record DNS, dan izin. Anda tidak mendokumentasikan apa yang sudah Anda lakukan setelahnya—Anda mendefinisikan apa yang seharusnya ada.
Definisi itu penting karena bersifat eksplisit. Jika rekan membutuhkan lingkungan yang sama, mereka bisa menggunakan konfigurasi yang sama. Jika Anda harus merekonstruksi lingkungan setelah insiden, Anda bisa melakukannya dari sumber yang sama.
Terraform bekerja berdasarkan ide state yang diinginkan: Anda menyatakan apa yang Anda inginkan, dan Terraform menghitung perubahan yang dibutuhkan untuk mencapainya.
Loop tipikal terlihat seperti ini:
Pendekatan “pratinjau lalu terapkan” inilah yang menjadi kekuatan Terraform untuk tim: ia mendukung code review, persetujuan, dan rollout yang dapat diprediksi.
“IaC berarti otomatisasi penuh.” Tidak selalu. Anda bisa (dan sering sebaiknya) mempertahankan checkpoint manusia—terutama untuk perubahan produksi. IaC soal repeatability dan kejelasan, bukan mengeluarkan orang dari proses.
“Satu alat menyelesaikan semua masalah infrastruktur dan pengiriman.” Terraform hebat untuk provisioning dan mengubah infrastruktur, tetapi tidak menggantikan arsitektur yang baik, monitoring, atau disiplin operasional. Ia juga tidak mengelola semua hal dengan sama baiknya (beberapa resource lebih baik ditangani sistem lain), jadi paling baik digunakan sebagai bagian dari alur kerja yang lebih luas.
Tugas Vagrant sederhana: memberi setiap pengembang lingkungan kerja yang sama, sesuai permintaan, dari satu file konfigurasi.
Intinya adalah Vagrantfile, tempat Anda mendeskripsikan base image (sebuah “box”), CPU/RAM, jaringan, folder bersama, dan bagaimana mesin harus dikonfigurasi.
Karena itu berupa kode, lingkungan bisa ditinjau, versi, dan mudah dibagikan. Rekan baru bisa meng-clone repo, menjalankan satu perintah, dan mendapatkan setup yang dapat diprediksi yang mencakup versi OS yang benar, paket, layanan, dan default.
Container bagus untuk mengemas aplikasi dan dependensinya, tapi mereka berbagi kernel host. Itu berarti Anda masih bisa menemukan perbedaan pada jaringan, perilaku filesystem, layanan latar, atau tooling level-OS—terutama ketika produksi lebih mirip VM penuh daripada runtime container.
Vagrant biasanya menggunakan mesin virtual (melalui provider seperti VirtualBox, VMware, atau Hyper-V). VM berperilaku seperti komputer nyata dengan kernel dan sistem init sendiri. Itu membuatnya lebih cocok saat Anda perlu menguji hal yang container tidak modelkan dengan baik: layanan sistem, pengaturan kernel, aturan iptables, jaringan multi-NIC, atau bug yang muncul hanya pada Ubuntu 22.04, misalnya.
Ini bukan kompetisi: banyak tim menggunakan container untuk packaging aplikasi dan Vagrant untuk pengembangan dan pengujian yang realistis.
Singkatnya, Vagrant bukan soal “virtualisasi demi virtualisasi” melainkan membuat lingkungan dev menjadi alur kerja bersama yang dapat dipercaya tim Anda.
Terraform dan Vagrant menyelesaikan masalah berbeda, tapi bersama-sama mereka menciptakan jalur jelas dari “bekerja di mesin saya” menjadi “berjalan andal untuk semua.” Jembatannya adalah parity: menjaga asumsi aplikasi konsisten sementara target environment berubah.
Vagrant adalah pintu depan. Ia memberi setiap pengembang lingkungan lokal yang dapat diulang—OS sama, paket sama, versi layanan sama—sehingga aplikasi dimulai dari baseline yang diketahui.
Terraform adalah fondasi bersama. Ia mendefinisikan infrastruktur yang tim andalkan bersama: jaringan, database, compute, DNS, load balancer, dan aturan akses. Definisi itu menjadi sumber kebenaran untuk test dan produksi.
Koneksinya sederhana: Vagrant membantu Anda membangun dan memvalidasi aplikasi di lingkungan yang mirip kenyataan, dan Terraform memastikan kenyataan (test/prod) diprovision dan diubah dengan cara yang konsisten dan dapat ditinjau.
Anda tidak menggunakan alat yang sama untuk setiap target—Anda menggunakan kontrak yang sama.
DATABASE_URL dan REDIS_URL.Vagrant menegakkan kontrak itu secara lokal. Terraform menegakkannya di lingkungan bersama. Aplikasi tetap sama; hanya “dimana” yang berubah.
Laptop (Vagrant): Pengembang menjalankan vagrant up, mendapat VM dengan runtime aplikasi plus Postgres dan Redis. Mereka iterasi cepat dan menangkap masalah “bekerja di lokal” lebih awal.
Test (Terraform): PR memperbarui Terraform untuk mem-provision database test dan instance aplikasi. Tim memvalidasi perilaku terhadap keterbatasan infrastruktur nyata.
Production (Terraform): Pola Terraform yang sama diterapkan dengan pengaturan produksi—kapasitas lebih besar, akses lebih ketat, ketersediaan lebih tinggi—tanpa merombak setup.
Itulah jembatan: parity lokal yang dapat diulang memberi makan infrastruktur bersama yang dapat diulang, sehingga pengiriman menjadi progresi terkontrol, bukan penemuan ulang di setiap tahap.
Alur Terraform/Vagrant yang solid bukan soal menghafal perintah, melainkan membuat perubahan mudah untuk ditinjau, diulang, dan di-rollback.
Tujuannya: seorang pengembang bisa mulai secara lokal, mengusulkan perubahan infrastruktur bersamaan dengan perubahan aplikasi, dan mempromosikan perubahan itu ke lingkungan lain dengan minimal kejutan.
Banyak tim menyimpan aplikasi dan infrastruktur dalam repo yang sama agar cerita pengiriman tetap koheren:
/app — kode aplikasi, tes, aset build/infra/modules — modul Terraform yang dapat digunakan ulang (network, database, service aplikasi)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — lapisan environment yang tipis/vagrant — Vagrantfile plus skrip provisioning untuk mencerminkan dependensi “nyata”Pola penting adalah “envs tipis, modul tebal”: environment sebagian besar memilih input (ukuran, jumlah, nama DNS), sementara modul bersama memuat definisi resource yang sebenarnya.
Pendekatan trunk-based sederhana bekerja baik: branch fitur singkat, merge lewat pull request.
Dalam review, minta dua artefak:
terraform fmt, validate, dan menghasilkan output terraform plan untuk PR.Reviewer seharusnya bisa menjawab “Apa yang akan berubah?” dan “Apakah aman?” tanpa perlu mereplikasinya secara lokal.
Promosikan set modul yang sama dari dev → test → prod, membuat perbedaan eksplisit dan kecil:
Hindari menyalin seluruh direktori per environment. Lebih baik mempromosikan dengan mengubah variabel, bukan menulis ulang definisi resource.
Saat perubahan aplikasi membutuhkan infrastruktur baru (mis. antrean baru atau konfigurasi baru), kirimkan keduanya dalam 1 PR agar ditinjau sebagai satu kesatuan.
Jika infrastruktur dibagi di banyak layanan, perlakukan modul seperti produk: beri versi (tag/release) dan dokumentasikan input/output sebagai kontrak. Dengan begitu tim bisa meng-upgrade secara sengaja daripada tanpa sadar mengikuti “apa pun yang terbaru”.
Kekuatan Terraform bukan hanya bisa membuat infrastruktur—tetapi mengubahnya dengan aman seiring waktu. Untuk itu, ia butuh memori tentang apa yang dibuat dan apa yang diperkirakan ada.
State Terraform adalah file (atau data yang disimpan) yang memetakan konfigurasi Anda ke resource nyata: instance database mana yang terkait dengan aws_db_instance, apa ID-nya, dan pengaturan mana yang terakhir diterapkan.
Tanpa state, Terraform harus menebak apa yang ada dengan memindai semuanya kembali, yang lambat, tidak andal, dan kadang mustahil. Dengan state, Terraform bisa menghitung plan: apa yang akan ditambah, diubah, atau dihancurkan.
Karena state bisa berisi identifier resource—dan kadang nilai yang tak ingin Anda ekspose—maka harus diperlakukan seperti kredensial. Jika seseorang bisa membaca atau memodifikasinya, mereka bisa memengaruhi apa yang Terraform ubah.
Drift terjadi ketika infrastruktur diubah di luar Terraform: edit konsol, hotfix jam 2 pagi, atau proses otomatis yang memodifikasi pengaturan.
Drift membuat plan mendatang menjadi mengejutkan: Terraform mungkin mencoba “membatalkan” perubahan manual, atau gagal karena asumsi tak lagi cocok dengan kenyataan.
Tim biasanya menyimpan state secara remote (daripada di laptop) sehingga semua orang plan dan apply terhadap sumber kebenaran yang sama. Setup remote yang baik juga mendukung:
Pengiriman yang aman kebanyakan membosankan: satu state, akses yang terkendali, dan perubahan lewat plan yang bisa ditinjau.
Terraform jadi sangat kuat saat Anda berhenti menyalin blok yang sama antar proyek dan mulai mengemas pola umum ke dalam modul.
Modul adalah paket kode Terraform yang dapat digunakan ulang yang menerima input (mis. CIDR VPC atau ukuran instance) dan menghasilkan output (mis. ID subnet atau endpoint database). Keuntungannya: lebih sedikit duplikasi, lebih sedikit setup “snowflake”, dan pengiriman lebih cepat karena tim bisa mulai dari blok bangunan yang sudah terbukti.
Tanpa modul, kode infrastruktur cenderung menyimpang menjadi varian copy/paste: satu repo mengubah aturan security group, repo lain lupa pengaturan enkripsi, yang ketiga mem-pin provider versi berbeda.
Modul menciptakan satu tempat untuk menyandi keputusan dan memperbaikinya seiring waktu. Review juga lebih mudah: alih-alih mengaudit ulang 200 baris networking tiap kali, Anda meninjau antarmuka modul (input/output) yang kecil dan modul berubah saat berevolusi.
Modul yang baik menstandarkan bentuk solusi sambil memberi ruang untuk perbedaan bermakna.
Contoh pola yang layak dimodulasi:
Hindari meng-encode setiap opsi yang mungkin. Jika modul butuh 40 input agar berguna, mungkin ia mencoba menampung terlalu banyak kasus. Pilih default yang wajar dan beberapa keputusan kebijakan kecil (enkripsi aktif, tag wajib, family instance yang disetujui), sementara jalur keluar langka dan eksplisit.
Modul bisa jadi labirin jika semua orang menerbitkan versi sedikit berbeda (“vpc-basic”, “vpc-basic2”, “vpc-new”). Sprawl biasanya terjadi saat tidak ada pemilik jelas, disiplin versioning, dan panduan kapan membuat modul baru vs memperbaiki yang ada.
Guardrail praktis:
Jika dikerjakan dengan baik, modul mengubah Terraform menjadi alur kerja bersama: tim bergerak lebih cepat karena “cara yang benar” dipaketkan, dapat ditemukan, dan dapat diulang.
Terraform dan Vagrant membuat lingkungan bisa direproduksi—tetapi juga membuat kesalahan dapat direproduksi. Token yang bocor di repo bisa menyebar ke laptop, job CI, dan perubahan produksi.
Beberapa kebiasaan sederhana mencegah kebanyakan kegagalan umum.
Perlakukan “apa yang dibangun” (konfigurasi) dan “bagaimana otentikasi” (rahasia) sebagai dua hal terpisah.
Definisi infrastruktur, Vagrantfile, dan input modul harus mendeskripsikan resource dan pengaturan—bukan password, API key, atau sertifikat privat. Sebagai gantinya, tarik rahasia saat runtime dari vault yang sudah teruji (layanan vault khusus, secret manager cloud Anda, atau store rahasia CI yang terkontrol). Ini membuat kode dapat ditinjau dan nilai sensitif diaudit.
Beri setiap aktor hanya izin yang diperlukan:
terraform plan tidak otomatis perlu izin untuk menerapkan perubahan produksi. Gunakan pemisahan peran sehingga persetujuan dan eksekusi tidak selalu orang yang sama.Hindari menyematkan kredensial di kode, dotfile lokal yang tersebar, atau “kunci tim” bersama. Rahasia bersama menghapus akuntabilitas.
Guardrail ini tidak memperlambat pengiriman—mereka mengurangi radius kerusakan saat terjadi hal buruk.
CI/CD adalah tempat Terraform berhenti menjadi “sesuatu yang dijalankan satu orang” dan menjadi alur kerja tim: setiap perubahan terlihat, ditinjau, dan diterapkan dengan cara yang sama setiap kali.
Baseline praktis adalah tiga langkah, terhubung ke pull request dan persetujuan deployment Anda:
terraform fmt -check dan terraform validate untuk menangkap kesalahan jelas lebih awal.terraform plan dan publikasikan output ke PR (sebagai artifact atau komentar). Reviewer harus bisa menjawab: Apa yang akan berubah? Di mana? Mengapa?terraform apply menggunakan revisi kode yang sama yang menghasilkan plan.# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
Kuncinya adalah pemisahan: PR menghasilkan bukti (plan), persetujuan memberi otorisasi perubahan (apply).
Vagrant tidak menggantikan CI, tetapi bisa membuat pengujian lokal terasa sekelas CI. Ketika laporan bug mengatakan “bekerja di mesin saya”, Vagrantfile bersama memungkinkan siapa pun menyalakan OS, paket, dan versi layanan yang sama untuk mereproduksi masalah.
Itu berguna untuk:
Jika tim Anda menstandarkan alur pengiriman, alat seperti Terraform dan Vagrant bekerja paling baik bila dipasangkan dengan scaffolding aplikasi yang konsisten dan langkah rilis yang dapat diulang.
Koder.ai dapat membantu sebagai platform vibe-coding: tim bisa menghasilkan baseline web/backend/mobile yang berfungsi dari chat, lalu ekspor source code dan memasukkannya ke alur kerja berbasis Git yang sama (termasuk modul Terraform dan gate plan/apply di CI). Ini bukan pengganti Terraform atau Vagrant; ini cara untuk mengurangi time-to-first-commit sambil menjaga praktik infrastruktur dan lingkungan tetap eksplisit dan dapat ditinjau.
Agar automasi tidak menjadi automasi kecelakaan:
Dengan guardrail ini, Terraform dan Vagrant mendukung tujuan yang sama: perubahan yang bisa Anda jelaskan, ulangi, dan percayai.
Bahkan alat bagus bisa menciptakan masalah baru saat diperlakukan sebagai “pasang dan lupa.” Terraform dan Vagrant bekerja terbaik saat Anda menjaga scope jelas, menerapkan beberapa guardrail, dan menahan diri dari memodelkan setiap detail kecil.
Drift jangka panjang: perubahan infrastruktur yang dibuat “sekali saja” di konsol cloud bisa perlahan menyimpang dari Terraform. Berbulan-bulan kemudian, apply berikutnya berisiko karena Terraform tak lagi menggambarkan kenyataan.
Modul terlalu kompleks: modul bagus untuk reuse, tapi bisa berubah menjadi labirin—puluhan variabel, modul bersarang, dan default “ajaib” yang hanya dipahami satu orang. Hasilnya pengiriman melambat, bukan lebih cepat.
VM lokal yang lambat: box Vagrant bisa membengkak (image besar, terlalu banyak layanan, provisioning lambat). Pengembang mulai melewatkan VM, dan lingkungan “yang dapat diulang” menjadi pilihan—sampai sesuatu rusak di produksi.
Pertahankan Vagrant saat Anda butuh lingkungan OS penuh yang cocok dengan perilaku produksi (layanan sistem, quirks jaringan, perbedaan filesystem) dan tim mendapat manfaat dari baseline “dikenal baik”.
Pindah ke container bila aplikasi berjalan baik di Docker, Anda ingin startup lebih cepat, dan tidak butuh boundary kernel penuh VM. Container sering mengurangi masalah “VM lokal lambat”.
Gunakan keduanya bila Anda butuh VM untuk meniru host (atau menjalankan infrastruktur pendukung), tetapi menjalankan aplikasi dalam container di dalam VM. Ini bisa menyeimbangkan realisme dengan kecepatan.
Suggested links: /blog/terraform-workflow-checklist, /docs, /pricing
Terraform membuat perubahan infrastruktur menjadi eksplisit, bisa ditinjau, dan dapat diulang. Daripada mengandalkan klik di konsol atau runbook, Anda meng-commit konfigurasi ke version control, menggunakan terraform plan untuk melihat dampak, lalu menerapkan perubahan secara konsisten.
Ini paling bernilai ketika banyak orang perlu memahami dan mengubah infrastruktur bersama secara aman dari waktu ke waktu.
Vagrant memberi pengembang sebuah lingkungan level-OS yang sudah teruji dari satu Vagrantfile. Itu mengurangi waktu onboarding, menghilangkan drift “works on my laptop”, dan membantu mereproduksi bug yang terkait paket OS, layanan, atau jaringan.
Ini sangat berguna ketika asumsi produksi lebih mirip VM daripada container.
Gunakan Vagrant untuk menstandarkan lingkungan lokal (OS, layanan, default). Gunakan Terraform untuk menstandarkan lingkungan bersama (jaringan, database, compute, DNS, izin).
Ide penghubungnya adalah kontrak stabil (port, env var seperti DATABASE_URL, ketersediaan layanan) yang tetap konsisten saat berpindah dari laptop → test → production.
Mulailah dengan struktur yang memisahkan blok bangunan yang dapat digunakan ulang dari pengaturan spesifik lingkungan:
/infra/modules/infra/envs/dev, /infra/envs/prod)/vagrantIni membuat promosi antar lingkungan lebih berupa , bukan menyalin/menempel ulang konfigurasi.
“State” Terraform adalah bagaimana Terraform mengingat resource nyata yang terkait dengan konfigurasi Anda. Tanpa state, Terraform tidak dapat menghitung perubahan dengan andal.
Perlakukan state seperti kredensial:
Drift terjadi saat infrastruktur nyata berubah di luar Terraform (edit konsol, hotfix darurat, proses otomatis). Itu membuat plan mendatang menjadi mengejutkan dan bisa menyebabkan Terraform mencoba membalikkan perubahan manual atau gagal.
Cara praktis mengurangi drift:
Gunakan modul untuk menstandarkan pola umum (jaringan, database, deployment layanan) tanpa menduplikasi kode. Modul yang baik memiliki:
Hindari modul yang membutuhkan 40 variabel kecuali benar-benar perlu—kompleksitas bisa memperlambat pengiriman lebih dari manfaatnya.
Pisahkan konfigurasi dan rahasia:
Vagrantfileplan vs apply, dan kontrol lebih ketat untuk produksiAnggap juga bahwa state mungkin mengandung identifier sensitif dan lindungi sesuai kebutuhan.
Pipeline minimal yang bisa diskalakan:
terraform fmt -check + terraform validateterraform plan untuk ditinjauterraform apply menggunakan revisi kode yang sama yang menghasilkan planIni membuat perubahan dapat diaudit: reviewer bisa menjawab “apa yang akan berubah?” sebelum terjadi apa pun.
Pertahankan Vagrant jika Anda butuh:
Pertimbangkan container jika Anda butuh startup lebih cepat dan aplikasi tidak bergantung pada perilaku level-VM. Banyak tim menggabungkan keduanya: container untuk aplikasi, Vagrant untuk host yang mirip produksi.