Berhenti Mencampur Environment: Mengapa State Dev dan Prod Tidak Boleh Bersentuhan

Anda memiliki tiga direktori: dev, staging, dan prod. Masing-masing berisi file konfigurasi, catatan state, dan definisi resource. Saat perlu memperbarui aturan firewall, Anda membuka ketiga direktori dan melakukan perubahan yang sama tiga kali. Suatu sore, Anda lupa memperbarui staging. Dua minggu kemudian, deployment ke staging gagal karena firewall memblokir koneksi yang berfungsi di tempat lain. Tidak ada yang menyadari sampai rilis terhambat.

Situasi ini umum terjadi. Tim memulai dengan satu environment, lalu menambah yang lain, dan seterusnya. Pemisahan terasa jelas karena folder memiliki nama berbeda. Namun pemisahan itu hanya kosmetik. Masalah sebenarnya adalah orang yang sama, alat yang sama, dan pola akses yang sama dapat menyentuh setiap environment tanpa ada pengaman.

Masalah Sebenarnya dengan Pemisahan Environment

Pemisahan environment bukan tentang nama folder. Ini tentang memastikan perubahan di pengembangan tidak pernah secara tidak sengaja memengaruhi produksi, dan pengujian di staging benar-benar mencerminkan kondisi produksi.

Saat Anda menggunakan file state yang sama untuk semua environment, Anda menciptakan satu titik kegagalan. Kesalahan di pengembangan dapat menghapus resource produksi. Pipeline CI yang salah konfigurasi dapat menerapkan nilai staging ke infrastruktur produksi. Ini bukan risiko teoretis. Ini terjadi ketika tim berbagi file state, berbagi backend, atau berbagi kredensial akses antar environment.

Tujuannya adalah membuat tidak mungkin untuk secara tidak sengaja memodifikasi produksi saat bekerja di pengembangan. Itu membutuhkan lebih dari sekadar disiplin. Ini membutuhkan pemisahan struktural.

Tiga Pendekatan untuk Pemisahan Environment

1. Direktori Terpisah

Diagram berikut memetakan setiap pendekatan beserta struktur dan karakteristik utamanya:

flowchart TD subgraph Approach1["1. Direktori Terpisah"] A1[Kode + Konfigurasi + State per environment] --> D1[dev] A1 --> S1[staging] A1 --> P1[prod] end subgraph Approach2["2. Struktur Bersama + File Konfigurasi"] A2[Kode Bersama] --> C2[File Konfigurasi] C2 --> D2[dev] C2 --> S2[staging] C2 --> P2[prod] A2 -.->|backend state sama| D2 A2 -.->|backend state sama| S2 A2 -.->|backend state sama| P2 end subgraph Approach3["3. Backend State Terpisah"] A3[Kode + Konfigurasi Bersama] --> D3[dev] A3 --> S3[staging] A3 --> P3[prod] D3 --> B1[Backend dev] S3 --> B2[Backend staging] P3 --> B3[Backend prod] end Approach1 -.->|duplikasi tinggi| L1[Sederhana tapi mudah melenceng] Approach2 -.->|isolasi sedang| L2[Duplikasi lebih sedikit, risiko bersama] Approach3 -.->|isolasi penuh| L3[Terbaik untuk skala & keamanan]

Ini adalah pendekatan paling sederhana. Anda membuat folder untuk setiap environment: dev/, staging/, prod/. Setiap folder berisi file konfigurasi dan file state sendiri. Saat menjalankan perintah, Anda menentukan folder mana yang akan digunakan.

Ini bekerja dengan baik untuk tim kecil dengan sedikit environment. Anda dapat melihat perbedaan antar environment dengan membandingkan file secara berdampingan. Strukturnya mudah dipahami. Anggota tim baru dapat menemukan apa yang mereka butuhkan tanpa bertanya.

Masalah muncul ketika environment berbagi sebagian besar konfigurasi. Development dan staging mungkin hanya berbeda dalam ukuran server dan nama database. Saat perlu mengubah pengaturan keamanan, Anda harus memperbarui tiga file. Melupakan satu file menciptakan penyimpangan yang tidak terlihat. Seiring waktu, environment menyimpang hingga staging tidak lagi mewakili produksi.

2. Struktur Bersama dengan File Konfigurasi Terpisah

Alih-alih menduplikasi seluruh konfigurasi, Anda menyimpan satu set definisi resource dan file terpisah untuk nilai spesifik environment. File utama mendefinisikan logika dan struktur. File konfigurasi menyimpan nilai seperti nama server, ukuran instance, dan string koneksi.

Pendekatan ini mengurangi duplikasi. Anda menulis definisi resource sekali. Saat mengubah aturan firewall, Anda mengubahnya di satu tempat. File spesifik environment hanya berisi nilai yang benar-benar berbeda.

Trade-off-nya adalah kompleksitas. Anda perlu memahami bagaimana file konfigurasi digabungkan dengan definisi utama. Anda perlu memastikan setiap environment memiliki file konfigurasi yang benar. Nilai yang hilang dapat menyebabkan deployment gagal atau, lebih buruk, menggunakan nilai default yang salah untuk environment tersebut.

