Apa itu Environment? #
Hampir semua tim yang mengelola infrastruktur serius memiliki lebih dari satu environment. Ada dev tempat developer bereksperimen, staging yang mencerminkan production untuk pengujian akhir, dan production yang melayani pengguna nyata. Tantangannya bukan membuat masing-masing — tapi memastikan ketiganya dikelola dari konfigurasi yang sama, konsisten, dan tidak terjadi situasi di mana staging berbeda secara diam-diam dari production sehingga bug lolos tanpa terdeteksi.
Mengapa Environment Dibutuhkan #
Perbedaan environment bukan sekadar konvensi penamaan. Setiap environment punya tujuan yang berbeda, dan perbedaan tujuan itu memerlukan perbedaan konfigurasi yang terstruktur.
DEV (Development)
Tujuan : Eksperimen, iterasi cepat, debugging
Sifat : Boleh tidak stabil, data bisa dihapus kapan saja
Ukuran : Kecil, minimal — hemat biaya
Akses : Developer bebas akses penuh
Contoh : 1 instance t3.micro, DB single-AZ tanpa backup
STAGING
Tujuan : Validasi sebelum release ke production
Sifat : Harus semirip mungkin dengan production
Ukuran : Sedang — cukup untuk testing yang representatif
Akses : Terbatas — tim QA, developer senior
Contoh : 2 instance t3.small, DB dengan backup enabled
PRODUCTION
Tujuan : Melayani pengguna nyata
Sifat : Harus stabil, highly available, aman
Ukuran : Full scale sesuai kebutuhan traffic
Akses : Sangat terbatas — hanya operator terotorisasi
Contoh : 3+ instance t3.medium, DB multi-AZ dengan backup 30 hari
Apa yang Berbeda Antar Environment #
Environment yang berbeda bukan berarti konfigurasi yang berbeda total — justru strukturnya harus sama, hanya nilainya yang berbeda.
# Yang SAMA di semua environment (struktur konfigurasi):
# - Resource apa yang dibuat (VPC, subnet, EC2, RDS)
# - Bagaimana resource saling terhubung
# - Security rules dan networking topology
# - Cara deployment dilakukan
# Yang BERBEDA antar environment (nilai konfigurasi):
# - Ukuran instance (t3.micro vs t3.medium vs t3.large)
# - Jumlah instance (1 vs 2 vs 5)
# - Multi-AZ (false vs false vs true)
# - Backup retention (0 vs 7 vs 30 hari)
# - Deletion protection (false vs false vs true)
# - Nama dan tag resource
# - CIDR block VPC (10.0.0.0/16 vs 10.1.0.0/16 vs 10.2.0.0/16)
# Ini tercermin dalam variable:
variable "instance_type" {
# dev: "t3.micro", staging: "t3.small", production: "t3.medium"
}
variable "multi_az" {
# dev: false, staging: false, production: true
}
variable "backup_retention_days" {
# dev: 0, staging: 7, production: 30
}
Prinsip Environment yang Konsisten #
Ada satu prinsip yang paling sering dilanggar dalam pengelolaan multi-environment: production drift — kondisi di mana staging dan production berbeda secara diam-diam karena dikelola dengan cara yang berbeda.
ANTI-PATTERN: Environment yang tidak simetris
Dev → Dikelola dengan Terraform ✓
Staging → Dikelola dengan Terraform ✓
Production → "Sudah jalan, jangan diubah" → dikelola manual ✗
Akibat:
- Production punya resource "misterius" yang tidak ada di staging
- Bug yang lolos di staging bisa muncul di production
- Tidak ada cara untuk reproduce production environment di tempat lain
- Saat disaster recovery, tidak ada yang tahu persis kondisi production
BENAR: Semua environment dikelola dari konfigurasi yang sama
Dev, Staging, Production → semua dari konfigurasi Terraform yang sama
Perbedaan hanya pada nilai variable, bukan pada struktur konfigurasi
Tantangan Pengelolaan Multi-Environment #
TANTANGAN 1: ISOLASI STATE
Setiap environment harus punya state sendiri.
State dev tidak boleh campur dengan state production.
→ Solusi: remote backend dengan key terpisah per environment
TANTANGAN 2: ISOLASI KONFIGURASI
Perubahan di konfigurasi dev tidak boleh otomatis masuk production.
→ Solusi: workflow yang eksplisit (PR, review, promotion)
TANTANGAN 3: CREDENTIAL TERPISAH
Dev dan production tidak boleh menggunakan AWS account yang sama.
→ Solusi: AWS account terpisah per environment (multi-account strategy)
TANTANGAN 4: KONSISTENSI KONFIGURASI
Struktur konfigurasi harus sama antar environment.
→ Solusi: modul yang sama, tfvars yang berbeda
TANTANGAN 5: PROMOTION WORKFLOW
Bagaimana konfigurasi "naik" dari dev ke staging ke production?
→ Solusi: GitOps dengan branch atau tag per environment
Dua Pendekatan Utama #
Terraform menyediakan dua pendekatan utama untuk mengelola multi-environment — masing-masing dengan trade-off yang berbeda.
PENDEKATAN 1: WORKSPACE
Satu direktori konfigurasi, state terpisah per workspace.
terraform workspace new dev
terraform workspace new production
Kelebihan : Satu set kode, mudah dibuat konsisten
Kekurangan: Semua environment berbagi provider dan backend config,
sulit jika butuh AWS account terpisah per environment
PENDEKATAN 2: DIRECTORY BASED
Direktori terpisah per environment, masing-masing punya
konfigurasi dan state sendiri.
environments/dev/ → state dev
environments/staging/ → state staging
environments/production/ → state production
Kelebihan : Isolasi penuh, fleksibel untuk perbedaan besar
Kekurangan: Risiko divergensi konfigurasi antar environment
jika tidak dikelola dengan disiplin
Kedua pendekatan ini akan dibahas lebih detail di artikel berikutnya.
Ringkasan #
- Environment bukan sekadar nama — dev, staging, dan production punya tujuan berbeda yang memerlukan konfigurasi berbeda secara terstruktur.
- Struktur sama, nilai berbeda — prinsip dasar environment yang baik. Konfigurasi Terraform yang sama dipakai di semua environment, hanya nilai variable yang berbeda.
- Production drift adalah musuh utama — ketika staging tidak mencerminkan production, bug lolos tanpa terdeteksi dan disaster recovery menjadi tidak bisa diandalkan.
- Lima tantangan: isolasi state, isolasi konfigurasi, credential terpisah, konsistensi konfigurasi, dan promotion workflow.
- Dua pendekatan utama: workspace (satu konfigurasi, state terpisah) dan directory based (direktori terpisah per environment).
- Idealnya gunakan AWS account terpisah per environment untuk isolasi biaya, keamanan, dan blast radius yang lebih baik.