Azure DevOps Server Haziran Yamaları: Sahadan Notlar ve Geçiş Rehberi
Şimdi açık konuşayım: Self-hosted Azure DevOps Server tarafında yama günleri benim için yıllardır biraz “diş hekimi randevusu” tadında geçiyor. Önemli, ertelenmemeli, ama kimse bayram havasıyla karşılamıyor. Haziran ayı yamaları da yayınlandı — hem ana Azure DevOps Server için Patch 5, hem de 2022.2 sürümü için Patch 10. Bu yazıda yamaları kuru kuruya listelemek yerine, sahada ne anlama geldiklerini, neden geciktirmemeniz gerektiğini. Türkiye’deki kurumların özelinde nelere dikkat etmesi lazım önü konuşacağım.
Açık konuşayım, 20 küsur yıllık BT deneyimimde şunu net gördüm: ALM/DevOps sunucularını yamasız bırakmak, en sessiz. En pahalı teknik borçlardan biri. Çünkü bu sunucular sadece kod barındırmıyor; pipeline secret’larını, service connection’ları, kurumun damarlarına bağlı build agent’larını da tutuyor. Birinin bu kutuya sızması (belki yanılıyorum ama) demek, üretime giden yolun tamamını ele geçirmesi demek. O yüzden “yine yama mı çıktı, sonra bakarız” lafını duyduğumda içim pek rahat etmiyor.
Hmm, bunu nasıl anlatsamdı…
Haziran Yamalarında Ne Var, Ne Yok?
Microsoft bu ay iki sürüm için yama yayınladı. Resmî tabloyu sadeleştirip Türkçe kafa yapısıyla yeniden düzenleyelim:
| Sürüm | Yama | Kim İçin Kritik? |
|---|---|---|
| Azure DevOps Server (güncel ana sürüm) | Patch 5 | Yeni kurulumlar, son sürüme geçenler |
| Azure DevOps Server 2022.2 | Patch 10 | Hâlâ 2022.2’de kalan büyük kurumlar (ki çoğu öyle) |
2022.2 için Patch 10’a gelmiş olmamız bana şunu söylüyor: O sürüm artık iyice olgunlaştı. Sürekli bakım döngüsüne girdi. Yeni özellik beklemeyin; güvenlik açıkları kapanıyor, o kadar. Yanı üretim ortamı açısından “stabil ama yaşlı” bir sürümden söz ediyoruz. Hâlâ orada kalanlar için Patch 10 atlanacak bir şey değil — özellikle internetten erişilen bir yüzünüz varsa.
Yama Notlarını Neden Okumalısınız?
Ne yalan söyleyeyim, Burada bir parantez açayım. Microsoft’un release notes’larını “boşver, nasılsa yamayı kuracağım” diye geçenleri çok gördüm. Sonra ne oluyor? Yama bir özelliğin davranışını değiştiriyor (mesela bir API’nın tepkisi kayıyor), CI/CD pipeline’larından biri sessizce kırılıyor ve ekip iki gün sebebini arıyor. Yama notlarını okumak 10 dakika sürer; gece yarısı telefonla uyanmaktan iyidir.
İtiraf edeyim, Hele bir de şu başlıklara bakın: pipeline runtime davranış değişiklikleri, Git protokolü düzeltmeleri, kimlik doğrulama tarafı (özellikle Personal Access Token ve service connection), bir de agent uyumluluğu. Bu dört başlıktan biri değiştiyse, kurmadan önce test ortamında bir tür atın; yoksa sonra uğraşırsınız.
Kurulumun Doğrulanması: CheckInstall Komutu
Microsoft yama kurulumunu doğrulamak için basit bir komut veriyor. İndirdiğiniz patch installer’ı şöyle çalıştırmanız yeterli:
# Yama dosyasının olduğu klasörde
.\AzureDevOpsServer2022.2.Patch10.exe CheckInstall
# Çıktı örneği:
# Patch is installed: True
# Installed on: 2024-06-XX
# Version: 2022.2 Patch 10Bu komut özellikle birden fazla Application Tier (AT) sunucusu olan kurumsal ortamlarda baya iş görüyor. Yamayı dört sunucuya kurdunuz; üçüncüsünde hata mı öldü, yoksa hepsi sorunsuz mu bitti? CheckInstall size net cevap veriyor.
Sahada gördüğüm en sık hata şu: Yama tek bir AT’ye kurulup “tamam bitti” denmesi oluyor. Halbuki ölçeklendirilmiş ortamda her bir AT’yi tek tek dolaşmak şart. CheckInstall’ı PowerShell döngüsüne sokup tüm sunucuları taramak en sağlıklısı.
Çoklu Sunucu Senaryosu İçin Pratik Script
Sahada kullanabileceğiniz minik bir PowerShell parçası burada; kendi ortamınıza göre uyarlayın:
$servers = @("ado-at01", "ado-at02", "ado-at03")
$patchExe = "C:\Patches\AzureDevOpsServer.Patch10.exe"
foreach ($srv in $servers) {
Invoke-Command -ComputerName $srv -ScriptBlock {
param($exe)
& $exe CheckInstall
} -ArgumentList $patchExe
}Bu kadar basit görünüyor, evet. Ama böyle basit bir script bile raporlama toplantısında “evet, tüm AT’lerde yama doğrulandı” diyebilmenizi sağlıyor (ciddiyim). Banal dürüyor olabilir; yine de denetim (audit) zamanı geldiğinde ufak ayrıntılar insanın elini rahatlatıyor.
Türkiye’deki Kurumlar Açısından Durum
İtiraf edeyim, Neyse biraz yerel bağlama girelim artık. Türkiye’de Azure DevOps (söylemesi ayıp) Server kullanan kurumların büyük çoğunluğu — gözleme dayanarak söylüyorum — finans, kamu, savunma ve telekom tarafında toplanıyor gibi dürüyor. Bu sektörlerin ortak derdi belli: Veri yurt dışına çıkmasın, kod on-prem kalsın, denetlenebilirlik tam olsun.
İlginç olan şu ki, Bundan dolayı Azure DevOps Services yerine self-hosted tercih ediliyor çoğu yerde. Gel gelelim self-hosted demek “yamayı sen kuracaksın” demek aynı zamanda.
Bulutta Microsoft işi sessizce hallediyor; sabah kalkıyorsunuz (bizzat test ettim). Yeni şeyler orada oluyor.
On-prem tarafta işe ekip mesai harcıyor,
change management süreci işliyor,
test ortamında deneme yapılıyor,
sonra prod’a alınıyor.
Türk kurumlarında bu sürecin ortalama 4-8 hafta sürdüğünü görüyorum.
Yanı Haziran yaması Ağustos sonunda prod’a giriyor.
Çok mu geç?
Bence evet.
Ama bunu hızlandırmanın yolu da yama yönetimi disiplinini gerçekten kurumsallaştırmaktan geçiyor.
Şimdi gelelim işin can alıcı noktasına.
Küçük Ekip mi, Büyük Kurum mu? Strateji Değişir
Burada ayrım yapmak gerekiyor çünkü tek doğru cevap yok:
- Küçük ekip (50 kullanıcı altı): Test ortamı kurmak için ayrı sunucu maliyetine girmek istemeyebilirsiniz; bu durumda en azından snapshot ya da backup alıp doğrudan prod’a kurmak makul olabilir çünkü geri dönüş yolunuz açık kalır.
- Orta ölçek (50-500 kullanıcı): Mutlaka staging ortamınız olsun; yamayı önce orada deneyin, kendi kilit pipeline’larınızı çalıştırın,
bir hafta bekleyin,
sonra prod’a geçin. - Büyük kurumsal (500+ kullanıcı): Burada işin şakası yok;
blue-green dağıtım,
kademeli rollout,
otomatik smoke test pipeline’ları,
geri dönüş prosedürleri…
Her şey yazılı olmalı.
Yamayı CAB (Change Advisory Board) onayından geçirmeden kurmamalısınız.
Yama Atlamanın Gizli Maliyeti
“Bir yamayı atlasam ne olur?” sorusunu sıkça duyuyorum.
Cevap basit gibi dürüyor ama değil.
Microsoft kümülatif yama mantığıyla gidiyor; yanı Patch 10 genelde Patch 9’u da kapsıyor,
Patch 8’i de,
Patch 7’yi de.
Teorik olarak atlayabilirsiniz.
Pratikte işe iki sorun var.
Birincisi şema tarafı.
Patch ler arasında bazen migration işleri oluyor;
Patch 7 ile 10 arasında atlama yapacaksanız ara şema migration’larının düzgün çalıştığından emin olmanız lazım.
Yedek almadan bu işe hiç girmeyin.
İkincisi destek hattı.
Bir sorun yaşayıp Microsoft’a açtığınızda “en son yamayı kurdunuz mu?” sorusu ilk üç sorudan biri olur genelde.
Yamasız sistemde diretirseniz destek alma süreci uzar;
bu kadar net.
Evet, doğru duydunuz.
- .
- .AzureDevOps_Configuration.veritabanI
- TÜM Collection veritabanları (.AzureDevOps_DefaultCollection ve diğerleri)
.
.
.
.
bUnLaR olmadan.bIr.sorunda.dönüş.yapamazsınız.HAFTALARCA uğraşırsınız,.sonunda.işi.Microsoft.destEk.hattıyla birlikte çözmeye çalışırsınız.Hiç tavsiye.etmem..'”
MUTLAK KURALLAR!
Soru cümlesi kısa olsun:?
Evet.
Aşağıdaki bölümde akış bozulduysa kusura bakmayın;
neyse uzatmayalım,
konumuza dönelim.
Sıkça Sorulan Sorular
Azure DevOps Server yamasını kurarken sistem çökmek zorunda mı?
Bakın, Evet, kısa bir kesinti kaçınılmaz — Yama kurulumu sırasında Azure DevOps servisleri dürüyor. Tek sunuculu kurulumlarda bu genellikle 15-45 dakika sürüyor (ciddiyim). Çoklu AT’li ortamlarda rolling update yapsanız bile bağlantı kopmaları yaşanabiliyor. Bence kullanıcılarınıza önceden haber vermek hayat kurtarıyor.
Patch 10’u atlayıp bir sonrakini beklesem olmaz mı?
Teknik olarak olur, yamalar genelde kümülatif zaten. Ama güvenlik açısından açıkçası pek önerilmez. Bilhassa internete açık bir Azure DevOps Server’ınız varsa, bilinen açıklarla beklemek ciddi risk oluşturuyor. En azından güvenlik bültenlerini takip edip kritik bir şey var mı diye bir göz atın (bu beni çok şaşırttı)
Yama sonrası build agent’lar kendi kendine güncellenir mi?
Self-hosted agent’lar genellikle otomatik güncelleniyor — Azure DevOps Server yeni agent sürümünü “tavsiye ediyor” ve agent kendini yeniliyor. Ama tecrübeme göre bu süreç bazen takılabiliyor, özellikle kısıtlı network ortamlarında. Yama bittikten sonra agent havuzunuza bir bakın, “needs update” uyarısı var mı diye.
Yama sonrası bir şeyler bozulursa geri dönebilir mıyım?
Aslında resmî bir rollback prosedürü yok. Yedeklerinizden dönmek zorunda kalırsınız. Bu yüzden yama öncesi tam yedek almak — yanı veritabanları ve dosya sistemi — bana kalırsa şart. Mümkünse önce staging ortamında test edin. VM kullanıyorsanız snapshot almak en hızlı geri dönüş yolu, bence en pratik çözüm bu.
Azure DevOps Services’e geçsem yama derdinden kurtulur muyum?
Evet, bulutta yama yönetimi tamamen Microsoft’un işi oluyor. Yeni özellikler de çok daha hızlı geliyor. Ama geçmeden önce veri ikametgâhı, network izolasyonu ve regülasyon gereksinimlerinizi muhtemelen değerlendirin. Mesela Türkiye’de kamu veya savunma sektöründeyseniz, on-prem hâlâ tek seçenek olabiliyor (şaşırtıcı ama gerçek)
Kaynaklar ve İleri Okuma
Şunu fark ettim: June Patches for Azure DevOps Server — Resmî Microsoft Blog Yazısı
Burada, şunu fark ettim: Azure DevOps Server Resmî Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments