Jenis Environment #

Tidak semua tim membutuhkan tiga environment yang sama. Startup kecil mungkin cukup dengan dev dan production. Tim yang mature dengan ratusan engineer mungkin membutuhkan lebih — termasuk environment yang hidup hanya selama satu PR open lalu hilang setelah merge. Memahami jenis-jenis environment yang ada, tujuannya, dan kapan masing-masing dibutuhkan membantumu memutuskan arsitektur environment yang tepat untuk konteks timmu.

Environment Standar #

DEV (Development)
  Tujuan    : Iterasi dan eksperimen cepat
  Dikelola  : Bersama oleh semua developer atau per-developer
  Stabilitas: Rendah — boleh down, data bisa dihapus
  Biaya     : Minimal — instance kecil, mati di luar jam kerja
  Lifecycle : Persisten, tapi resource bisa di-destroy kapan saja

STAGING / UAT (User Acceptance Testing)
  Tujuan    : Validasi akhir sebelum ke production
  Dikelola  : Tim QA + developer senior
  Stabilitas: Tinggi — harus semirip mungkin production
  Biaya     : Sedang — cukup representatif tapi tidak full scale
  Lifecycle : Persisten

PRODUCTION
  Tujuan    : Melayani pengguna nyata
  Dikelola  : Tim ops / SRE dengan akses sangat terbatas
  Stabilitas: Sangat tinggi — SLA, on-call, monitoring ketat
  Biaya     : Full scale sesuai kebutuhan traffic
  Lifecycle : Persisten, dengan change freeze pada periode kritis

Ephemeral Environment #

Ephemeral environment adalah environment yang dibuat untuk tujuan spesifik dan dihapus setelah tujuan tersebut selesai. Ini bukan konsep baru, tapi Terraform membuatnya jauh lebih praktis untuk diimplementasikan.

KAPAN EPHEMERAL ENVIRONMENT DIPAKAI:

Per-PR Environment
  Dibuat  : Saat PR dibuka
  Isi     : Konfigurasi dari branch PR tersebut
  Tujuan  : Developer bisa test perubahan di environment nyata
  Dihapus : Saat PR di-merge atau di-close

  Contoh workflow:
  PR dibuka → CI trigger → terraform apply (buat environment)
  Test selesai → PR merged → CI trigger → terraform destroy

Per-Feature Environment
  Dibuat  : Saat sprint feature dimulai
  Dihapus : Saat feature selesai dan siap naik ke staging
  Berguna : Untuk fitur besar yang butuh testing lintas tim

Performance Testing Environment
  Dibuat  : Sebelum load test dijalankan
  Isi     : Skalakan production dengan data representatif
  Dihapus : Setelah load test selesai
  Berguna : Mahal jika persisten, tidak perlu jalan terus-menerus

# Konfigurasi untuk ephemeral environment
# Biasanya dipanggil dari CI/CD dengan environment name dari branch name

variable "environment" {
  type = string
  # Untuk ephemeral: "pr-123", "feature-payment", "loadtest-q4"
}

locals {
  # Resource naming yang mencerminkan sifat ephemeral
  resource_prefix = var.environment
  # Semua resource diberi prefix agar mudah diidentifikasi dan dibersihkan
}

resource "aws_instance" "app" {
  instance_type = "t3.micro"  # Selalu minimal untuk ephemeral

  tags = {
    Name        = "${local.resource_prefix}-app"
    Environment = var.environment
    Ephemeral   = "true"  # Tag khusus untuk audit dan cleanup otomatis
    TTL         = "72h"   # Time-to-live — bisa dibaca oleh cleanup script
  }
}

Strategi Multi-Account AWS #

Untuk tim yang serius dengan keamanan dan isolasi, setiap environment sebaiknya berada di AWS account yang terpisah — bukan hanya state yang terpisah.

SINGLE ACCOUNT (tidak direkomendasikan untuk production):

  Account: 123456789
  ├── Resource Dev
  ├── Resource Staging
  └── Resource Production

  Masalah:
  - Satu credential dapat akses ke semua environment
  - Resource quotas (EC2, VPC, dll.) dibagi semua environment
  - Billing tidak terpisah per environment
  - Blast radius besar — kesalahan di dev bisa mempengaruhi production

