Microsoft AZ-400: Sürüm Yönetimi ve Dağıtım Stratejileri — Çalışma kılavuzu

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft DevOps Engineer Expert AZ-400 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Azure’da sürüm yönetimi, kullanılabilirliği korurken geri bildirimi hızlandıran, tekrarlanabilir ve ilke tabanlı teslimata dayanır. Dağıtım stratejilerinde, kapılı doğrulamalarda (gated validations), halka tabanlı sunumda (ring-based exposure) ve özellik bayraklı karanlık lansmanlarda (feature-flagged dark launches) uzmanlaşmak, ekiplerin güvenlikten ödün vermeden sürekli teslimat yapmasını sağlar. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager ve Azure App Configuration; aşamalı teslimat (progressive delivery), çoklu ortam düzenlemesi (orchestration) ve denetlenebilir değişiklik kontrolü için bütünleşik bir araç zinciri sunar. Bu bölümde, her bir yeteneğin ne zaman ve nasıl kullanılacağı, bunların birbirine nasıl bağlanacağı ve üretim seviyesindeki işlem hatlarında (pipeline) hangi geri alma (rollback) ve belgelendirme uygulamalarının beklendiği açıklanmaktadır.

Dağıtım Stratejileri ve Aşamalı Teslimat

Mavi-yeşil (blue-green) (kırmızı-siyah olarak da bilinir), mevcut sürüm (mavi) trafiğe hizmet verirken yeni sürümü paralel bir ortama (yeşil) dağıtır. Azure App Service’te, dağıtım yuvaları (deployment slots) mavi-yeşil stratejisini uygular: hazırlık (staging) yuvasına dağıtım yapın, uygulamayı ısıtın (warm up) ve ardından bir yuva takası (slot swap) gerçekleştirin. Geri alma, yuvaları tekrar takas ederek anında gerçekleşir; bu nedenle mavi-yeşil en hızlı geri alma seçeneğidir. Trafik yönlendirilmeden önce bağlamaları (bindings) ve uygulama ayarlarını doğrulamak için yuva takaslarını “Önizlemeli Takas” (Swap with preview) özelliğiyle birlikte kullanın.

Kanarya (canary) dağıtımı, önce kullanıcıların küçük bir bölümüne dağıtım yapar, ardından sistem sağlığı korundukça trafiği aşamalı olarak artırır. Azure’da kanarya dağıtımını şu yöntemlerle uygulayabilirsiniz:

• Uygulama katmanında eski ve yeni arka uçlar (backend) arasında trafiği bölmek için sağlık yoklamaları (health probes) ve WAF ile birlikte Azure Front Door ağırlıklı yönlendirme (weighted routing) kullanmak.
• Bölge düzeyinde kontrole ihtiyaç duyduğunuzda, DNS tabanlı, küresel kanarya dağıtımları için Azure Traffic Manager ağırlıklı uç noktaları (weighted endpoints) kullanmak.
• Ingress (ör. NGINX kanarya ek açıklamaları) veya service mesh trafik bölme (traffic splitting) yoluyla AKS kanarya dağıtımı. Kapılar (gates), bir sonraki aşamaya geçmeden önce hata bütçelerini (error budgets), gecikme yüzdeliklerini (latency percentiles) ve doygunluğu (saturation) değerlendirmelidir.

Kademeli güncellemeler (rolling updates), örnekleri (instance) yavaş yavaş değiştirerek çift filo maliyetinden kaçınır. AKS’te, rollingUpdate‘i maxSurge ve maxUnavailable ile yapılandırın; readiness/liveness problarının ve PDB’lerin (Pod Disruption Budgets) kullanılabilirliği koruduğundan emin olun. VM Scale Sets için, uygulama sağlık yoklamaları (application health probes) ile kademeli yükseltme ilkelerini (rolling upgrade policies) kullanın. Kademeli güncelleme ekonomiktir ancak sistemsel gerilemelerden (systemic regressions) kurtulması mavi-yeşil dağıtıma göre daha yavaştır.

Özellik bayrakları (feature flags), sürüm yayınını (release) dağıtımdan (deploy) ayırır. Karanlık lansman (dark launching), özellikleri kullanıcılara sunmadan altyapıyı test etmek için kod yollarını varsayılan olarak devre dışı bırakılmış şekilde dağıtır. Bayrakları, maliyetli geçişleri (migrations) kontrol etmek, kullanıcı arayüzünü (UI) aşamalı olarak açmak ve sorunlu davranışları hızla sonlandırmak için kullanın. Bu yöntem, kanarya ve halka dağıtımlarını tamamlar: geniş çapta dağıtım yapın, ardından aşamalı olarak etkinleştirin.

