10.7 Deployment: Lingkungan, Konfigurasi, dan Strategi Lepas Landas

Semua aspek itu perlu dituangkan ke deployment view agar solusi benar-benar bisa dieksekusi. Saya pernah melihat tim yang sudah menyusun solution architecture dengan rapi: opsi sudah dipilih, integrasi sudah dirancang, data flow sudah didokumentasikan, security review sudah lulus, dan operability checklist sudah lengkap. Lalu ketika tiba saatnya deploy, mereka baru sadar bahwa lingkungan produksi tidak punya akses ke registry image yang dipakai. Atau konfigurasi database development berbeda dengan produksi, dan tidak ada yang tahu bagaimana cara mengelola perbedaan itu.

Berikut adalah diagram alur deployment yang merangkum lingkungan, konfigurasi, dan strategi rilis yang dibahas.

flowchart TD A([Commit]) --> B[Build & Test] B --> C[Registry Image] C --> D[Deploy ke Dev] D --> E[Verifikasi Dev] E --> F[Deploy ke Staging] F --> G[Verifikasi Staging] G --> H{Pilih Strategi} H --> I[Blue-Green] H --> J[Canary] H --> K[Rolling] I --> L[Deploy ke Production] J --> L K --> L L --> M[Verifikasi Production] M --> N{Sukses?} N -->|Ya| O[Selesai] N -->|Tidak| P[Rollback / Roll-forward] P --> L subgraph Konfigurasi CF1[Env Vars Dev] CF2[Env Vars Staging] CF3[Env Vars Production] end D --> CF1 F --> CF2 L --> CF3

Deployment view menjawab pertanyaan yang sering dianggap sepele: di mana solusi akan berjalan, bagaimana konfigurasinya diatur, dan bagaimana strategi melepasnya ke pengguna.

Lingkungan adalah lapisan pertama. Sebuah solusi biasanya melewati beberapa lingkungan: development untuk eksperimen, staging untuk integrasi dan uji coba, production untuk pengguna nyata. Setiap lingkungan punya karakteristik berbeda. Development boleh longgar, staging harus mirip produksi, dan produksi harus stabil. Masalah muncul ketika tim tidak mendokumentasikan perbedaan ini. Misalnya, tim menggunakan database yang berbeda di setiap lingkungan, lalu data staging tidak pernah sinkron dengan skema produksi. Atau environment variable yang dibutuhkan di produksi tidak ada di staging, sehingga uji coba tidak pernah mencerminkan kondisi nyata.

Konfigurasi adalah lapisan kedua. Setiap lingkungan butuh konfigurasi yang berbeda: koneksi database, API key, endpoint service lain, ambang alert, dan logging level. Konfigurasi tidak boleh diketik manual atau disimpan di dalam kode. Bayangkan seorang engineer harus mengganti konfigurasi di dua puluh file setiap kali deploy ke lingkungan baru. Itu bukan hanya rawan salah, tapi juga membuang waktu. Solusi yang baik memisahkan kode dari konfigurasi, menyimpan konfigurasi di tempat yang aman seperti vault atau environment variable, dan memastikan setiap lingkungan punya konfigurasi yang terdokumentasi.

Berikut contoh tiga file konfigurasi untuk lingkungan development, staging, dan production yang memisahkan nilai spesifik tanpa hardcode di kode.

# config/dev.yaml
database:
  url: "postgres://user:pass@localhost:5432/dev_db"
  pool_size: 5
log:
  level: "debug"
api_key: "dev-key-12345"

# config/staging.yaml
database:
  url: "postgres://user:pass@staging-db.internal:5432/staging_db"
  pool_size: 10
log:
  level: "info"
api_key: "staging-key-67890"

# config/prod.yaml
database:
  url: "postgres://user:pass@prod-db.internal:5432/prod_db"
  pool_size: 20
log:
  level: "warn"
api_key: "${PROD_API_KEY}"  # dari vault atau env var

Strategi lepas landas adalah lapisan ketiga. Ini adalah keputusan paling kritis: bagaimana solusi sampai ke pengguna tanpa mengganggu yang sudah berjalan. Ada beberapa pola yang bisa dipilih. Blue-green deployment menyediakan dua lingkungan identik, satu aktif dan satu siaga. Ketika versi baru siap, traffic dialihkan ke lingkungan siaga. Jika ada masalah, traffic bisa dikembalikan ke lingkungan lama. Canary release mengirim versi baru ke sebagian kecil pengguna dulu, lalu diperluas secara bertahap. Feature toggle memungkinkan fitur baru dimatikan dari jarak jauh tanpa harus deploy ulang.

Setiap pola punya trade-off. Blue-green membutuhkan infrastruktur dua kali lipat. Canary butuh monitoring yang granular. Feature toggle menambah kompleksitas kode. Arsitek harus memilih berdasarkan karakteristik solusi: seberapa kritis sistemnya, seberapa besar dampak jika gagal, dan seberapa cepat tim bisa merespons.

Rollback dan roll-forward adalah jaring pengaman. Rollback berarti kembali ke versi sebelumnya jika terjadi masalah. Roll-forward berarti memperbaiki masalah dengan versi baru, bukan kembali ke versi lama. Keduanya harus sudah direncanakan sebelum deploy, bukan dipikirkan saat krisis. Tim perlu tahu: berapa lama waktu yang dibutuhkan untuk rollback? Apakah data yang sudah berubah perlu dikembalikan? Apakah pengguna akan melihat error selama proses rollback?

Verifikasi adalah langkah terakhir yang sering dilewatkan. Setelah deploy selesai, tim harus memastikan bahwa solusi benar-benar berfungsi seperti yang diharapkan. Bukan hanya mengecek bahwa server menyala, tapi juga bahwa integrasi berjalan, data mengalir, dan pengguna bisa memakai fitur utama. Verifikasi otomatis lebih baik daripada manual, karena konsisten dan bisa diulang.

AI bisa membantu menyusun deployment plan dan checklist. Berikan prompt yang berisi karakteristik solusi, lingkungan yang tersedia, dan pola release yang diinginkan. AI bisa menghasilkan draft langkah-langkah deploy, daftar konfigurasi yang perlu disiapkan, skenario rollback, dan checklist verifikasi. Tapi keputusan akhir tetap di tangan arsitek, karena AI tidak tahu konteks organisasi, kebiasaan tim, dan risiko spesifik yang pernah terjadi sebelumnya.

Deployment view bukan sekadar teknis. Ini adalah jembatan antara solusi di atas kertas dan solusi yang benar-benar dipakai. Tanpa deployment view, semua rancangan indah hanya akan menjadi dokumen yang tidak pernah dieksekusi. Dan setelah solusi berjalan, kita perlu memastikan bahwa semua aspek yang sudah dirancang bisa dipantau dan dikelola, yang akan kita bahas di subbab berikutnya tentang operability.