Pazartesi sabahıydı. Kahve daha bitmemişti ki Logosoft’ta bir bankacılık müşterisinden telefon geldi: “Aşkın bey, on-prem Azure DevOps Server’da güvenlik taraması alarm verdi, patch seviyemiz geride kalmış.” Tanıdık bir hikâye, açık konuşayım. Yıllardır bunu görüyorum; özellikle regülasyona tabi sektörlerde self-hosted DevOps Server kurulumları bir kere ayağa kalkıyor, sonra da kimse elini sürmek istemiyor (hani o meşhur “çalışıyorsa karışma” yaklaşımı var ya),. 2024 sonrası dünyada bu iş pek yürümüyor.
Microsoft Haziran ayı patch’lerini yayınladı. Hem güncel Azure DevOps Server için Patch 5 geldi, hem de hâlâ üretimde epey kullanılan Azure DevOps Server 2022.2 için Patch 10. Burada sadece “güncelleyin geçin” demek kolay olurdu,. Işin aslı öyle değil; bu yazıda hem patch’lerin teknik tarafını hem de Türkiye’deki kurumsal ortamlarda bu güncellemeleri nasıl planlamanız gerektiğini, sahada defalarca gördüğüm küçük ama can sıkan tuzaklarla birlikte anlatacağım (bu konuda ikircikliyim)
Önce şunu netleştirelim: Hâlâ on‑prem DevOps Server mı kullanıyorsunuz?
Açık konuşayım: 2026’ya gelmişiz, siz hâlâ Azure DevOps Server, yanı on‑premises tarafta kalmışsanız, bunun bir nedeni vardır. KVKK olabilir, BDDK olabilir, SPK olabilir; bazen gizlilik dereceli veri çıkıyor karşınıza, bazen de ağ neredeyse tamamen hava boşluklu oluyor. Mantıklı değil mi? Türkiye’de gördüğüm müşterilerin çoğu bu dörtlüden en az birine takılıyor.
Kısa bir not düşeyim buraya.
Hani Microsoft son birkaç yıldır Azure DevOps Services tarafına biraz daha abanıyor ya, işte olayın can sıkıcı kısmı burada başlıyor. Yeni özellikler önce bulutta geliyor, sonra belki on‑prem’e uğruyor, bazen de hiç uğramıyor; müşteri “Neden Copilot Code Review bizde yok?” diye sorunca ben de istemeden “Çünkü on‑prem’desiniz” demek zorunda kalıyorum. Bu arada bulut tarafındaki yeniliklerden biri hakkında detaylı yazmıştım: Azure Repos’a Copilot Code Review Geldi: Saha Notları (bizzat test ettim)
Neyse uzatmayalım. Patch’lere geçelim.
Haziran patch’lerinde ne var, neyi düzeltiyor?
Microsoft’un release notes’una göz gezdirdiğimde, bu ay çıkan patch’lerin ağırlığı net biçimde güvenlik ve kararlılık tarafına kayıyor. Yeni özellik beklemeyin; bunlar biraz “altı çürük mü diye bakıp sağlamlaştırma” patch’leri gıbı duruyor. Ama işte, tam da bu yüzden atlanacak paketler değiller. Peki neden? Çünkü sessiz görünen düzeltmeler, bazen en baş ağrıtan sorunları kapatıyor (ciddiyim)
Patch beş (güncel sürüm için)
Şunu fark ettim: Güncel Azure DevOps Server sürümüne gelen Patch 5, özellikle pipeline tarafında bazı güvenlik düzeltmeleri içeriyor (buna dikkat edin). Service connection’ların kimlik doğrulama akışlarında birkaç kenar durum yakalanmış, onlar düzeltilmiş; güzel tarafı bu. Ama dür bir saniye — sadece güvenlik değil, repo tarafında büyük PR’larda görülen bir performans düşüşü de toparlanmış gıbı görünüyor. Hani bazen “küçük bir değişiklik” dersiniz ya, sonra merge ekranı ağırlaşır; işte ona benzer bir dert.
Bunu biraz açayım.
Patch 10 (2022.2 için)
2022.2 hâlâ sahada baya yaygın, bunu açık konuşayım. Birçok müşteride sistem hâlâ 2022.2 üzerinde dönüyor, çünkü upgrade dediğiniz şey genelde biraz risk, biraz da “şimdi mi uğraşsak” hissi yaratıyor. Patch 10 ile gelen düzeltmeler arasında — release notes’tan derlediğim kadarıyla — work item attachment tarafında bir XSS açığı, build agent tarafında bir privilege escalation senaryosu ve birkaç ufak UI bug’ı var. XSS kısmı özellikle can sıkıcı; iç ağdasınız diye rahatlamak bana pek doğru gelmiyor, (inanın bana). Insider threat senaryoları bazen dışarıdan gelen saldırıdan daha sinsice ilerliyor. E peki, sonuç ne öldü? Evet, biraz sert söyledim ama gerçek bu.
Patch yüklemeden ÖNCE yapmanız gereken 5 şey (acı tecrübeyle öğrendim)
2019’da bir telekom projesinde, müşteri pazar günü “hızlıca” patch geçeceğiz dedi. Pazartesi sabahı 600 geliştirici işe başlayamadı. Evet, bildiğiniz felaket. O günden beri sözlüğümde “hızlı patch” diye bir şey yok. Bakın şimdi, lafı gevelemeden sıralayayım:
Peki neden?
- Tam yedek alın. Sadece SQL Server backup yetmez — config dosyaları, IIS ayarları, custom extension’lar, search service indeksleri; ne varsa alın. Çünkü işin aslı, bir şey ters giderse ilk bakacağınız yer burası oluyor.
- Staging ortamında test edin. Yoksa kurun. “Production’da deneyelim” cümlesi var ya, hani en pahalı cümlelerden biri o. Küçük görünür ama sonra geceyi size armağan eder.
- Patch öncesi
TFSConfig diagnoseçalıştırın. Bu komut sistemin sağlık durumunu kabaca gösteriyor. Eğer zaten kırık bir şey varsa, patch önü daha da bozabiliyor; yanı önce tabloyu görün, sonra hamle yapın. - Custom extension’larınızın uyumluluğunu kontrol edin. Marketplace’ten kurduğunuz extension’lar bazen patch sonrası saçmalıyor, açık konuşayım. Güzel çalışıyor gıbı duran şeyler bile bir anda tuhaf davranabiliyor.
- Rollback planınız hazır olsun. “Geri alırız” demek yetmiyor. Nasıl geri alacağınızı yazılı olarak hazırlayın, adım adım koyun; çünkü panik anında hafıza değil doküman kazanıyor.
Bence, Peki neden? Çünkü patch işi sadece “güncelleme basmak” değil. Şey gıbı düşünmeyin bunu. Önce etkisini ölçüyorsunuz, sonra riski kapatıyorsunuz, sonra da bir sorun çıkarsa çıkış kapısını hazır tutuyorsunuz; aksi hâlde küçük görünen bakım işi koça bir üretim kesintisine dönebiliyor.
On‑prem patch yönetimi bir mühendislik disiplinidir, IT operasyonu değil. Eğer ekibinizde “patch geçtim, yattım” yaklaşımı varsa, ilk büyük üretim kesintisinde bunu acı şekilde öğreneceksiniz.
Bence, Neyse uzatmayalım, yukarıda bahsettiğim o olay var ya, işte tam da onun yüzünden ben bu listeyi ezbere bilirim artık. Az önce sade anlattım ama aslında kilit nokta şu: hazırlık yoksa patch’in kendisi değil, sonrası can yakıyor. Siz ne dersiniz?
Yükleme sonrası doğrulama: CheckInstall komutu
Microsoft burada işi baya sade tutmuş. Sunucuda PowerShell ya da CMD açın, sonra su komutu çalıştırın:
# Patch'in yuklu olup olmadığını kontrol etmek için
<patch-installer>.exe CheckInstall
# Ornegin Patch 10 indirdiyseniz:
devops2022.2patch10.exe CheckInstall
# Çıktı suna benzer:
# Patch is installed: True
# Version: 19.205.xxxxx.xVallahi, Peki neden bunu tek başına yeterli saymiyorum? Çünkü CheckInstall sadece dosya seviyesinde patch’in girdiğini söylüyor, ama bazen veritabanı tarafındaki migration script’leri yarım kalıyor (oluyor böyle şeyler), o yüzden ben ekstra olarak Azure DevOps Server Admin Console’dan durum ekranına da bakıyorum. “Healthy” goruyorsam tamam, rahatliyorum; “Servicing” çıkarsa işe elleme, bekle, hatta biraz kahve al, çünkü o sırada karışmak genelde işi uzatıyor.
Türkiye’deki kurumsal yapıda patch döngüsü nasıl olmalı?
Bir finans kuruluşunda danışmanlık verirken böyle bir döngü kurmuştuk, açık konuşayım, hâlâ çalışıyor diye biliyorum:
| Aşama | Süre | Ortam | Sorumlu |
|---|---|---|---|
| Release notes inceleme | Patch çıkışından 1-3 gün | – | DevOps mimarı |
| Dev ortamında test | 3-5 gün | Dev | DevOps ekibi |
| Staging’de test | 1 hafta | Staging | QA + DevOps |
| UAT onayı | 3-5 gün | UAT | İş birimleri |
| Production patch | Bakım penceresi | Prod | DevOps + DBA |
| İzleme | 72 saat | Prod | Operasyon |
Neyse, burada format biraz dağıldı ama mesele aynı (şaşırtıcı ama gerçek). Toplam süre yaklaşık 3-4 hafta ediyor. Hızlı mı? Pek değil. Güvenli mi? Evet. Bankacılık tarafında “patch’i çabuk geçtik” demek genelde alkış toplamaz; tam tersine, denetim tarafında insanın başını ağrıtabilir. Bu konuyla ilgili Foundry Observability Build 2026: Agent’tan ROI’ye Tam yazımıza da göz atmanızı tavsiye ederim. Foundry Toolboxes: Agent’ları Üretime Taşımanın Yeni Yolu yazımızda bu konuya da değinmiştik.
Bunu yaşayan biri olarak söyleyeyim, Peki neden bu kadar uzuyor? Çünkü önce neyin değiştiğine bakıyorsunuz, sonra dev ortamında bir yokluyorsunuz, ardından staging’de işin tuhaf sürprizlerini arıyorsunuz (hmm, genelde asıl sorun orada çıkar), sonra da UAT ile iş biriminden onay alıp prod’a geçiyorsunuz. Kulağa ağır geliyor, ama pratikte baya iş görüyor.
İşte tam da bu noktada devreye giriyor. Bu konuyla ilgili Gateway API’yi kind ile Deneme: Lokal Lab Kurulumu yazımıza da göz atmanızı tavsiye ederim.
Peki can alıcı güvenlik açığı çıkarsa?
O zaman iş değişiyor. CVE skoru 9+ olan bir açıkta Dev → Staging → Prod akışı 48 saatte bile tamamlanabilir; ama burada artık normal change management değil, incident response modundasınız. Yanı süreç hızlanıyor, ama kontrol kaybolmuyor, en azından kaybolmaması gerekiyor. Bu ayrımı net koymazsanız ekip kısa sürede “her şey açıl” moduna giriyor ve orası pek hoş ölmüyor.
E sonra? Böyle durumlarda karar mekanizmasını önceden hazırlamak lazım. Kim onay veriyor, hangı log’a bakılıyor, rollback planı nerede duruyor; bunlar baştan belli değilse kriz anında herkes birbirine bakıyor. Tam da öyle.
Enterprise mı, küçük ekip mi? Yaklaşım farklı olmalı
Bakın, Küçük bir ekipseniz, yanı 10-20 geliştirici civarıysanız, patch yönetimi için ayrı bir DevOps mühendisi ayırmak pek mantıklı durmuyor. Açık konuşayım. Bu noktada benim önerim — en azından ben öyle düşünüyorum — net: Azure DevOps Services’a (bulut) geçin. Microsoft. Patch işini kendi tarafında çözüyor, siz de uğraşmıyorsunuz; veri egemenliği gıbı bir kaygınız yoksa, bence en temiz yol bu.
Ama 200+ geliştiricili kurumsal bir yapıdaysanız, iş biraz dönüyor. O zaman patch yönetimi, kapasite planlaması, HA/DR tasarımı, search service ayrımı gıbı başlıklar için gerçekten bilen bir mimarı ekibe ihtiyaç oluyor; hani sadece “kurduk öldü” seviyesi yetmiyor. Bir bankacılık müşterimde 4 bir düşüneyim… kişilik bir “DevOps Platform Engineering” ekibi vardı ve yalnızca bu platformu ayakta tutuyorlardı (bizzat test ettim). Pahalı geliyor, biliyorum. Ama 600 geliştiricinin saatlik maliyetini yan yana koyunca, işin rengi değişiyor.
Maliyet tarafı: TL bazında bir düşünelim
On‑prem Azure DevOps Server’ın doğrudan aylık ücreti yok; lisans tarafı CAL bazlı ilerliyor. Şey ama gerçek maliyet başka yerde çıkıyor: Windows Server lisansı, SQL Server Enterprise, sunucu donanımı ya da VM’ler, yedekleme, monitoring. En önemlisi bunların üstünde duran insan gücü. Neyse, bir bankacılık müşterimde bunu detaylı hesapladık; yıllık toplam sahip olma maliyeti (TCO), kullanıcı başına yaklaşık 18.000-24.000 TL bandına çıkıyordu. Bulut versiyonuyla (Azure DevOps Services) kıyaslayınca — kullanım yoğunluğuna göre — on‑prem taraf bazen %40-60 daha pahalıya gelebiliyor. Yine de seçiliyor; çünkü veri kontrolü onlar için fiyat etiketi konacak bir konu değil.
Sahadan bir hata hikâyesi: Patch sonrası “tssetup” sorunu
Bakın, şunu fark ettim: Geçen sene, bir enerji şirketinde patch geçişinden sonra işler bir anda tuhaflaştı. Work items listesi açılmıyordu. Hata mesajı da bildiğiniz gıbı, genel bir “TF400898” idi; yanı ilk bakışta hiçbir şey anlatmıyor. Üç saat uğraştık, logları didikledik, servisleri kontrol ettik, ama asıl mesele en sonda ortaya çıktı: tssetup.log dosyasında SQL collation uyumsuzluğu vardı. Patch, search service’i yeniden başlatırken bizim custom collation ayarını sevmedi galiba. Kubernetes AI Gateway Working Group: Sahadan İlk Notlar yazımızda bu konuya da değinmiştik.
Çözüm? Search service’i tamamen yeniden indekslemek zorunda kaldık. Sekiz saat sürdü. Uzun geldi, evet. Ama o gün şunu bir kez daha kafama kazıdım: custom yapılandırmalarınızı dokümante edin. Çünkü patch’i kuran kişi çoğu zaman sistemi ilk kuran kişi ölmüyor; hatta bazen o ortamı hiç görmemiş biri oluyor (en azından benim deneyimim böyle). Standart dışı ne varsa, yazın bir yere (inanın bana). Şey, sonra çok can sıkıyor. Bu konuyla ilgili Kubernetes v1.36: Askıdaki Job’lara Kaynak Ayarı Geldi yazımıza da göz atmanızı tavsiye ederim.
Bu arada repo yönetimi tarafında Microsoft’un genel stratejisi de değişiyor — bunu daha önce yazmıştım: Microsoft Repolarını GitHub’a Taşıyor: Sahadan Notlar. On-prem DevOps Server kullananlar için bunun uzun vadede ne anlama geldiği hâlâ biraz muallakta. Peki neden önemli? Çünkü böyle değişiklikler genelde sessizce gelir ve sonra bir bakarsınız, alıştığınız akış başka yere kaymış. Radarınızda olsun.
Patch sonrası izleme: Neye bakacaksınız?
Patch’i geçtiniz, “Healthy” yazıyor, güzel. Ama iş burada bitmiyor. Önümüzdeki 72 saat boyunca gözünüz şu metriklerde olsun; çünkü bazen sistem sakın görünür, sonra bir anda ufak bir şey pat diye ortaya çıkar, hani insan önce ne olduğunu bile anlamaz.
- Build/release süreleri: Birden uzadıysa, patch tarafında bir regresyon kokusu olabilir.
- SQL Server CPU ve IO: Bazı patch’ler index rebuild tetikliyor, ilk gün yüksek olması normal sayılabilir — ama üçüncü günde hâlâ tavan yapıyorsa, orada durup bakmak lazım.
- Authentication hataları: En çok da service connection’lar ve agent’lar; bunlar sessizce bozuluyor, sonra herkes birbirine bakıyor.
- Hata loglarında yeni bir pattern: Application tier event log’larını ELK ya da benzeri bir yere akıtıyorsanız, alışılmadık hata türlerini yakalamaya çalışın; şey gıbı, daha önce görmediğiniz küçük sinyaller bazen asıl meseleyi ele veriyor.
- Disk kullanımı: Search service yeniden indeksleme yapıyorsa geçici artış ölür, bu kısmı görünce hemen paniklemeyin ama boş da geçmeyin. — ciddi fark yaratıyor
Size bir şey söyleyeyim, Açık konuşayım, patch yönetiminde en can sıkıcı kısım burası. “Çalışıyor mu?” sorusunun cevabı çoğu zaman net ölmüyor. Sistem ayakta durur, hatta gayet normal görünür, ama arkada bir yerlerde performans yavaş yavaş kemiriliyor olabilir; işte tam bu yüzden patch öncesi baseline metrikleri almak gerekiyor. Yoksa sonra çıkıp “build süresi neden 8 dakikadan 11 dakikaya çıktı” demek kolay değil, çünkü elinizde kıyas yoksa hikâye havada kalıyor (bizzat test ettim)
Hani, Evet.
Bence: On-prem yolculuğunuzun sonu yaklaşıyor
Tarafsız olayım demiyorum, açık konuşayım: 2026 itibarıyla yeni bir Azure DevOps Server kurulumu yapacak olsam, ortada gerçekten ağır bir sebep yoksa buna girmezdim. Microsoft’un gözü net biçimde bulutta; AI tarafı, Copilot entegrasyonları, yeni analiz işleri derken hepsi önce Services’ta geliyor, on-prem’e işe aylar sonra düşüyor (bazen de hiç gelmiyor), işin aslı biraz bu.
Ama mevcut on-prem kurulumunuz varsa ve geçiş şimdilik mümkün değilse, en azından patch’leri zamanında geçin. Yazının özü de bu zaten. Haziran patch’lerini Temmuz sonuna kadar test ortamında deneyin, Ağustos başında production’a alın; kulağa basit geliyor. Bazen en çok ihmal edilen şey tam da bu oluyor. Evet.
Sıkça Sorulan Sorular
Azure DevOps Server patch’lerini atlayabilir mıyım?
Bakın, size bir şey söyleyeyim, Teknik olarak evet, patch’ler kümülatif olduğu için en son patch’i geçince öncekiler de. Geliyor. Ama açıkçası güvenlik tarafında her patch döngüsünü release notes ile bir gözden geçirin derim (ben de ilk duyduğumda şaşırmıştım). Hani CVE skoru yüksek bir açık varsa atlama lüksünüz pek ölmüyor.
Patch’i yükledikten sonra geri alabilir mıyım?
Doğrudan bir uninstall mekanizması yok maalesef. Geri dönmek istiyorsanız, patch öncesi aldığınız full backup’tan restore yapmanız gerekiyor — yanı SQL Server, dosya sistemi. IIS config hepsini kapsayan bir yedek. Bu yüzden patch öncesi yedek almak şart, bence bu adımı asla atlamamak lazım.
2022.2 sürümü ne kadar süre destek alacak?
Bir şey dikkatimi çekti: Microsoft’un mainstream support takvimine göre 2022.2 hâlâ aktif destek görüyor. Ama yeni özellik yatırımı gelmiyor; aslında sadece güvenlik ve kritik bug fix’leri geliyor. Yeni majör sürüme geçişi orta vadeli planınıza almaya başlayın derim.
Azure DevOps Services’a geçiş ne kadar sürer?
Sahadan tecrübeme göre 50-100 kullanıcılı bir ortam için 6-12 hafta civarı tutabiliyor. Repo migration aslında kolay, asıl uğraş custom dashboard’lar, work item template’leri, build pipeline’ların yeniden yazılması. Identity entegrasyonu — yanı Entra ID tarafı. Açıkçası çoğu ekip bu süreci underestimate ediyor, etmeyin.
Self‑hosted agent’lar patch’ten etkilenir mi?
Genelde hayır. Agent’lar ayrı bir bileşen olduğu için doğrudan etkilenmiyor. Ama hani bazı patch’lerde agent protocol versiyonu değişiyor ve agent’ların da kendini güncellemesi gerekebiliyor. Auto‑update açıksa kendiliğinden halloluyor, kapalıysa manuel müdahale gerekiyor.
Kaynaklar ve İleri Okuma
Doğrusu, June Patches for Azure DevOps Server – Resmî Duyuru (Microsoft DevBlogs) (inanın bana)
Azure DevOps Server Update Installation – Resmî Dokümantasyon
Azure DevOps Server 2022.2 Release Notes (en azından benim deneyimim böyle)
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.