Halka tabanlı dağıtım (ring-based deployment), kullanıcı grupları (cohorts) arasında aşamalı sunumu resmileştirir. R0 (iç kullanıcılar), R1 (kanarya müşterileri), R2 (tek bir bölge) ve R3+ (küresel) gibi halkalar tanımlayın. Bir sonraki halkaya geçiş kriterleri nesnel olmalıdır: SLO uyumluluğu, Sev2+ seviyesinde olay olmaması ve kabul edilebilir iş KPI’ları. Halkaları, trafiği erken durdurmak veya geri almak için trafik kaydırma (Front Door/Traffic Manager), ortam kontrolleri ve onay kapıları (approval gates) ile birlikte kullanın.

Aşamalı trafik kaydırma için Azure Front Door ve Traffic Manager karşılaştırması: Front Door, anlık değişiklikler, sağlık yoklamaları, oturum benzeşimi (session affinity), yol tabanlı yönlendirme (path-based routing) ve ağırlıklı bölmeler (weighted splits) ile katman 7’de çalışır; bu da onu uygulama katmanı kanarya dağıtımları ve A/B testleri için ideal kılar. Traffic Manager, DNS seviyesinde çalışır; coğrafi yönlendirme (geo-routing), bulutlar arası yük devretme (cross-cloud failover) veya bölge düzeyinde kanarya dağıtımları için daha iyidir ancak DNS TTL süreleri gibi dikkate alınması gereken noktaları vardır ve uygulama katmanı özellikleri sunmaz.

Ortamlar, Onaylar ve Kapılar

Azure Deployment Environments, koruma mekanizmaları (guardrails) ile geliştirme/test ortamlarının sağlanmasını standartlaştırır. Ortam tanımları (environment definitions), tekrarlanabilir yığınları (stacks) tanımlayan kod olarak altyapı (infrastructure-as-code) şablonlarıdır (Bicep/ARM/Terraform). Tanımlar, servise kaydedilmiş Git depoları olan kataloglarda (catalogs) yaşar ve bu sayede sürümlenmiş, keşfedilebilir ortam taslakları (blueprints) sağlar. Geliştiriciler, kurumsal ilkelerle (kotalar, RBAC, ağ yapılandırması) kısıtlanmış geliştirme/test örneklerini self-servis olarak oluşturabilir, bu da standart dışı (“snowflake”) ortamları ortadan kaldırır ve alt seviye ortamları üretim topolojisiyle uyumlu hale getirir.

Onaylar (approvals), gerektiğinde döngüye insan müdahalesini dahil eden kontroller oluşturur. Azure Pipelines’da:

• Dağıtım öncesi onaylar (pre-deployment approvals), belirlenmiş onaylayanlar izin verene kadar bir aşamayı (stage) engeller. Bunu, hazırlık (staging) ortamından üretime geçiş veya kanarya halkasının ötesine geçiş gibi yüksek riskli geçişler için kullanın.
• Dağıtım sonrası onaylar (post-deployment approvals), sürüm tamamlandı olarak işaretlenmeden önce doğrulama faaliyetlerini (Kullanıcı Kabul Testi onayı, denetim adımları) teyit eder.
• İsteklerin otomatik olarak zaman aşımına uğraması için onay zaman aşımlarını yapılandırın; süresi dolan onaylar aşamanın başarısız olmasına neden olur ve kontrolsüz sapmaları (drift) önler. Görevler ayrılığı (separation of duties) gerektiğinde birden fazla onaylayıcı veya sıralı onaylar isteyin. Tutarlı bir yönetişim için “Onaylar ve kontroller” (Approvals and checks) aracılığıyla ortamlara ve hizmet bağlantılarına (service connections) onayları uygulayın.

Sürüm kapıları (release gates), bir üst aşamaya geçmeden önce nesnel kanıtları zorunlu kılar. Azure Pipelines aşağıdaki gibi kontrolleri destekler:

• Metrikleri veya uyarıları sorgulayan Azure Monitor kontrolleri (örneğin, aktif Sev2 uyarısı olmaması, hata oranının eşiğin altında olması, p95 gecikmenin hedefin altında olması). Kapılar, başarı/başarısızlık veya zaman aşımına kadar belirli bir aralıkta yeniden değerlendirme yapar.
• Harici kalite servislerini, yük testlerini veya dahili uyumluluk uç noktalarını çağırmak için REST API çağırma (Invoke REST API) kontrolleri. Yanıtları ayrıştırın (parse) ve kriterler karşılanmazsa ilerlemeyi engelleyin.
• Sürümden önce gerekli görevlerin, hataların veya değişiklik taleplerinin doğru durumda olduğundan emin olmak için iş öğesi sorgulama (work item query) kontrolleri (örneğin, tüm “Düzeltilmesi Zorunlu” (Must Fix) hataların çözülmesi). Sürüm veya commit aralığına göre kapsamı belirlenmiş sorgular kullanın.

