Umbraco ve .NET’te ortam ayarlarını ayırmak

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: ASP.NET Core / Umbraco ortam ayrımı — Uygulamanın hedef sürümü, desteklenen SDK/runtime ve deneme veri kaynağı hazır olmalı.

1. Uygulama ve host modelini belirleyin
2. Ortak ve ortama özel ayarı ayırın
3. PowerShell oturumunda ortamı verip eski değeri geri getirin
4. Bash ve IIS host ayarını farklı uygulayın
5. Gerçek hedefleri sentetik veriyle kabul edin
6. Yayın paketini ve geri dönüşü eşleştirin

1. Uygulama ve host modelini belirleyin

Proje dizininde SDK/runtime ve paketleri okuyun. IIS Hosting Bundle ile konsol SDK’sı farklı bağımlılıklardır; hedef Umbraco sürümünün destek matrisini esas alın.

dotnet --info
dotnet --list-runtimes
dotnet list package --include-transitive

2. Ortak ve ortama özel ayarı ayırın

Bu JSON yalnız sır içermeyen ortak ayarı gösterir. appsettings.Staging.json dosyasında sadece o ortamın güvenli farkları tutulur; üretim connection string’i örneğe yazılmaz. Gerçek veri/medya/bildirim hedefleri ayrıca izole edilir.

{
  "Logging": {
    "LogLevel": { "Default": "Information" }
  },
  "AllowedHosts": "staging.batuhanyazici.com"
}

3. PowerShell oturumunda ortamı verip eski değeri geri getirin

Bu örnek yerel .NET denemesidir; mevcut iki environment değerini saklar ve süreç sona erdiğinde geri getirir. DOTNET_ENVIRONMENT/ASPNETCORE_ENVIRONMENT önceliği host modeline göre değiştiğinden çelişen değer verilmez. –no-launch-profile launchSettings etkisini ayırır.

$names = 'ASPNETCORE_ENVIRONMENT','DOTNET_ENVIRONMENT'
$before = @{}
foreach($name in $names) { $before[$name] = [Environment]::GetEnvironmentVariable($name,'Process') }
try {
  foreach($name in $names) { [Environment]::SetEnvironmentVariable($name,'Staging','Process') }
  dotnet run --no-launch-profile
} finally {
  foreach($name in $names) { [Environment]::SetEnvironmentVariable($name,$before[$name],'Process') }
}

4. Bash ve IIS host ayarını farklı uygulayın

Bash alt kabuğunda export yalnız deneme sürecine geçer; ana shell’in eski değerleri korunur. IIS’te IIS Manager > hedef site > Configuration Editor > system.webServer/aspNetCore > environmentVariables koleksiyonunda aynı ortam adlarını seçin veya mevcut web.config aspNetCore öğesine environmentVariables ekleyin; processPath/arguments alanlarını ezmeyin. App pool’u bakımda recycle edip yeni worker’ın startup ortam adını okuyun; tüm değişkenleri dökmeyin.

(
  export ASPNETCORE_ENVIRONMENT=Staging
  export DOTNET_ENVIRONMENT=Staging
  dotnet run --no-launch-profile
)

5. Gerçek hedefleri sentetik veriyle kabul edin

Ortam adı doğru görünse bile staging veritabanı, medya dizini, görevler ve e-posta/webhook hedefini ayrı doğrulayın. Yalnız staging’de oluşturulan sentetik kayıt üretimde görünmemeli. Bütün environment değişkenlerini loga dökmeyin.

6. Yayın paketini ve geri dönüşü eşleştirin

IIS environment koleksiyonunun önceki içeriği ve uyumlu publish/config/DB takımını geri yükleyin; hedef app pool’u kontrollü recycle edip yeni worker’ı doğrulayın. PowerShell try/finally ve Bash alt kabuğu kendi eski süreç ortamını korur. Üretim bağlantı dizesini staging’e geçici çözüm diye bağlamayın.

Beklenen sonuç: İzole uygulama Staging yapılandırmasını kullanır; dış servis ve veri bağlantıları da deneme kapsamındadır.

Sonuç farklıysa: Development banner’ı veya beklenmeyen bağlantı görülürse uygulamanın gerçek environment adı ve provider önceliğini kontrol edin.

Geri dönüş: Önceki onaylı ortam ataması ve uyumlu config dosyasına dönüp uygulamayı kontrollü yeniden başlatın.