3. Backend State Terpisah

Ini adalah pendekatan paling matang. Setiap environment menggunakan backend berbeda untuk menyimpan file state. File state mencatat setiap resource yang telah dibuat dan dikelola. Ketika backend terpisah, state development tidak dapat bercampur dengan state produksi secara tidak sengaja.

Berikut adalah contoh konkret cara mengonfigurasi backend state terpisah di Terraform menggunakan S3:

# konfigurasi backend untuk environment produksi
terraform {
  backend "s3" {
    bucket = "my-company-tfstate"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

Untuk environment staging, Anda akan menggunakan bucket yang sama tetapi key yang berbeda:

terraform {
  backend "s3" {
    bucket = "my-company-tfstate"
    key    = "staging/terraform.tfstate"
    region = "us-east-1"
  }
}

Dan untuk development:

terraform {
  backend "s3" {
    bucket = "my-company-tfstate"
    key    = "dev/terraform.tfstate"
    region = "us-east-1"
  }
}

File state setiap environment disimpan di bawah prefiks terpisah dalam bucket S3 yang sama. Anda kemudian dapat menerapkan kebijakan akses di tingkat bucket atau prefiks, memastikan bahwa pengembang hanya dapat membaca dan menulis prefiks dev/ sementara akses produksi dibatasi hanya untuk pipeline CI/CD Anda.

Anda dapat menerapkan kebijakan akses di tingkat backend. Anggota tim pengembangan hanya dapat mengakses backend development. Tim Operasi atau SRE memegang akses ke backend produksi. Seorang pengembang yang menjalankan perintah dari laptop mereka tidak dapat menyentuh resource produksi karena kredensial mereka tidak memiliki akses ke backend produksi.

Pemisahan ini sangat penting karena file state berisi informasi sensitif. State produksi biasanya mencatat alamat IP server, koneksi database, dan konfigurasi keamanan. Jika state produksi dan development disimpan di tempat yang sama, kebocoran atau perubahan yang tidak sengaja akan memengaruhi kedua environment. Dengan backend terpisah, Anda dapat menerapkan kebijakan keamanan yang berbeda untuk setiap environment.

Kapan Menggunakan Setiap Pendekatan

Pilih direktori terpisah ketika proyek Anda kecil, Anda memiliki sedikit environment, dan resource berbeda secara signifikan antar environment. Ini adalah titik awal yang baik, tetapi rencanakan untuk beralih darinya seiring pertumbuhan tim.

Pilih struktur bersama dengan file konfigurasi terpisah ketika environment Anda memiliki struktur yang sama tetapi nilai yang berbeda. Ini bekerja dengan baik untuk tim yang telah menstandarisasi infrastruktur mereka dan hanya perlu memvariasikan parameter seperti ukuran, region, atau penamaan.

Pilih backend state terpisah ketika tim Anda besar, produksi harus dilindungi secara ketat, atau Anda memerlukan jejak audit untuk setiap perubahan. Ini adalah pendekatan yang berskala seiring kompleksitas organisasi.

Sisi Kebijakan dari Pemisahan Environment

Pemisahan teknis hanya setengah dari solusi. Anda dapat memiliki pemisahan backend yang sempurna, tetapi jika setiap anggota tim memiliki akses ke backend produksi dari laptop mereka, pemisahan itu tidak berarti.

Pemisahan environment membutuhkan kebijakan. Siapa yang dapat membaca state produksi? Siapa yang dapat memodifikasinya? Siapa yang dapat menyetujui perubahan pada infrastruktur produksi? Pertanyaan-pertanyaan ini harus dijawab dan ditegakkan melalui kontrol akses, bukan melalui kesepakatan lisan.

Beberapa tim menggunakan pipeline CI/CD terpisah untuk deployment produksi. Pipeline produksi hanya berjalan dari branch tertentu, memerlukan persetujuan, dan menggunakan kredensial yang tidak tersedia untuk pengembang. Ini menambahkan lapisan pemisahan lain di luar backend itu sendiri.

Daftar Periksa Praktis

  • Setiap environment menggunakan backend state yang berbeda
  • Backend produksi hanya dapat diakses dari pipeline CI/CD, bukan dari mesin lokal
  • Backend development dan staging dapat diakses oleh pengembang
  • File state dienkripsi saat diam
  • Akses ke state produksi memerlukan persetujuan dan dicatat
  • Nilai konfigurasi divalidasi sebelum mencapai produksi

Kesimpulan Konkret

Pemisahan environment bukanlah masalah struktur folder. Ini adalah masalah isolasi state. Ketika Anda memperlakukan setiap environment sebagai sistem yang sepenuhnya terpisah dengan backend state sendiri, kontrol akses sendiri, dan pipeline deployment sendiri, Anda menghilangkan kemungkinan perubahan lintas environment yang tidak disengaja. Mulailah dengan direktori terpisah jika perlu, tetapi beralihlah ke backend terpisah sebelum tim Anda tumbuh melebihi lima orang. Biaya memperbaiki gangguan produksi yang disebabkan oleh state bersama selalu lebih tinggi daripada biaya menyiapkan pemisahan yang tepat sejak awal.