Sübjektif terfi kararlarından ölçülebilir terfi kararlarına geçmek için halka (ring) sınırlarında ve kanarya dağıtımı sırasında kapıları (gates) uygulayın.

Çok Ortamlı Pipeline’lar, Değişkenler ve Bağımlılıklar

Açık bağımlılıklara ve ortam kapsamına sahip çok aşamalı YAML pipeline’ları tasarlayın. Aşamalı dağıtımı (progressive rollout) modellemek için strateji blokları (runOnce, rolling, canary) içeren dağıtım işlerini (deployment jobs) kullanın ve otomatik geri alma (rollback) için preDeploy, routeTraffic, postRouteTraffic ve on: failure gibi kancaları (hook) dahil edin. Aşamalar, sonraki ortamların yalnızca önceki ortamlar kapıları (gate) ve onayları geçtikten sonra çalışmasını sağlamak için dependsOn ve koşulları (condition) bildirmelidir.

Ortama özgü yapılandırmayı şu yollarla yönetin:

• Ortama göre kapsamlandırılmış, gizli bilgiler (secret) için Azure Key Vault’a bağlanmış değişken grupları (variable groups). Her aşama için gruplara referans verin ve hassas değerleri kaynak kontrolü dışında tutun.
• Hizmetler arası dağıtımları standartlaştırmak ve ortama özgü değerleri (bağlantı dizeleri, özellik bayrağı varsayılanları, Front Door ağırlıklandırması) geçirmek için YAML şablonları ve çalışma zamanı parametreleri.
• appsettings ve Kubernetes manifestoları için tokenizasyon veya dönüştürme görevleri kullanarak kod olarak yapılandırmada sapma olmamasını (drift-free) sağlayın.

Birden çok ortama yapılan dağıtımlar için, yükseltme (promotion) ile birlikte değişmez (immutable) yapıtları (artifact) tercih edin (bir kez oluştur, çok kez dağıt). Aynı yapıtın dev’den prod’a akışı sırasında izlenebilirliği sürdürmek için iş öğelerini (work item) commit’lere ve build’lere bağlayın; bu, doğru sürüm notları ve denetimler sağlar.

Geri Alma (Rollback) Stratejileri ve Veritabanı Hususları

Dağıtım yapmadan önce geri alma işlemlerini planlayın:

• Otomatik geri alma, insan müdahalesi olmadan geri dönmek için sağlık sinyallerini kullanır. AKS’te, maxSurge/maxUnavailable değerlerini ihtiyatlı bir şekilde ayarlayın ve başarısız dağıtımlarda otomatik geri almayı etkinleştirin; önceki bir ReplicaSet’i tetiklemek için kubectl rollout undo komutunu kullanın veya dağıtım stratejisi başarısızlık kancalarına (failure hooks) güvenin. Azure App Service’te, slot takasını geri almak anlıktır; otomatik olarak karar vermek için bunu sağlık kontrolleri (health check) ve dağıtım kapıları (deployment gate) ile eşleştirin.
• Manuel geri alma, kurtarmanın operatör kararı gerektirdiği durumlarda (veri riski, kısmi başarısızlık) uygundur. Front Door/Traffic Manager ağırlıklarını yeniden yönlendiren, slot takaslarını geri alan veya bilinen son iyi build’i yeniden dağıtan tek tıklamalık pipeline görevleri sağlayın. Önceki yapıtı (artifact) her zaman hazır bulundurun ve karar sürecini belgeleyin.
• Veritabanı geri alması ekstra özen gerektirir. Geriye dönük uyumsuz değişikliklerden kaçının. Genişlet-daralt (expand-contract) yöntemini kullanın: okuma/yazma işlemleri uyumlu kalırken sütunlar/tablolar ekleyin ve bunları doldurun; gerekirse her iki şemaya da yazan kodu dağıtın; kullanımdan kaldırılan öğeleri yalnızca daha sonra kaldırın. Azure SQL Database için şunları birleştirin:
  • İdempotent, sürüm bilgisi içeren betikler ve dağıtım öncesi/sonrası doğrulama ile DACPAC veya migration framework’leri (EF Core).
  • Kilit çekişmesini (lock contention) en aza indirmek için çevrimiçi işlemler (sürdürülebilir indeks yeniden oluşturma, bölüm değiştirme).
  • Veri kaybı riskini kabul ederek son çare olarak belirli bir zamana geri yükleme (point-in-time restore) ve aktif coğrafi çoğaltma (active geo-replication).
  • Herhangi bir şema düşürme işleminden önce özellikleri bayraklar (flag) aracılığıyla kapatın. Yükseltmeleri (promotion), Azure Monitor ve Query Store’da yakalanan veritabanı sağlığına (DTU/CPU, deadlock’lar) göre kapı denetiminden geçirin.

Azure App Configuration ile Özellik Bayrakları ve Sürüm Notları Otomasyonu

Azure App Configuration, .NET, Java, Node.js ve diğerleri için SDK’lar ile özellik yönetimini merkezileştirir. Bayrakları ortama veya dağıtım halkasına (ring) göre kapsamlandırmak için etiketler kullanın ve uygulamaların yeniden dağıtıma gerek kalmadan değişiklikleri alması için dinamik yenilemeyi etkinleştirin.

• Hedefleme filtreleri, kullanıcı/grup, talep (claim), cihaz veya özel niteliklere dayalı olarak ayrıntılı etkinleştirmeye olanak tanır. Dağıtım halkalarıyla (ring) uyumlu hale getirmek için kohortlar (örneğin, şirket içi kiracılar, VIP müşteriler) tanımlayın.
• Yüzdesel dağıtım, özellikleri kademeli olarak rastgele bir alt kümeye sunar. %1-5 ile başlayın, KPI’ları doğrulayın, ardından oranı artırın. Kullanıcı ve trafik seviyelerinde katmanlı kontrol için Front Door ağırlıklandırması ile koordine edin.
• Acil durdurma anahtarları (kill switch), bir olay meydana geldiğinde bir özelliği anında devre dışı bırakır. Yüksek riskli yolları (ödemeler, veri yazma işlemleri) çalıştırmak için sıfır dağıtım gerektiren genel bir kapatma anahtarı ile koruyun. Denetim için tüm anahtar durum değişikliklerini günlüğe kaydedin ve olaylarla ilişkilendirin.

İzlenebilirlik ve iletişim sağlamak için sürüm notlarını otomatikleştirin:

• Commit mesajlarının ve PR’ların kimliklere (ID) referans vermesini zorunlu kılarak iş öğesi ilişkilendirmesini uygulayın. Azure DevOps, derlemeleri (build) ve sürümleri (release) iş öğeleri ve commit’lerle otomatik olarak ilişkilendirir.
• İş hatlarında (pipeline), hedef ortama yapılan son başarılı dağıtımdan bu yana yapılan değişiklikleri ve iş öğelerini listelemek için Generate Release Notes görevini veya REST API çağrılarını kullanarak değişiklik günlükleri (changelog) oluşturun. Özellikler, düzeltmeler, çığır açan değişiklikler (breaking change) ve veritabanı geçişleri için bölümler içeren Markdown çıktısı alın.
• Notları proje Wiki’sinde yayınlayın, bir derleme yapıtı (build artifact) olarak paketleyin ve sürüme ekleyin. Uyumluluk için dağıtım meta verilerini (derleme numarası, commit SHA, ortam, onaylayanlar, geçilen kapılar) ekleyin.

Pratik Problem Senaryosu

Adobe, Azure’da barındırılan pazarlama sitelerine, yoğun kampanyalar sırasında dönüşüm oranlarını riske atmadan yeni bir kişiselleştirme motoru sunmalıdır. Ekibin sık sık dağıtım yapması, özelliği aşamalı olarak kullanıma sunması, SLO’ları doğrulaması ve KPI’lar düşerse anında geri alması gerekir.

1. Azure Deployment Environments ile ortamları tanımlama

• Git destekli bir katalogda uygulama, AKS, Azure SQL ve Front Door için ortam tanımları (Bicep) oluşturun. Geliştiriciler, üretimle eşdeğerliği sağlayarak ve deneyler için geçici test yığınlarını mümkün kılarak dev/test ortamlarını güvenli bir şekilde kendi kendilerine tedarik eder. ADE, harcamaları ve erişimi kontrol etmek için kotaları ve RBAC’yi zorunlu kılar.

2. Çok aşamalı YAML ile bir kez oluştur, çok kez dağıt

• Tek bir yapıt (artifact), ring-r0, ring-r1, ring-r2 ve prod aşamaları üzerinden yükseltilir. Aşamalar birbirine bağlıdır ve uygun yerlerde strategy: canary ve rolling ile dağıtım işlerini kullanarak halkalar arasında tutarlı ikili dosyalar (binary) garanti eder.