MULTI-ACCOUNT (direkomendasikan):

  Management Account (root)
  ├── Dev Account (111111111)
  │   └── Semua resource dev
  ├── Staging Account (222222222)
  │   └── Semua resource staging
  └── Production Account (333333333)
      └── Semua resource production

  Keuntungan:
  - Isolasi penuh — credential dev tidak bisa sentuh production
  - Billing terpisah per environment
  - Blast radius kecil — kesalahan di dev terisolasi
  - Service Quota terpisah per account
  - Compliance lebih mudah — audit trail terpisah

# Konfigurasi Terraform untuk multi-account
# Setiap environment punya provider dengan assume_role yang berbeda

provider "aws" {
  region = "ap-southeast-1"

  assume_role {
    role_arn = "arn:aws:iam::${var.account_id}:role/TerraformDeployRole"
    # Role ini hanya ada di account yang spesifik
    # Terraform di-run dengan kredensial management account
    # lalu assume role ke account target
  }
}

# tfvars per environment:
# dev.tfvars:         account_id = "111111111"
# staging.tfvars:     account_id = "222222222"
# production.tfvars:  account_id = "333333333"

Menentukan Jumlah Environment yang Tepat #

PERTANYAAN UNTUK MENENTUKAN ENVIRONMENT:

1. Seberapa sering deploy ke production?
   - Beberapa kali per hari → butuh staging yang kuat
   - Seminggu sekali → staging minimal sudah cukup

2. Berapa besar tim dan seberapa sering konflik terjadi?
   - Tim kecil (< 5 dev) → dev bersama sudah cukup
   - Tim besar (> 10 dev) → pertimbangkan per-dev environment
     atau ephemeral per-PR

3. Apakah ada kebutuhan compliance atau audit?
   - Ada (PCI-DSS, HIPAA, SOC2) → multi-account wajib
   - Tidak ada → single account dengan IAM boundaries sudah cukup

4. Apakah pernah ada insiden "bug lolos ke production"?
   - Sering → tambah layer testing environment
   - Jarang → environment saat ini mungkin sudah cukup

RULE OF THUMB:
  Startup early-stage  → Dev + Production (2 environment)
  Tim growing          → Dev + Staging + Production (3 environment)
  Tim mature           → Dev + Staging + Production + Ephemeral (4+)
  Enterprise           → Multi-account, per-region, per-compliance scope

Environment Naming Convention #

Konsistensi penamaan sangat membantu saat resources dari berbagai environment ada di satu tampilan (billing console, monitoring dashboard).

# Pola penamaan yang umum
locals {
  # Format: <project>-<environment>-<component>
  # Contoh:  myapp-production-api
  #          myapp-dev-database
  #          myapp-pr123-web

  name_prefix = "${var.project}-${var.environment}"

  common_tags = {
    Project     = var.project
    Environment = var.environment
    ManagedBy   = "terraform"
    # Tag ini memudahkan filtering di billing dan monitoring
  }
}

resource "aws_instance" "api" {
  # ...
  tags = merge(local.common_tags, {
    Name      = "${local.name_prefix}-api"
    Component = "api"
  })
}

Ringkasan #

  • Tiga environment standar: dev (iterasi cepat), staging (validasi akhir), production (melayani user) — masing-masing punya tujuan dan karakteristik berbeda.
  • Ephemeral environment dibuat untuk tujuan spesifik (per-PR, per-feature, load test) lalu dihapus — Terraform membuat ini praktis dengan terraform apply dan terraform destroy.
  • Multi-account AWS adalah best practice untuk tim yang serius — isolasi penuh, billing terpisah, blast radius kecil, compliance lebih mudah.
  • Jumlah environment bukan “lebih banyak lebih baik” — tentukan berdasarkan frekuensi deploy, ukuran tim, kebutuhan compliance, dan riwayat insiden.
  • Naming convention yang konsisten (<project>-<env>-<component>) memudahkan navigasi di billing console, monitoring, dan audit.
  • Tag Environment pada semua resource adalah praktik minimal yang harus selalu ada — memudahkan cost allocation dan filtering.

← Sebelumnya: Apa itu Environment?   Berikutnya: Workspace →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact