Açık konuşayım: Self-hosted Azure DevOps Server kullanan müşterilerimin çoğu, yama işini biraz hafife alıyor. “E bizim ortam kapalı zaten, internete kapalı, ne olacak ki?” diyorlar. Geçen ay tam bu cümleyi kuran bir finans müşterimizde, bağımsız bir denetim sırasında 2019.1.2 sürümünde yamasız kalmış bir kurulum çıktı karşımıza. Denetçi gülümsedi, biz terledik.
Bunu yaşayan biri olarak söyleyeyim, Microsoft, Mayıs ayında Azure DevOps Server için yine bir paket yama yayınladı. Hem mevcut Azure DevOps Server ana sürümü, hem 2022.2, hem 2020.1.2, hem de hâlâ inatla ayakta tutulan 2019.1.2 için ayrı ayrı patch’ler geldi. Bu yazıda hem yamaların ne anlama geldiğini, hem de — daha önemlisi — Türkiye’deki kurumlar için bu döngüyü nasıl yönetmeniz gerektiğini anlatacağım.
Önce Şu “Self-Hosted” Meselesini Bir Konuşalım
Bakın, Azure DevOps Services (yanı bulut tarafı) ile Azure DevOps Server (yanı şirket içine kurulan versiyon) arasındaki fark, Türkiye’de hâlâ ciddi bir tartışma konusu. KVKK, BDDK düzenlemeleri, “verim yurtdışına çıkmasın” hassasiyeti… Bunlar gerçek kaygılar. Bu yüzden bankalar, kamu kurumları, savunma sanayi şirketleri hâlâ Server tarafında.
İnanın, Gel gelelim, self-hosted bir ürünü ayakta tutmak demek, yama yönetimini, yedekleme stratejisini, SQL Server bakımını, sertifika yenileme döngüsünü. Daha bir sürü şeyi kendi sırtınızda taşımak demek. Cloud tarafında Microsoft sizin yerinize hallediyor bunları. Server’da her şey size kalıyor. İşte yük burada başlıyor.
İşte tam burada Mayıs yamaları gıbı güncellemeler devreye giriyor. Atlamak lüks değil — risk.
Mayıs Ayında Hangı Sürümlere Ne Geldi?
Microsoft bu sefer dört ayrı sürüm için yama bıraktı. Bunlardan en eskisi 2019.1.2 —. 6 yıl öncesinden kalan bir sürüm hâlâ destekleniyor (en azından benim deneyimim böyle) — itiraf edeyim, beklentimin üstündeydi —. Bu aslında iyi haber gıbı duruyor, ama bir taraftan da “bu kadar eski sürümde takılıp kalmayın” mesajı veriyor satır aralarında.
Aşağıya yama matrisini bir tablo hâlinde koydum,. Hangı sürümde olduğunuzu bilmeden hangı patch’i indireceğinize karar veremezsiniz:
| Sürüm | Patch Numarası | Durum | Önerim |
|---|---|---|---|
| Azure DevOps Server (güncel) | Patch 4 | Aktif | Hemen uygulayın |
| Azure DevOps Server 2022.2 | Patch 9 | Aktif | Test → Prod planı yapın |
| Azure DevOps Server 2020.1.2 | Patch 19 | Olgun ama eskimiş | Yamayı uygulayın ama upgrade planlayın |
| Azure DevOps Server 2019.1.2 | Patch 13 | Çok eski | Açıl migration roadmap çıkarın |
Yanı, Burada dikkat çekmek istediğim bir şey var: 2020.1.2 için 19. yama yayınlanıyor. On dokuzuncu! Bu da ürünün hâlâ aktif şekilde sömürülebilir açıklar barındırdığını gösteriyor gıbı geliyor bana. Yanı “ben kurdum, çalışıyor, dokunmuyorum” stratejisi burada pek işlemiyor.
Hangı Sürümdeyim, Nasıl Anlarım?
Azure DevOps Server’ın admin konsolundan kolayca görebilirsiniz,. PowerShell’i seven biriyseniz şu komut işinizi görür:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\TeamFoundationServer\*" `
| Select-Object InstalledEdition, InstalledVersion, InstallPathBen genelde müşteri ziyaretlerinde ilk iş bu komutu çalıştırırım. Bazen öyle şeyler çıkıyor ki — bir kamu projesinde TFS 2018 ile karşılaştım geçenlerde, hâlâ üretimde, hâlâ kod check-in alıyor. Şok öldüm açıkçası; hani insan duysa inanmaz.
Yamayı Doğrulamak: O Küçük “CheckInstall” Komutu
Microsoft’un dokümantasyonunda kısaca geçtiği için çoğu sysadmin gözden kaçırıyor. Aslında bu basit komut baya iş görüyor:
<patch-installer>.exe CheckInstallHani, Patch dosyasını indirip kurduktan sonra aynı.exe’yi bu parametreyle çalıştırırsanız size yamanın gerçekten yüklenip yüklenmediğini söylüyor. Neden önemli? Çünkü patch installer’lar bazen sessizce başarısız olabiliyor — özellikle SQL connection sorunları, AlwaysOn cluster ortamları veya yeterli disk olmayan durumlarda. Kurulum tamamlandı gıbı görünüyor ama aslında değil.
Evet.
Size bir şey söyleyeyim, Geçen yıl bir telekom müşterisinde tam bunu yaşadık. Patch yüklendi sanıldı, üç hafta sonra denetimde “hâlâ açık var” raporu geldi. CheckInstall’u çalıştırdığımızda durumun gerçek olduğunu gördük; yanı işin aslı buydu zaten. Siz ne dersiniz? O günden beri her patch sonrası bu komutu çalıştırmadan dosyayı kapatmıyorum (inanın bana)
Türkiye’deki Kurumlar İçin Pratik Yama Stratejisi
Peki neden? Çünkü Microsoft “patch’i indir, kur, bitti” diyor ama Türkiye’deki gerçek biraz farklı akıyor (şaşırtıcı ama gerçek)
Birkaç senaryoyu tek tek konuşalım; yoksa konu havada kalıyor ve herkes kendi kafasına göre yorum yapıyor.
Küçük Ekipler İçin (5-30 Geliştirici)
Eğer küçük bir ekipseniz ve hâlâ on-prem Azure DevOps Server kullanıyorsanız, samimi tavsiyem şu: Bu yama döngüsüne enerji harcamak yerine bulut tarafına geçmeyi ciddi ciddi değerlendirin. Server lisans + SQL Server lisans + bakım iş gücü hesabını yaptığınızda Azure DevOps Services’in kullanıcı başı fiyatlandırması (ki ilk beş kullanıcı bedava) çoğu zaman daha rahat geliyor.
Tabi veri egemenliği kaygınız varsa o başka mesele; bunu küçümsemiyorum bile açıkçası zira bazı kurumlarda konu gerçekten oraya dayanıyor. Ama dürüst olalım — 20 kişilik bir ekibin kodu için bu yatırım neredeyse her zaman gerekli mi? Bence çoğu zaman değil.
Orta Ölçek Kurumlar (50-300 Geliştirici)
Burası biraz daha karışık hâle geliyor. Peki bunu neden söylüyorum? Yamayı uygulamadan önce muhtemelen bir test ortamınızın olması lazım; üretim ortamında doğrudan patch geçen müşterilerim öldü ve birlikte kâbus yaşadık diyebilirim çünkü geri dönüş penceresi daralınca herkes aynı anda panikliyor.
Cuma akşamı test ortamına yamayı uygula mı dersiniz? Hafta sonu boyunca smoke test’leri koşturmak mı dersiniz? Pazartesi sabahı ekipler giriş yaptıktan sonra performans izlemek mi dersiniz? Hepsi mantıklı geliyor bana; Salı/Çarşamba üretime planlayıp en sonda da CheckInstall + manuel doğrulama yapmak bence fena değil.
Neyse uzatmayayım; burada Service Bus + Azure Functions: Backoff ve Circuit Breaker yazımda bahsettiğim “patlamaya hazır ol” prensibini Azure DevOps Server bakımına da uyarlayabilirsiniz — geri dönüş planı olmadan patch geçmeyin. Bu konuyla ilgili azure ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Büyük Enterprise (300+ Geliştirici, Yüksek Erişilebilirlik)
Büyük tarafta iş biraz daha teknikleşiyor; SQL AlwaysOn var mı yok mu derken application tier load balancer’ları ve search service ayrımı da devreye giriyor (bir de üstüne ekiplerin pipeline alışkanlıkları eklenince tablo iyice renkleniyor). Burada artık standart yama prosedürü yetmiyor gıbı düşünüyorum; şu kontrolleri eklemeniz lazım:
- SQL replica’ların durumu (patch öncesi mutlaka senkron olmalı)
- Search service Elasticsearch index durumu
- Build agent havuzlarının drain edilmesi (bence en önemlisi)
- Aktif pipeline’ların completion beklenmesi
- İzleme (monitoring) baseline’ının alınması — önce/sonra karşılaştırması için (bu kritik)
Evet.
Bir bankacılık projesinde bu drill’i her ay tekrar ediyoruz; ilk başta 6 saat sürüyordu ama şimdi 90 dakikaya indi. Açıkçası bu fark baya rahatlatıcı öldü.
Pratik yapın derim.
Kasları geliştirir.
Sistem de sızı daha az üzer.
Eski Sürümlerde Kalmanın Gizli Maliyeti
“Aşkın, biz patch’leri uyguluyoruz, sorun yok, niye upgrade edelim?” diye soran bir müşteriyi geçen ay dinledim mesela; ilk bakışta haklı gıbı duruyor. Biraz kazıyınca öyle olmadığı çıkıyor ortaya.
Evet.
Eski sürümde kalmanın görünmeyen maliyetleri şunlar:
Bircisi:. Yeni.NET runtime’ları idare etmiyor artık eski Agent yapılarıyla uğraşmayı; Node sürümleri de benzer şekilde sıkıntı çıkarabiliyor ve modern build tool’ları eski Server sürümlerinin agent’larında bazen hiç açılmıyor bile.
Ekibiniz “biz neden hâlâ Node 14 kullanıyoruz” diye sormaya başladığında siz cevap ararken buluyorsunuz kendinizi.
Yanı mesele sadece teknik değil.
Biraz da huzur meselesi. Kubernetes v1.36 Mixed Version Proxy: Beta’ya Yükseldi yazımızda bu konuya da değinmiştik.
Bir şey dikkatimi çekti: İkincisi:. GitHub entegrasyonu, modern OAuth flow’ları. Azure AD koşullu erişim gıbı şeyler eski sürümlerde ya hiç çalışmıyor ya da yarım yamalak çalışıyor.
GitHub Enterprise Installation API: Public Preview Notları yazımda bahsettiğim API’ler de bunlardan biri — eski Server modern dünyaya bağlanırken nefes nefese kalıyor diyeyim.
Biraz sert öldü belki ama doğruya yakın.
Bak şimdi burası önemli: bağlantı var gıbı görünse de davranış başka oluyor.
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için VSLive! AI Hackathon 2026: Çalışan Kodla Eve Dönmek yazımıza bakabilirsiniz. Daha fazla bilgi için Kubernetes v1.36 Workload API: PodGroup Devri Başladı yazımıza bakabilirsiniz.
İçincisi:. Microsoft destek alırken her ticket’ta çoğu zaman “önce upgrade edin” cevabını duyuyorsunuz.
Bunu yaşamadan anlamak zor;
insan ancak kuyruğa girince fark ediyor bazı şeyleri.
Sonra dönüp aynı cümleyi kendiniz kuruyorsunuz.
Bu kadar net yanı. Daha fazla bilgi için Kubernetes v1.36 CCM: Route Sync Metriği Sahaya İndi yazımıza bakabilirsiniz.
“Yamasız bir Azure DevOps Server, kilitsiz bir banka kasası gibidir — içeride ne olduğu önemli değil, sadece kim önce bulacak meselesi.” — bu cümleyi 2023’te bir red team raporunda okumuştum, hâlâ aklımda.
Migration Planlıyorsanız: Birkaç Pratik Tavsiye
Eğer eski sürümden modern Azure DevOps Server’a veya doğrudan Services tarafına geçmeyi düşünüyorsanız, deneyimden birkaç şey paylaşayım. Kağıt üstündeki planla gerçek hayat çoğu zaman aynı gitmiyor.
İlk iş envanter çıkarın.
Kaç collection var?
Her birinde kaç proje var?
Hangı extension’lar yüklü?
Hangı build agent’lar custom ayarlu?
Bu liste olmadan migration planı yapmak boşa kürek çekmek demek ölür.
Daha sonra Microsoft’un Data Migration Tool’unu (DMT) test edin.
Bulut tarafına gidiyorsanız bu zorunlu sayılır.
DMT’nın verdiği validation raporu bazen insanı epey şaşırtıyor — yıllardır farkında olmadığınız “long path” sorunları, encoding problemleri. Eski Git LFS pointer’ları… Geçen yıl bir sigorta müşterimizde sadece bu validation hatalarını temizlemek için 3 hafta uğraştık.
Azure Red Hat OpenShift: AI Üretimine Geçişin Hikâyesi yazımda da değindiğim gıbı,
“lift and shift” yaklaşımı bu tür ürünlerde pek yürümüyor.
Önceden temizlik şart oluyor;
aksi hâlde yeni ortama sadece eski dertleri taşıyorsunuz.
Maliyet Tarafı: TL Bazında Düşünmek
İşin para kısmına gelince tablo biraz netleşiyor ama yine de herkes kendi Excel’ine göre farklı sonuç çıkarabiliyor.
Azure DevOps Server lisansı CAL bazlı — yanı her kullanıcı için ayrı lisans gerekiyor.
Üstüne SQL Server Standard veya Enterprise lisansı,
Windows Server lisansı,
donanım ya da VM maliyeti…
Dolar bazında düşününce,
100 kullanıcılı bir kurum için yıllık yaklaşık $30-50 bin civarı TCO çıkabiliyor.
Bunu güncel kurla çarpınca rakam ister istemez büyüyor.
Ciddi para yanı.
Peki karşı tarafta ne var?
Azure DevOps Services:
Basic plan kullanıcı başı $6/ay,
ilk 5 ücretsiz.
100 kullanıcı için yıllık $6,840 ediyor.
Aradaki fark gayet net görünüyor;
hesap basit yanı. Etkisi basit değil. Tabi bu hesap (belki yanılıyorum ama) düz hâliyle bakınca böyle. Compliance gereksinimleri, ağ izolasyonu ihtiyaçları, mevcut yatırımlar… hepsi denkleme giriyor. Ama yamaları uygulamak için her ay harcanan iş gücünü de unutmayın; bazı kurumlarda asıl masraf orada patlıyor.
Sıkça Sorulan Sorular
Azure DevOps Server yamalarını atlarsak ne ölür?
Kısa cevap: Güvenlik açıklarına davetiye çıkarıyorsunuz. Uzun cevap: Microsoft’un yayınladığı her patch, aslında CVE numarası alan en az bir güvenlik açığını kapatıyor (ben de ilk duyduğumda şaşırmıştım). Yanı atladığınız her yama, saldırganlar için açık bir kapı bırakıyor. Üstelik denetim süreçlerinde (ISO 27001, PCI-DSS, KVKK gıbı) “patch management” başlığından ciddi bulgular çıkıyor — bence bu kısım çoğu ekibin gözden kaçırdığı en kritik nokta.
Patch uygulamadan önce mutlaka backup almak gerekir mi?
Evet, kesinlikle. SQL Server tarafında configuration ve collection veritabanlarının tam yedeği şart. Ben aynı zamanda application tier’da IIS konfigürasyonunu da yedekliyorum, hani appcmd ile export yapıyorum. Patch %99 sorunsuz geçiyor ama o %1 için bu yedekler hayat kurtarıyor — tecrübeme göre o %1’i yaşadığınızda çok mutlu oluyorsunuz.
2019.1.2 sürümünü kullanmaya devam edebilir mıyım?
Teknik olarak evet, hâlâ patch alıyor. Ama pratik olarak açıkçası hayır — modern entegrasyonların büyük kısmını kaybediyorsunuz ve Microsoft desteği giderek azalıyor. Siz hiç denediniz mi? Bence en geç önümüzdeki 12 ay içinde bir upgrade roadmap’i hazırlamanız şart.
CheckInstall komutu hata verirse ne yapmalıyım?
Önce patch installer log dosyalarına bakın, genelde %TEMP% altında oluşuyor. En sık karşılaşılan sebep yetersiz yetki — patch’i mutlaka local admin yetkisiyle,. “Run as Administrator” ile çalıştırın. Eğer log’da SQL bağlantı hatası görüyorsanız, AlwaysOn cluster’da primary replica üzerinde çalıştırdığınızdan emin olun. Bu iki şeyi kontrol etmek genellikle sorunu çözüyor.
Bulut tarafına geçmeden Server’da kalmamın geçerli sebepleri neler?
Açık konuşayım, Mesela yasal zorunluluk varsa (BDDK, savunma sanayi gıbı), tamamen air-gapped ağ gereksiniminiz varsa, mevcut on-prem yatırımlarınızın amortismanı henüz tamamlanmamışsa veya çok fazla özelleştirme (custom extension’lar) yaptıysanız Server’da kalmak makul. Ama “alışkanlık” geçerli bir sebep değil — bence bu konuda kendinize karşı dürüst olmak gerekiyor.
Hmm, bunu nasıl anlatsamdı…
Kaynaklar ve İleri Okuma
Azure DevOps Blog: May Patches for Azure DevOps Server (Resmî Duyuru) (yanlış duymadınız)
Dürüst olmak gerekirse, Microsoft Learn: Azure DevOps Server Update ve Patch Yönetimi
Ne yalan söyleyeyim, Azure DevOps Migration Overview: Server’dan Services’e Geçiş Rehberi
Aslında, Azure DevOps Server Download Sayfası (kendi tecrübem)
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.