3. Eski web katmanı için App Service slot’ları ile mavi-yeşil dağıtım kullanma

• Bir hazırlık (staging) slot’una dağıtım yapın, ısınmasını bekleyin, ardından ring-r0 şirket içi kullanıcıları için değiştirin (swap). Adobe’nin SLO’ları gerilerse, slot’u geri değiştirmek (slot swap back) sıfıra yakın kesinti süresiyle en hızlı geri almayı sağlar.

4. Azure Front Door ağırlıklı yönlendirme ile kanarya dağıtımı sunma

• Hem eski hem de yeni kişiselleştirme arka uçlarını (backend) kaydedin. ring-r1’deki yeni arka uca %1 trafikle başlayın. Front Door sağlık denetimleri (health probe) ve anlık ağırlık güncellemeleri, trafik modellerine uygun güvenli ve hızlı ayarlamalar sağlar.

5. Yükseltmeleri nesnel denetimlerle kapıdan geçirme

• Application Insights’tan alınan p95 gecikme süresi, hata oranı ve dönüşüm KPI’ları için Azure Monitor denetimleri ekleyin. Koruma metriklerini (guardrail metrics) doğrulamak için Adobe’nin dahili deney hizmetine bir REST API denetimi ekleyin. Halka ilerlemesinden önce “Düzeltilmesi Gereken” (Must Fix) hataların kapatıldığından emin olmak için bir iş öğesi sorgu denetimi yapılandırın. Kapılar (gate) periyodik olarak değerlendirme yapar ve duraksamış değişiklikleri önlemek için zaman aşımına uğrar.

6. Kritik geçişlerde onayları zorunlu kılma

• ring-r2 ve prod için dağıtım öncesi onaylar, pazarlama ve SRE onayını gerektirir ve havada kalan sürümleri önlemek için 4 saatlik bir zaman aşımı vardır. Dağıtım sonrası onaylar, sürümü kapatmadan önce UAT ve analitik doğrulamasının tamamlandığını teyit eder.

7. Azure App Configuration özellik bayrakları ile sunumu kontrol etme

• Yeni motorun mevcut ancak başlangıçta devre dışı olması için karanlık başlatma (dark launching) uygulayın. Şirket içi personel (ring-r0) ve seçili müşteri kohortları (ring-r1) için etkinleştirmek üzere hedefleme filtreleri kullanın. Sunumu genişletmek için yüzdesel dağıtım uygulayın. Bir acil durdurma anahtarı (kill switch), anomaliler ortaya çıkarsa motoru yeniden dağıtım yapmadan saniyeler içinde küresel olarak devre dışı bırakır.

8. Genişlet-daralt (expand-contract) geçişleri ile verileri koruma

• Önce eklemeli SQL değişikliklerini dağıtın, verileri eşzamansız olarak geriye dönük doldurun ve gerektiğinde çift yazma (dual-write) yapın. Yalnızca kararlılık kanıtlandıktan sonra kullanımdan kaldırılmış şemayı (deprecated schema) kaldırırlar. Kapılar, güvenli olmayan yükseltmeyi önlemek için DTU, kilitlenmeleri (deadlock) ve uzun süren sorguları izler.

9. Geri alma yollarını otomatikleştirme

• Dağıtım işlerindeki hata kancaları (failure hook) geri almayı tetikler: Front Door ağırlıkları yeni arka uç için %0’a döner; App Service ters bir slot değişimi gerçekleştirir; AKS,

undefined

komutunu çalıştırır. Karmaşık senaryolar için operatörler tarafından manuel tek tıklamayla geri alma seçeneği mevcut kalır.

10. Sürüm dokümantasyonunu otomatikleştirme

• İş hattı (pipeline), ilişkili iş öğelerinden ve commit’lerden Markdown sürüm notları oluşturur; etkinleştirilen özellikleri, veritabanı değişikliklerini ve geçilen kapıları vurgular. Notlar, Azure DevOps Wiki’sinde yayınlanır ve sürüme eklenerek denetim ve paydaş görünürlüğü gereksinimlerini karşılar.

Bu yaklaşım, her aracı kendi gücüne göre kullanır: güvenli, tekrarlanabilir ortamlar için ADE; yönetilen akış için YAML stratejileri ve onayları; katmanlı aşamalı teslimat için Front Door ve App Configuration; nesnel kalite kontrolü için Azure Monitor ve kapılar; ve dayanıklılık ve izlenebilirlik için otomatik geri almalar ve sürüm notları.

← Konteynerleştirme ve Kubernetes · Tüm alanlar · Güvenlik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Microsoft'a göz atın →