Azure DevOps Server Nisan Yaması: Ne Geldi, Ne Yapmalı?
Geçen hafta bir müşteriden sabah 8’de telefon geldi. “Pull request’ler tamamlanamıyor, iş neredeyse duracak” dedi. İlk aklıma gelen şey yapılandırma bozuldu sanıldı; — ki bu tartışılır — sonra baktım, null reference exception var,. Kodun bir yerinde boş referans patlamış. Tam da Microsoft’un Nisan yamasında düzelttiği hatanın aynısıydı. Yama daha birkaç gün önce çıkmıştı, müşteri de uygulamayı bekletmişti. Sız hiç denediniz mi? Klasik hikâye.
Bakın şimdi, Azure DevOps Server kullanan kurumsal müşterilerin büyük kısmı — özellikle Türkiye’deki bankalar, kamu kurumları, savunma sanayi firmaları — cloud sürümünü değil de self-hosted (kendi sunucularında barındırılan) sürümü seçiyor. Sebep genelde regülasyon, veri lokalizasyonu ya da iç güvenlik politikaları oluyor. Ama self-hosted olunca yama işi neredeyse tamamen sizin üstünüze kalıyor. Microsoft yamayı yayınlıyor, gerisini sız toparlıyorsunuz. Ve açık konuşayım, bu yamaları ertelemek ciddi dert çıkarabiliyor.
Ve işler burada ilginçleşiyor.
Nisan Yamasında Ne Düzeltildi?
Microsoft’un Nisan ayında Azure DevOps Server için yayınladığı bu yama (Patch 3) üç ayrı sorunu çözüyor. Tek tek bakalım, çünkü her birinin sahadaki karşılığı biraz farklı.
Pull Request Tamamlama Hatası (Null Reference Exception)
Bu hata beni en çok ilgilendiren konu öldü, çünkü birebir sahada yaşadığım bir şeye benziyor. Durum şu: bir pull request’i tamamlamaya çalışıyorsunuz, auto-complete açık ve iş öğesi (work item) otomatik kapatılacak; tam o sırada null reference exception fırlıyor ve PR tamamlanmıyor. Geliştirici ekip “merge olmuyor” diyor, release pipeline dürüyor, herkes birbirine bakıyor.
Bu tip hatalar sinsi oluyor çünkü neredeyse her zaman ortaya çıkmıyorlar. Belirli koşullarda — mesela work item’ın bazı alanları boşsa ya da parent-child ilişkisinde bir tutarsızlık varsa — kendini gösteriyor. Logosoft’ta çalıştığım bir telekomünikasyon projesinde 2024 sonlarında buna benzer bir sorun yaşamıştık; workaround olarak auto-complete’i kapatıp manuel tamamlama yapıyorduk. Çirkin mi? Evet. Çalışıyor müydü? Çalışıyordu. Şimdi artık buna gerek yok, yama bunu düzeltiyor.
Sign-Out Sırasında Kötü Niyetli Yönlendirme Riski
İkinci düzeltme güvenlikle ilgili ve açık söyleyeyim, bu tarz açıklar insanı huzursuz ediyor. Olay şu: kullanıcı çıkış yaptığında, doğrulama (validation) eksikliği yüzünden potansiyel olarak kötü niyetli bir URL’ye yönlendirilebiliyormuş. Yanı saldırgan özel hazırlanmış bir link ile kullanıcıyı sign-out sonrası phishing sayfasına atabiliyor. Kullanıcı da “az önce çıktım, tekrar giriş yapmam lazım” diye düşünüp sahte giriş ekranına bilgilerini yazabiliyor.
Open redirect zafiyetleri OWASP Top 10’da doğrudan yer almasa bile sosyal mühendislik saldırılarının sevdiği araçlardan biri oluyor. Bilhassa kurumsal ortamlarda — hani şirket portalında çıkış yapıyorsunuz ve sonra “oturumunuz sonlandı, tekrar giriş yapın” diyen bir sayfa açılıyor ya — kullanıcılar çoğu zaman sorgulamadan bilgilerini giriyor. Tehlikeli işte. Hem de baya tehlikeli.
Bunu biraz açayım.
AZ-500 sınavına hazırlanırken bu tarz redirect attack senaryolarını epey çalışmıştım. Teoride basit görünüyor ama pratikte hasarı büyük olabiliyor; hatta farklı bir üründe değil ama mantık olarak aynı olan bir açık bulduğumuz finans kuruluşu denetimi de aklıma geliyor, düzeltilmesi 5 dakika sürdü ama açık 6 ay boyunca orada kalmıştı ve kimse fark etmemişti.
GitHub Enterprise Server PAT Bağlantı Sorunu
Üçüncü düzeltme işe GitHub Enterprise Server’a Personal Access Token (PAT) ile bağlantı oluşturma sorunuyla ilgiliydi. Hmm, burada biraz düşünmek gerekiyor… Evet şöyle: bazı kurumlar hem Azure DevOps Server hem de GitHub Enterprise Server kullanıyor. İlginç, değil mi? İkisi arasında entegrasyon kurmak istediğinizde PAT ile bağlantı yapıyorsunuz; işte o bağlantı kurulumu bozulmuştu ve yama bunu toparlıyor.
Evet, doğru duydunuz. Bu konuyla ilgili Kubernetes Image Promoter Yeniden Yazıldı: Sessiz Devrim yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili VS Live! Las Vegas 2026: İzlenmesi Gereken 20 Oturum yazımıza da göz atmanızı tavsiye ederim.
Türkiye’de bu senaryoyu kullanan müşteri sayısı aslında sanıldığından fazla. Hele bir de satın alma ya da birleşme sonrası bir taraf GitHub Enterprise kullanırken diğer taraf Azure DevOps kullanıyorsa — ki ben bunu en az 3-4 kez gördüm — entegrasyon resmen kilit hâle geliyor. Geçen yıl bir e-ticaret şirketinde aynı durum vardı: DevOps tarafı Azure DevOps Server’daydı ama satın aldıkları startup’ın tüm kodu GitHub Enterprise’da duruyordu; PAT bağlantısı olmadan iş akışlarını birleştirmek mümkün değildi.
Yamayı Nasıl Uyguluyoruz?
Lafı gevelemeden anlatayım: Microsoft’un yayınladığı yama dosyasını indiriyorsunuz. Azure DevOps Server makinenizde çalıştırıyorsunuz. Ama önce — dur bir saniye — büyük ihtimalle backup alın demem lazım; veritabanı yedeği olsun, uygulama katmanı yedeği olsun, hepsi elinizin altında dursun. Ben paranoyak mıyım? Olabilir. Ama 2019’da bir müşteride yama sonrası veritabanı tutarsızlığı yaşamıştık; yedeğimiz olmasaydı… Neyse, düşünmek istemiyorum. Daha fazla bilgi için Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor yazımıza bakabilirsiniz. Bu konuyla ilgili GitHub CLI ile Agent Skill Yönetimi: Tam Rehber yazımıza da göz atmanızı tavsiye ederim.
Bakın, Yamayı uyguladıktan sonra doğrulama yapmak önemli oluyor. Microsoft bunun için basit bir komut veriyor:
# Yama dosyasını indirdiğiniz dizinde calistirin
# Ornek dosya adı: devops2022.1patch3.exe
devops2022.1patch3.exe CheckInstall
# Ciktilida "The patch is installed" mesajini gormelisiniz
# Eğer "The patch is NOT installed" diyorsa, yukleme basarisiz olmuş demektirBu kadar basit görünüyor. Dikkat edin; <patch-installer>.exe CheckInstall komutundaki dosya adını kendi indirdiğiniz dosyayla değiştirmek gerekiyor.
Copy-paste yaparken bunu atlayanları gördüm; sonra “komut çalışmıyor” diye dönüyorlar.
Türkiye’deki Kurumsal Gerçeklik
Şimdi gelelim Türkiye’ye özgü tabloya.
Biraz özetleyeyim çünkü enterprise ile küçük ekip arasındaki fark gerçekten sert:
| Kriter | Küçük Ekip (5-20 kişi) | Enterprise (100+ kişi) |
|---|---|---|
| Yama uygulama süresi | 30 dakika, direkt production’a | 1-2 hafta (test → staging → prod) |
| Onay süreci | Teknik lider onaylar, biter | CAB toplantısı, change request, risk değerlendirmesi |
| Downtime penceresi | Öğle arası yeterli | Hafta sonu gece 02:00-06:00 |
| Rollback planı | “Snapshot’tan dönelim” | Ayrıntılı rollback prosedürü + rehearsal |
| Test kapsamı | Smoke test | Regression test suite + kullanıcı kabul testi |
Kendi deneyimimden konuşuyorum, Türkiye’deki kurumsal müşterilerde gördüğüm kadarıyla özellikle bankacılık ve kamu sektöründe yama uygulamak bazen 3-4 haftayı buluyor.
Neden mi? Change Advisory Board (CAB) toplantısı ayarlanacak, risk analizi yapılacak, test ortamında deneme yapılacak, KVKK kapsamında veri etki değerlendirmesi güncellenecek… Liste uzayıp gidiyor.
Küçük bir startup için “indir, çalıştır, bitti” olan süreç enterprise tarafında minicik ama yorucu bir projeye dönüşüyor.
Self-hosted Azure DevOps Server kullanıyorsanız güvenlik yamalarını ertelemek lüks değil risk.
En çok da sign-out redirect düzeltmesi gibi güvenlik yamalarında “bekleyelim sonraki yamayla toplarız” demek kapıyı ardına kadar açık bırakmak gibi.
Neden Self-Hosted Hâlâ Tercih Ediliyor?
E tabi insan sormadan edemiyor: 2026’da neden hâlâ self-hosted Azure DevOps Server kullanılıyor?
Azure DevOps Services varken neden sunucu yönetimiyle uğraşılıyor?
Neden yama takibiyle baş ağrıtılıyor?
Neden veritabanı bakımıyla vakit gidiyor? Daha fazla bilgi için azure ile ilgili önceki yazımız yazımıza bakabilirsiniz.
Cevap genelde üç sebebe dayanıyor.
Birincisi veri lokalizasyonu.
Türkiye’deki bazı regülasyonlar — özellikle BDDK düzenlemeleri — verilerin ülkede kalmasını zorunlu kılıyor.
Azure DevOps Services’in Türkiye bölgesi yok (en yakın Batı Avrupa), bu yüzden bazı kurumlara uymuyor.
İkincisi ağ izolasyonu; bazı savunma sanayi firmaları internet bağlantısı olmayan kapalı ağlarda çalışıyor.
Üçüncüsü işe… alışkanlık.
Açık konuşayım,
bazı müşteriler TFS (Team Foundation Server) zamanından beri bu yapıda ve göç etmek istemiyorlar.
“Çalışıyorsa dokunma” kafası yanı.
Tuhaf ama, Ama şunu da ekleyeyim:
Eğer regülasyon zorunluluğunuz yoksa cloud sürümüne geçişi ciddi ciddi düşünmek lazım.
Yama derdi yok,
altyapı bakımı yok,
ölçeklendirme kendi halinde ilerliyor.
Bir arkadaşım geçen yıl 200 kişilik geliştirici ekibini self-hosted’dan cloud’a taşıdı ve operasyonel maliyetlerin 3 ay içinde %35 düştüğünü söyledi;
ilk duyduğumda ben de inanamadım ama rakamları görünce… hani olur ya,
mantıklı geldi doğrusu.
Kritik Yamalar Için Pratik Checklist
Şahsen, Piyasada kullandığım küçük ama işe yarayan bir kontrol listesi var; Logosoft’taki projelerde yıllardır elimden düşmedi diyebilirim:
- Yama notlarını oku: Sadece başlığa bakma; detayına in. Bazen “küçük düzeltme” denen şey kritik güvenlik açığı çıkabiliyor.
- Tes ortamında dene: Production’a direkt atmak cesaret değil çoğu zaman dikkatsizlik oluyor; en azından clone ortamda deneyin.
- Daten tabanı yedeği al: SQL Server veritabanınızın full backup’ını alın; differential yetmeyebilir.
- Aplikasyon katmanını yedekle: IIS konfigürasyonu mu dersin, özel eklentiler mi, SSL sertifikaları mı ; hepsini saklayın.
- Bakım penceresi duyur: Ekiplere “14 :00 -15 :00 arası DevOps Server bakımda” diye bildirım gönderin.
- Yamayı uygula ve
CheckInstallçalıştır : Doğrulamadan geçme. - Smoke test yap : PR oluştur, tamamla, build çalıştır, work item güncelle. Temel akışlar çalışıyorsa tamamdır. — ciddi fark yaratıyor
- Rollback planını hazır tut : Bir şey ters giderse snapshot’a ya da yedekten dönme prosedurunuz olsun.
Çönümür?
Microsoft’un resmî indirme sayfası.
Sıkça Sorulan Sorular
Azure DevOps Server Nisan yamasını uygulamak zorunlu mu?
Teknik olarak zorunlu değil aslında, ama güvenlik açığı düzeltmeleri içerdiği için bence büyük ihtimalle uygulamalısınız. Yanı özellikle sign-out sırasındaki redirect zafiyeti var — bu phishing saldırıları için gayet kullanışlı bir açık. Ertelemeyin.
Yama uygularken Azure DevOps Server’ı durdurmam gerekiyor mu?
Şunu fark ettim: Evet, kısa bir kesinti oluyor. Genelde 10-15 dakika sürüyor, ama veritabanı boyutuna göre bu uzayabiliyor (şaşırtıcı ama gerçek). Tecrübeme göre bir bakım penceresi planlayıp öyle uygulamak çok daha rahat oluyor.
CheckInstall komutu “not installed” diyorsa ne yapmalıyım?
Önce yönetici (administrator) olarak çalıştırdığınıza bakın — açıkçası sorunların büyük kısmı buradan kaynaklanıyor. Hâlâ düzelmiyorsa Event Viewer loglarına bakın, hani genelde bir prerequisite eksikliği ya da dosya izni sorunu çıkıyor. Oradan da çözemediyseniz Microsoft’un resmî troubleshooting rehberini inceleyebilirsiniz.
Bu yama hangi Azure DevOps Server sürümlerine uygulanabiliyor?
Patch 3, yanı bu yama, Azure DevOps Server’ın en son sürümüne uygulanıyor. Eski sürümler için (2020, 2019 mesela) ayrı bir yama çıkmıyor — bu da aslında güncel sürümde kalmanın ne kadar önemli olduğunu bir kez daha gösteriyor.
Azure DevOps Services (bulut) kullananlar bu yamayı uygulamalı mı?
Hayır, gerek yok. Bulut versiyonunu zaten Microsoft kendisi yönetiyor ve yamalar otomatik uygulanıyor. Bu yama sadece self-hosted, yanı kendi sunucunuzda barındırdığınız kurulumlar için geçerli.
Kaynaklar ve İleri Okuma
Yanı, April Patches for Azure DevOps Server — Azure DevOps Blog
Azure DevOps Server İndirme Sayfası — Microsoft Learn
Daha açık söyleyeyim, şunu fark ettim: Azure DevOps Server Release Notes — Microsoft Learn
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.
4 comments