Dev, Staging, Prod için ortam yapılandırma desenleri

Neden sabitlenmiş yapılandırma sürekli sorun çıkarıyor

Sabitlenmiş yapılandırma ilk günlerde makul görünür. Sonra bir staging ortamına, ikinci bir API'ye veya hızlı bir özellik anahtarına ihtiyaç duyarsınız ve “basit” değişiklik sürüm riskine dönüşür. Çözüm basit: ortam değerlerini kaynak dosyalarından çıkarın ve öngörülebilir bir düzende saklayın.

Yaygın sorun çıkaranlar kolayca görülür:

• Uygulamanın içine gömülü API temel URL'leri (test ederken prod'u çağırmak veya yayın sonrası dev'i çağırmak)
• Repoya işlenmiş API anahtarları (sızıntılar, beklenmedik faturalar, acil rotasyonlar)
• Sabit olarak yazılmış özellik anahtarları (bir şeyi kapatmak için kod göndermeniz gerekir)
• Sabitlenmiş analiz ve hata raporlama kimlikleri (veriler yanlış yere gider)

“Prod için sadece değiştir” alışkanlığı son dakikacı düzenlemelere yol açar. Bu düzenlemeler genellikle incelemeyi, testleri ve tekrarlanabilirliği atlar. Bir kişi bir URL değiştirir, başka biri bir anahtar değiştirir ve artık temel bir soruya cevap veremezsiniz: bu derlemeyle tam olarak hangi yapılandırma çıktı?

Yaygın bir senaryo: yeni bir mobil sürümü staging'e karşı oluşturursunuz, sonra biri yayın öncesi URL'yi prod'a çevirir. Backend ertesi gün tekrar değişir ve geri almak zorunda kalırsınız. Eğer URL sabitlenmişse, geri alma başka bir uygulama güncellemesi demektir. Kullanıcılar bekler, destek talepleri artar.

Amaç burada web, Go backend ve Flutter mobil uygulaması genelinde işe yarayan basit bir şemadır:

• koda vs yapılandırmaya neyin ait olduğuna dair net kurallar
• dev, staging ve prod için güvenli varsayılanlar
• tam yeniden derleme gerektirmeyen özellik anahtarları
• kod tabanının dışında ele alınan, döndürülebilir sırada gizli değerler

Dev, staging ve prod arasında gerçekten ne değişir

Dev, staging ve prod aynı uygulamanın üç farklı yerde çalışıyormuş gibi hissettirmeli. Amaç davranışı değil, değerleri değiştirmektir.

Değişmesi gerekenler uygulamanın çalıştığı yere veya kullanıcılar kim olduğuna bağlı olan her şeydir: temel URL'ler ve host adları, kimlik bilgileri, sandbox vs gerçek entegrasyonlar ve prod'da daha sıkı güvenlik ayarları gibi güvenlik kontrolleri.

Aynı kalması gerekenler ise mantık ve parçalar arasındaki sözleşmedir. API yolları, istek ve yanıt şekilleri, özellik isimleri ve temel iş kuralları ortama göre değişmemeli. Staging farklı davranırsa, prod'un güvenli bir provası olmaktan çıkar.

“Yeni ortam” ile “yeni yapılandırma değeri” arasındaki pratik kural: izole bir sisteme (ayrı veri, erişim ve risk) ihtiyaç duyduğunuzda yeni bir ortam oluşturun. Sadece farklı uç noktalar veya farklı sayılar gerekiyorsa, yeni bir yapılandırma değeri ekleyin.

Örnek: yeni bir arama sağlayıcısını test etmek istiyorsunuz. Küçük bir grup için güvenli şekilde etkinleştirilebiliyorsa, bir staging ortamı tutun ve bir özellik bayrağı ekleyin. Ayrı bir veritabanı ve sıkı erişim kontrolleri gerekiyorsa, o zaman yeni bir ortam mantıklıdır.

Her yerde yeniden kullanabileceğiniz pratik bir yapılandırma modeli

İyi bir kurulum bir işi iyi yapar: yanlışlıkla bir dev URL'si, test anahtarı veya bitmemiş bir özellik göndermeyi zorlaştırır.

Her uygulama (web, backend, mobil) için aynı üç katmanı kullanın:

1. Varsayılanlar: çoğu yerde işe yarayan güvenli değerler.
2. Ortam geçersiz kılmaları: dev, staging, prod için değişenler.
3. Gizli değerler: asla repoda yer almayan hassas değerler.

Kafa karışıklığını önlemek için her uygulama için bir tek gerçek kaynağı seçin ve ona sadık kalın. Örneğin backend başlatıldığında çevre değişkenlerinden okur, web uygulaması build zamanlı değişkenlerden veya dağıtım sırasında oluşturulan küçük bir runtime config dosyasından okur, mobil uygulama build zamanında seçilen küçük bir ortam dosyasından okur. Her uygulama içinde tutarlılık, aynı mekanizmayı her yerde zorlamaktan daha önemlidir.

Basit, yeniden kullanılabilir bir şema şöyle görünür:

• Varsayılanlar kodda duyarsız sabitler olarak yaşar (zaman aşımı, sayfa boyutu, yeniden deneme sayısı).
• Geçersiz kılmalar ortam-a özel dosyalarda veya ortam değişkenlerinde olur (API base URL, analytics açık/kapalı).
• Gizli değerler bir secret store'da olur ve deploy/build sırasında enjekte edilir (JWT secret, veritabanı parolası, üçüncü parti API anahtarları).

İnsanların anlayabileceği adlandırma

Her yapılandırma öğesine ne olduğunu, nerede uygulandığını ve hangi tür olduğunu cevaplayan net bir isim verin.

Pratik bir konvansiyon:

• Uygulamaya göre önek: WEB_, API_, MOBILE_
• ALL_CAPS ve alt çizgi kullanın
• Amaçla gruplayın: API_BASE_URL, AUTH_JWT_SECRET, FEATURES_NEW_CHECKOUT
• Boole'leri açık tutun: FEATURES_SEARCH_ENABLED=true

Böylece kimse “BASE_URL”in React uygulaması mı, Go servisi mi yoksa Flutter uygulaması mı olduğunu tahmin etmek zorunda kalmaz.

Adım adım: hardcode yapmadan web uygulaması yapılandırması (React)

React kodu kullanıcının tarayıcısında çalışır; gönderdiğiniz her şey okunabilir. Amaç basit: gizli değerleri sunucuda tutmak, tarayıcının yalnızca API base URL gibi “güvenli” ayarları veya uygulama adını görmesine izin vermek.

1) Build-zamanı vs runtime ne olduğuna karar verin

Build-zamanı yapılandırma bundle oluşturulurken enjekte edilir. Nadir değişen ve açığa çıkarılması güvenli olan değerler için uygundur.

Runtime yapılandırma uygulama başladığında yüklenir (örneğin uygulama ile birlikte sunulan küçük bir JSON dosyasından veya enjekte edilen bir globalden). Dağıtımdan sonra değiştirmek isteyebileceğiniz değerler için daha iyidir, örneğin API base URL'i ortamlar arasında değiştirmek.

Basit kural: değiştirmek için UI'yi yeniden derlememek istiyorsanız runtime yapın.

2) API base URL'i commitlemeden saklayın

Geliştiriciler için yerel bir dosya tutun (commit etmeyin) ve gerçek değerleri deploy hattınızda ayarlayın.

• Yerel geliştiricilik: .env.local (gitignored) içinde VITE_API_BASE_URL=http://localhost:8080 gibi kullanın
• CI/CD: build işinde VITE_API_BASE_URLi ortam değişkeni olarak ayarlayın veya deploy sırasında oluşturulan runtime config dosyasına koyun

Runtime örneği (uygulamanızın yanında servis edilen):

{ \"apiBaseUrl\": \"https://api.staging.example.com\", \"features\": { \"newCheckout\": false } }

Sonra bunu başlangıçta bir kez yükleyip tek bir yerde tutun:

export async function loadConfig() {
  const res = await fetch('/config.json', { cache: 'no-store' });
  return res.json();
}

3) Tarayıcıya yalnızca güvenli değerleri açın

React env değişkenlerindeki her şeyi açık kabul edin. Parolaları, özel API anahtarlarını veya veritabanı URL'lerini web uygulamasına koymayın.

Güvenli örnekler: API base URL, Sentry DSN (public), build versiyonu ve basit özellik bayrakları.

Adım adım: doğrulayabileceğiniz backend yapılandırması (Go)

Backend yapılandırması, tiplenmiş, ortam değişkenlerinden yüklenen ve sunucu trafik kabul etmeden önce doğrulanan bir yapı olduğunda daha güvenli kalır.

Başlamak için backend'in çalışması için gerekenleri belirleyin ve bu değerleri açık hale getirin. Tipik “zorunlu” değerler:

• APP_ENV (dev, staging, prod)
• HTTP_ADDR (örneğin :8080)
• DATABASE_URL (Postgres DSN)
• PUBLIC_BASE_URL (callback'ler ve linkler için)
• API_KEY (üçüncü parti servis için)

Sonra bunları bir struct'a yükleyin ve eksik veya yanlış formatlı bir şey varsa hızlıca hata verin. Bu sayede kısmi dağıtım sonrası değil, saniyeler içinde sorunları bulursunuz.

package config

import (
	\"errors\"
	\"net/url\"
	\"os\"
	\"strings\"
)

type Config struct {
	Env           string
	HTTPAddr      string
	DatabaseURL   string
	PublicBaseURL string
	APIKey        string
}

func Load() (Config, error) {
	c := Config{
		Env:           mustGet(\"APP_ENV\"),
		HTTPAddr:      getDefault(\"HTTP_ADDR\", \":8080\"),
		DatabaseURL:   mustGet(\"DATABASE_URL\"),
		PublicBaseURL: mustGet(\"PUBLIC_BASE_URL\"),
		APIKey:        mustGet(\"API_KEY\"),
	}
	return c, c.Validate()
}

func (c Config) Validate() error {
	if c.Env != \"dev\" && c.Env != \"staging\" && c.Env != \"prod\" {
		return errors.New(\"APP_ENV must be dev, staging, or prod\")
	}
	if _, err := url.ParseRequestURI(c.PublicBaseURL); err != nil {
		return errors.New(\"PUBLIC_BASE_URL must be a valid URL\")
	}
	if !strings.HasPrefix(c.DatabaseURL, \"postgres://\") {
		return errors.New(\"DATABASE_URL must start with postgres://\")
	}
	return nil
}

func mustGet(k string) string {
	v, ok := os.LookupEnv(k)
	if !ok || strings.TrimSpace(v) == \"\" {
		panic(\"missing env var: \" + k)
	}
	return v
}

func getDefault(k, def string) string {
	if v, ok := os.LookupEnv(k); ok && strings.TrimSpace(v) != \"\" {
		return v
	}
	return def
}

Bu, veritabanı DSN'lerini, API anahtarlarını ve callback URL'lerini koddan ve gitten uzak tutar. Barındırılan ortamlarda bu env var'ları ortam başına enjekte edersiniz, böylece dev, staging ve prod tek bir satır bile değiştirmeden farklı olabilir.

Adım adım: esnek kalan mobil yapılandırması (Flutter)

Flutter uygulamaları genellikle iki katman yapılandırma ister: build-zamanı flavor'lar (ne gönderdiğiniz) ve runtime ayarlar (uygulamanın yeni bir sürüm olmadan değiştirebilecekleri). Bunları ayırmak “sadece bir URL değişikliği”nin acil bir yeniden derlemeye dönüşmesini engeller.

1) Flavor'ları kimlik için kullanın, endpoint'ler için değil

Üç flavor oluşturun: dev, staging, prod. Flavorlar build-zamanı sabit olması gereken şeyleri kontrol etsin: uygulama adı, bundle id, signing, analytics projesi ve debug araçlarının açık olup olmadığı gibi.

Sonra sadece --dart-define (veya CI) ile duyarsız varsayılanları geçirin, böylece bunları kodda asla sabitlemezsiniz:

• ENV=staging
• DEFAULT_API_BASE=https://api-staging.example.com
• CONFIG_URL=https://config.example.com/mobile.json

Dart'ta bunları String.fromEnvironment ile okuyup başlangıçta basit bir AppConfig nesnesi oluşturun.

2) URL'leri ve anahtarları alınan bir config'e koyun

Küçük uç nokta değişiklikleri için yeniden derlemek istemiyorsanız, API base URL'i sabit olarak ele almayın. Uygulama başlatıldığında küçük bir config dosyası çekin (ve cache'leyin). Flavor sadece konfigürasyonu nereden çekeceğini belirlesin.

Pratik bölünme:

• Flavor (build-zamanı): uygulama kimliği, varsayılan config URL, hata raporlama projesi
• Uzaktan config (runtime): API base URL, özellik bayrakları, rollout yüzdeleri, bakım modu
• Gizli değerler: uygulamada asla gönderilmez (mobil binary'ler incelenebilir)

Backend'inizi taşırsanız, remote config'i güncelleyip yeni base URL'i gösterirsiniz. Mevcut kullanıcılar bir sonraki açılışta bunu alır; son cached değere güvenli bir yedek var.

Karmaşaya dönüşmeyen özellik bayrakları ve anahtarlar

Özellik bayrakları kademeli dağıtımlar, A-B testleri, hızlı kill switch'ler ve staging'de riskli değişiklikleri prod'ta açmadan önce test etmek için yararlıdır. Güvenlik kontrollerinin yerine geçmezler. Eğer bir bayrak korunması gereken bir şeyi koruyorsa, o bir bayrak değil, bir yetkilendirme kuralıdır.

Her bayrağı bir API gibi ele alın: net bir isim, bir sahibi ve bir bitiş tarihi olsun.

Niyeti açık eden adlandırma

Bayrak ON olduğunda ne olduğunu ve ürünün hangi kısmını etkilediğini söyleyen isimler kullanın. Basit bir şema:

• feature.checkout_new_ui_enabled (müşteri tarafı özellik)
• ops.payments_kill_switch (acil kapatma anahtarı)
• exp.search_rerank_v2 (deney)
• release.api_v3_rollout_pct (kademeli dağıtım)
• debug.show_network_logs (diagnostik)

Pozitif boole'leri (..._enabled) tercih edin. Arama ve denetim için sabit bir önek tutun.

Varsayılanlar, koruyucular ve temizlik

Servis down olduğunda uygulamanız kararlı sürüm gibi davranmalı: güvenli varsayılanlarla başlatın.

Gerçekçi bir model: backend'de yeni bir uç nokta yayınlayın, eskisini çalışır tutun ve release.api_v3_rollout_pct ile trafiği yavaşça taşıyın. Hatalar yükselirse, hotfix olmadan geri alın.

Bayrak yığını oluşmasını önlemek için kurallar:

• Her bayrağın bir sahibi ve “kaldırılacak” tarihi olsun
• Tam yayından sonra 1-2 sürüm içinde bayrakları kaldırın
• Önemli akışlarda bayrak değerlerini loglayın
• Bayrakları aylık gözden geçirin

Gizli değerler: depolama, erişim ve rotasyon temelleri

“Gizli” bir sızıntı olduğunda zarar verecek her şeydir. API tokenları, veritabanı parolaları, OAuth client secret'ları, imzalama anahtarları (JWT), webhook secret'ları ve özel sertifikalar gibi. Gizli olmayanlar: API base URL'ler, build numaraları, özellik bayrakları veya public analytics ID'leri.

Gizli değerleri diğer ayarlardan ayırın. Geliştiriciler güvenli yapılandırmayı serbestçe değiştirebilmeli, gizli değerler ise sadece runtime'da ve sadece gerektiği yerde enjekte edilmeli.

Gizlilerin nerede yaşaması gerekir (ortama göre)

Geliştirmede gizliler yerel ve değiştirilebilir olmalı. .env dosyası veya işletim sistemi keychain'i kullanın ve sıfırlamayı kolay yapın. Asla commit etmeyin.

Staging ve prod'da gizliler özel bir secret store'da olmalı, kod repo'da, chat log'larda veya mobil uygulamalara gömülü şekilde olmamalı.

• Web (React): gizlileri tarayıcıya koymayın. İstemci bir token'a ihtiyaç duyuyorsa, backend'iniz tarafından verilen kısa ömürlü token kullanın.
• Backend (Go): gizlileri başlatmada ortam değişkenlerinden veya bir secrets manager'dan yükleyin ve sadece bellekte tutun.
• Mobil (Flutter): uygulamayı kamuya açık olarak kabul edin. Uygulamadaki herhangi bir “gizli” çıkartılabilir, bu yüzden backend tarafından verilen token'lar ve kullanıcı oturum verileri için device secure storage kullanın.

Rotasyon temelleri (prod'u bozmadan)

Rotasyon, bir anahtarı takas edip eski istemcilerin hâlâ onu kullandığını unutunca başarısız olur. Bir örtüşme penceresi planlayın.

• Aynı anda iki geçerli gizliyi destekleyin (aktif + önceki) kısa bir süre için.
• Yeni gizliyi önce dağıtın, sonra “aktif” işaretini değiştirin.
• Kimlik doğrulama hatalarını izleyin, sonra pencere sona erdikten sonra eski gizliyi kaldırın.
• Hata ayıklamak için gizli sürümlerini (değerler değil) loglayın.

Bu örtüşme yaklaşımı API anahtarları, webhook secret'ları ve imzalama anahtarları için işe yarar. Beklenmedik kesintileri önler.

Örnek dağıtım: API URL'lerini kullanıcıları kırmadan değiştirme

Bir staging API'niz ve yeni bir prod API'niz var. Amaç trafiği aşamalar halinde taşımak ve bir sorun görünürse hızlıca geri almak. Uygulamanın API base URL'i config'ten okunuyorsa bu daha kolaydır.

Her yerde API URL'ini deploy-zamanı değeri gibi ele alın. Web uygulamasında (React) genellikle build-zamanı değeri veya runtime config dosyasıdır. Mobilde (Flutter) genellikle flavor + remote config'tir. Backend'te (Go) runtime env var'dır. Önemli kısım tutarlılık: kod tek bir değişken adı (örneğin API_BASE_URL) kullanır ve URL'yi bileşenlerin, servislerin veya ekranların içine gömmez.

Güvenli bir kademeli dağıtım şöyle olabilir:

• Prod API'yi deploy edin ve “karanlık” tutun (sadece dahili trafik) while staging varsayılan kalırken.
• Önce backend bağımlılıklarını değiştirin (backend diğer servisleri çağırıyorsa), env var'ları kullanıp hızlıca yeniden başlatarak.
• Web trafiğini küçük bir dilimde (veya sadece dahili hesaplarda) öne taşıyın.
• Mobil uygulamayı yeni kurulumla yayınlayın, ancak geçişi ertelemek için sunucu kontrollü bir bayrak tutun.
• Trafiği yavaşça artırın ve geri dönme planı hazır olsun.

Doğrulama büyük ölçüde uyumsuzlukları erken yakalamaktır. Gerçek kullanıcı değişiklikten önce, health endpoint'lerinin cevap verdiğini, auth akışlarının çalıştığını ve aynı test hesabının bir temel senaryoyu baştan sona tamamlayabildiğini doğrulayın.

Gönderimden önce hızlı kontrol listesi

Çoğu prod yapılandırma hatası sıkıcıdır: bir staging değeri kalmış, bir bayrak varsayılanı ters, veya bir bölge için API anahtarı eksik. Hızlı bir kontrol bunların çoğunu yakalar.

Deploy etmeden önce üç şeyin hedef ortama uygun olduğunu doğrulayın: endpoint'ler, gizliler ve varsayılanlar.

• Base URL'ler doğru yere işaret ediyor (API, auth, CDN, ödemeler). Web, backend ve mobile'ı ayrı kontrol edin.
• Prod'ta test anahtarları yok, dev veya staging'de prod anahtarları yok. Ayrıca anahtar isimlerinin uygulamanın beklediğiyle eşleştiğini doğrulayın.
• Özellik bayrakları güvenli varsayılanlara sahip. Riskli olanlar kapalı başlamalı ve kasıtlı olarak açılmalı.
• Build ve release ayarları eşleşiyor (bundle ID/package name, özel domain, CORS origin, OAuth redirect URL'leri).
• Gözlemlenebilirlik yapılandırıldı (loglar, hata raporlama, tracing) ve doğru ortam etiketiyle ayarlı.

Sonra hızlı bir smoke testi yapın. Bir gerçek kullanıcı akışı seçip baştan sona çalıştırın, temiz bir kurulum veya temiz bir tarayıcı profili kullanın ki cache'lenmiş token'lara bel bağlamayın.

• Uygulamayı açın ve konsol hatası olmadan yüklendiğini doğrulayın.
• Oturum açın ve kimlik doğrulama gerektiren bir API çağrısı yapın (profil, ayarlar veya basit bir veri listesi).
• Kontrol edilmiş bir hatayı tetikleyin (geçersiz girdi veya çevrimdışı mod) ve boş bir ekran değil, kullanıcı dostu bir mesaj gördüğünüzü doğrulayın.
• Logları ve hata raporlamayı kontrol edin: bir test hatası doğru ortam altında birkaç dakika içinde görünmeli.

Pratik bir alışkanlık: staging'i farklı değerlerle prod gibi ele alın. Bu, aynı yapılandırma şeması, aynı doğrulama kuralları ve aynı dağıtım şekli anlamına gelir. Sadece değerler farklı olmalı, yapı değil.

Kesinlikle sık yapılan hatalar ve kesintilere yol açanlar

Çoğu yapılandırma kesintisi egzotik değildir. Basit hatalardır; yapılandırma dosyaları, build adımları ve panolar arasında dağılmış olduğunda ve kimse “Bu uygulama şu anda hangi değerleri kullanacak?” sorusuna cevap veremediğinde ortaya çıkar. İyi bir kurulum bu soruyu kolaylaştırır.

Build-zamanı ve runtime ayarlarını karıştırmak

Yaygın tuzak: runtime değerlerini build-zamanı yerlere koymak. API base URL'i bir React build'ine gömerseniz, her ortam için yeniden derlemeniz gerekir. Sonra biri yanlış artefaktı deploy eder ve prod staging'e işaret eder.

Daha güvenli kural: build'e sadece gerçekten yayın sonrası değişmeyecek değerleri koyun (örneğin uygulama versiyonu). Ortam detaylarını (API URL'leri, özellik anahtarları, analytics endpoint'leri) mümkünse runtime tutun ve tek gerçek kaynağı belirgin yapın.

Dev endpoint'leri veya test anahtarları gönderme

Bu, varsayılanların “yardımsever” ama güvensiz olduğu zaman olur. Bir mobil uygulama config okuyamazsa dev API'yi varsayılan yapabilir veya backend bir env var eksikse yerel veritabanına düşebilir. Bu küçük bir yapılandırma hatasını tam bir kesintiye dönüştürür.

İki alışkanlık yardımcı olur:

• Kapalı başar (fail closed): gerekli bir değer eksikse erken çökün ve net bir hata verin.
• Prod'u yanlış yapılandırmayı en zor hale getirin: dev varsayılan yok, test anahtar kabul yok, debug endpoint'ler kapalı.

Gerçekçi örnek: Cuma gecesi bir release çıkar, ve prod build yanlışlıkla bir staging ödeme anahtarını içerir. Her şey “çalışır” görünür ama ödemeler sessizce başarısız olur. Çözüm yeni bir ödeme kütüphanesi değil. Üretimde staging anahtarlarını reddeden doğrulama.

Staging'in prod'dan uzaklaşmasına izin vermek

Prod ile eşleşmeyen staging yanlış güven sağlar. Farklı veritabanı ayarları, eksik background job'lar veya ekstra özellik bayrakları hataların sadece yayın sonrası görünmesine neden olur.

Staging'i yakın tutmak için aynı yapılandırma şemasını, aynı doğrulama kurallarını ve aynı dağıtım şeklini kopyalayın. Sadece değerler farklı olsun, yapı değil.

Sonraki adımlar: yapılandırmayı sıkıcı, tekrarlanabilir ve güvenli yapın

Amaç havalı araçlar değil. Amaç sıkıcı tutarlılık: aynı isimler, aynı tipler, aynı kurallar dev, staging ve prod boyunca. Yapılandırma öngörülebilir olunca yayınlar riskli hissetmez.

Öncelikle kısa ama spesifik bir yapılandırma sözleşmesini tek bir yerde yazın: her anahtarın adı, tipi (string, number, boolean), nereden gelebileceği (env var, remote config, build-zamanı) ve varsayılanı. İstemcide asla ayarlanamayacak değerler için notlar ekleyin (örneğin özel API anahtarları). Bu sözleşmeyi bir API gibi ele alın: değişiklikler inceleme gerektirsin.

Sonra hataların erken ortaya çıkmasını sağlayın. Eksik bir API base URL'in en iyi keşfedileceği yer CI'dir, dağıtımdan sonra değil. Uygulamanızın aynı şekilde yüklediği yapılandırmayı yükleyen ve kontrol eden otomatik doğrulama ekleyin:

• zorunlu değerlerin varlığı (boş string yok)
• tiplerin doğruluğu ("true" vs true hataları yok)
• prod-özel kuralların geçmesi (örneğin HTTPS zorunlu)
• özellik bayraklarının bilinen isimlere sahip olması (yazım hatası yok)
• gizlilerin repoya check-in edilmemesi

Son olarak, bir yapılandırma değişikliği yanlış olduğunda kurtarmayı kolaylaştırın. Çalışanı anlık görüntüleyin, tek bir şeyi değiştirin, hızlıca doğrulayın ve geri alma yolu tutun.

Eğer Koder.ai (koder.ai) gibi bir platformla build ve deploy yapıyorsanız, aynı kurallar geçerlidir: ortam değerlerini build ve hosting için girdiler olarak ele alın, gizlileri dışarı aktarılan kaynağa koymayın ve göndermeden önce yapılandırmayı doğrulayın. Bu tutarlılık redeploy'ları ve geri alımları rutin hissettirir.

Yapılandırma belgelenmiş, doğrulanmış ve geri alınabilir olduğunda, kesintilerin kaynağı olmaktan çıkar ve gönderme sürecinin normal bir parçası haline gelir.