Her projenin o anı vardır: on iki ortam değişkeni mi, yoksa bir konfigürasyon dosyası mı tartışması. Cevap ölçekle ilgili. On iki faktörlü uygulamanın ilk yıllarında ortam değişkeni fazlasıyla yeter; sorun, değişken sayısı kırkı geçtiğinde, adı benzer değerleri farklı olan kırk satırın kimsenin kafasında tutulamadığında başlar. Doğru soru "hangi yaklaşım" değil, "hangi yaklaşım ne zaman" sorusudur.

On iki faktörden başlamak

Ortam değişkeninin güzelliği sadeliğidir: hiçbir dosya yok, hiçbir ayrıştırıcı yok, süreç başlarken hazır. Aynı imaj tüm ortamlara gider; değişkenler ortamla birlikte değişir. Bu, "geliştirmede çalışan kodun üretimde de aynı davranması" sözünün teknik karşılığıdır. Kural, config'i koddan ayırmaktır: veritabanı adresi kodda değil, ortamda durur.

# .env.example — gerçek değerler yok, beklenen anahtarlar var
DATABASE_URL=
REDIS_HOST=
OTURUM_GIZLI_ANAHTARI=
MAIL_PROVIDER_API_KEY=

Kırk değişkenden sonra

Değişken sayısı büyüdüğünde üç belirti sırayla çıkar. Birincisi isim çatışması: iki servis aynı değişkeni farklı anlamda kullanır. İkincisi doğrulama açığı: zorunlu bir anahtar eksik kaldığında uygulama üç saat sonra, ilk kullandığı yerde patlar. Üçüncüsü gizli bilgi yorgunluğu: otuz API anahtarı yedi farklı .env dosyasına dağılmıştır ve hangisinin geçerli olduğu bilinmez. Bu noktada konfigürasyonu katmanlara ayırmak işe yarar: varsayılanlar koda gömülü, ortam değerleri dosyada, gizliler ayrı serviste.

{
  "server": { "port": 3000, "timeoutMs": 5000 },
  "db": { "poolMax": 10 },
  "logLevel": "info"
}

Yukarıdaki gibi bir dosyanın avantajı hiyerarşidir: yapı, isim listesinden daha anlamlıdır ve şema ile doğrulanabilir. Uygulama başlarken tüm zorunlu alanları kontrol edin ve eksikse üç saniyede çökün — sessiz varsayılan, üretimde en pahalı sürprizdir.

Gizliler dosyada değil kasada

Ortam değişkeni ile dosya arasındaki kararı gizliler belirler. API anahtarı ve veritabanı şifresi repoya girmemeli, düz dosyada beklememeli; bu iş için ortam değişkeni bile bir ara duraktır. Gizli bilgi yönetim servisi — Vault, AWS Secrets Manager ya da bulut sağlayıcınızın karşılığı — tek doğruluk kaynağı olmalı, uygulama başlangıçta oradan okumalı. Dosyaya yazacaksanız bile şifreleyin ve erişimini sınırlayın.

Özet: küçük ekip ve az değişken için ortam değişkeni yeter, daha fazlası israf. Büyümeyle birlikte katmanlı dosya, şema doğrulaması ve gizli bilgi kasası ekleyin. Karar her seferinde mimari değil, ölçek sorusudur — ve ölçeği zorlamayın, belirti verince geçin.

Bir de yaşlanma sorusu var: konfigürasyon birikir. Beş yıl önce test için eklenen bayrak, bugün hâlâ ortamda dursun ve kimse elleme cesaretinde olmaz. Bu yüzden yapıyı yılda bir kez budamayı takvime yazın: hangi değişken gerçekten okunuyor, hangi varsayılan artık değişmiyor, hangi anahtarın sahibi ayrıldı? Budsız konfigürasyon, belgelenmemiş davranışın en verimli üreticisidir. Aynı gözden geçirme, ortamlar arasındaki kaymayı da görünür kılar — geliştirmede açık olup üretimde kapalı bir anahtar, çoğu zaman "bir tek üretimde yaşayan" hata demektir. Konfigürasyonu canlı bir belge gibi yönetin: okuyan, doğrulayan, arada da budayan. Onu yazan değil, okuyan doğru anladığında işe yarar.