Azure DevOps Server Mayıs Yamaları: Neyi, Neden, Nasıl Kontrol Etmeli?
Azure DevOps Server tarafında yama haberi görünce çoğu ekip aynı şeyi soruyor: “Tamam da bunu ne kadar acil almalıyız?” İşin aslı şu, self-hosted bir kurulum yönetiyorsanız bu soru hiç de teorik kalmıyor. Bir tarafta güvenlik var, öbür tarafta değişiklik riski; ikisi arasında dengede durmak gerekiyor.
Bakın, Ben bu tip güncellemeleri yıllardır izliyorum. 2018’de İstanbul’da bir üretim ortamında, küçük görünen bir Azure DevOps Server düzeltmesini iki hafta geciktirmiştik; sonra build ajanlarında garip yetki hataları başladı ve asıl masraf o gecikmeden çıktı. O yüzden patch konusu bana hep “sonra bakarız” işi gibi gelmiyor. Açık konuşayım, çoğu zaman sonra bakınca daha pahalıya patlıyor.
Mayıs yamaları da tam burada önem kazanıyor. Microsoft burada sadece “yeni sürüm çıktı” demiyor; mesaj baya net: elinizde self-hosted Azure DevOps Server varsa güncel kalın. Güvenli tarafta durun. E tabi kulağa basit geliyor ama kurumsal dünyada işler biraz karışıyor; bakım penceresi, test ortamı, bağımlılıklar, extension’lar, SQL tarafı derken iş uzayıp gidiyor (eh, fena değil)
Çok konuştum, örnekle göstereyim.
Neden bu yamalar ciddiye alınmalı?
Küçük bir detay: Self-hosted ürünlerde mesele sadece yeni özellik almak değil. Asıl konu risk azaltmak. İşte, azure DevOps Server sizin iç ağınızda çalışıyor olabilir ama bu önü otomatik olarak güvende yapmıyor. Kimlik doğrulama akışları, agent sunucuları, servis hesapları ve eklentiler zincirin zayıf halkası olabiliyor.
Geçen yıl Ankara’da bir finans müşterisinde buna benzer bir tablo gördük. Sunucu dışarı kapalıydı ama eski kalan bir bileşen yüzünden update süreci ertelenmişti. Sonra audit geldiğinde ilk sorulan şeylerden biri şu öldü: “Neden en son güvenlik düzeltmesi uygulanmamış?” Yanı teknik borç bazen direkt denetim borcu oluyor.
Durun, bir saniye.
Bence Microsoft’un burada verdiği sinyal net: patch’leri rutin operasyonun parçası yapın. Bir kere alıp unutacağınız türden işler değil bunlar. Hatta ben bunu tıpkı araç bakımına benzetiyorum; yağ değişimi zamanında yapılmazsa motor hemen durmaz belki ama sorun sessiz sessiz büyür.
Küçük ekip ile büyük kurum arasında fark var
Küçük ekipseniz şanslısınız; karar mekanizması kısa olur ve patch’i hızlıca planlayabilirsiniz. Test ortamınız basitse birkaç saat içinde doğrulama yaparsınız, biter gider. Ama enterprise tarafta durum başka… orada change advisory board var, uygulama sahipleri var, QA onayı var, hatta bazen compliance ekibi bile devreye giriyor.
Büyük yapılarda benim önerim şu: patch yönetimini tek seferlik görev gibi değil, takvimli bir süreç gibi ele alın. Aylık ya da iki haftalık kontrol ritmi oluşturun. Yoksa her yeni yama haberi panik yaratır ve ekipler birbirine bakıp kalır.
Hangi sürümler yamalandı?
Bu duyuruda birkaç farklı Azure DevOps Server hattı için güncelleme veriliyor (en azından benim deneyimim böyle). Buradaki mantık basit: kullandığınız sürüm hangisiyse ona uygun patch’i almanız gerekiyor. Yanı “ben. 2022 kullanıyorum” deyip geçmek yok; alt sürümünüz neyse onun yolu ayrı (en azından benim deneyimim böyle)
| Sürüm | Yama | Aksiyon |
|---|---|---|
| Azure DevOps Server | Patch 4 | En güncel paketle ilerleyin |
| Azure DevOps Server 2022.2 | Patch 9 | Sürüm eşleşmesini kontrol edin |
| Azure DevOps Server 2020.1.2 | Patch 19 | Bakım penceresi planlayın |
| Azure DevOps Server 2019.1.2 | Patch 13 | Daha dikkatli test edin |
Masa başında tabloya bakınca kolay görünüyor ama sahada öyle olmuyor işte… Bilhassa eski sürümlerde üçüncü parti extension’lar can sıkabiliyor. Bir bankacılık projesinde İstanbul Maslak tarafında yaşadığım olay hâlâ aklımdadır: Patch sonrası raporlama eklentisi ayağa kalkmadı. Vendor kendi uyumluluk notunu güncellememişti (ben de ilk duyduğumda şaşırmıştım)
Ne yalan söyleyeyim, Burası önemli: Patch’i indirmek tek başına çözüm değil; versiyon uyumu da kontrol edilmeli.
Neyi önce kontrol ederim?
- Sürüm numarasını netleştiririm.
- Tam olarak hangi patch’in size uygun olduğunu eşleştiririm.
- Eklentileri ve özel uzantıları gözden geçiririm.
- Lisanslama ve servis hesaplarını tekrar bakarım. (bu kritik)
Kendi sahadan notlarım: nerede tökezleniyor?
2019’da Bursa’daki bir üretim firmasında Azure DevOps Server yükseltmesi yaparken ilk hata log’u çok sıradan görünüyordu: installer tamamlanmıştı. CheckInstall çıktısı beklediğimiz sonucu vermediği için süreç durmuştu.. Sebep basitti — kurulum dosyasını yanlış klasörden çağırmıştık (evet, bazen sorun gerçekten böyle saçma olur). Komut doğru olsa bile path karmaşası yüzünden ekip yarım gün kaybetmişti.
Peki ben bunu neden anlatıyorum? Çünkü patch işlerinde en büyük tehlike sadece büyük güvenlik açıkları değil; insan hatası da ciddi risk oluşturuyor (evet, doğru duydunuz). O yüzden dokümantasyonu kısa tutup checklist hazırlamak şart oluyor.
Bir de şu var: Az önce “kolay” dedim ama bazı ortamlarda hiç kolay değil. AZ-305 sınavına hazırlanırken bile mimarı kararların nasıl domino etkisi yarattığını tekrar tekrar görmüştüm; patch yönetimi de aynen öyle. Yanı küçük dokunuş gibi görünen şey bazen servis kesintisine dönebiliyor!
“Patch’i yükledikten sonra ‘kuruldu galiba’ demek yetmez; CheckInstall ile doğrulamadan içim rahat etmez.”
Bende bıraktığı ders ne öldü?
Açık konuşayım, en çok zaman kazandıran şey iyi hazırlanmış runbook oluyor. Sonradan kahramanlık yapmaya gerek yok (ki bu çoğu kişinin gözünden kaçıyor). Microsoft’un verdiği komutla kurulumu doğrulamak basit görünebilir ama operasyonel disiplinin omurgası tam da burasıdır. Bir müşteri toplantısında bunu özellikle vurgulamıştım; herkes upgrade konuşuyordu fakat kimse verification adımını yazmamıştı. Bu eksikliği son anda yakaladık ve güzelce toparladık.. Maalesef böyle ufak boşluklar genelde gece nöbetinde patlıyor!
Kural basit: önce test et, sonra yayına al
Şöyle söyleyeyim, Peki pratikte nasıl ilerlemek lazım? Ben olsam şöyle giderdim:
<patch-installer>.exe CheckInstall
`<patch-installer>.exe CheckInstall` komutu çok sade dürüyor. Işlevi kritik.Uygulamada bunun karşılığı şudur: “Ben kurdum sanıyorum” ile “Gerçekten kuruldu” arasındaki farkı kapatır.Ha bu arada çıktı pozitif geliyorsa yine de loglara göz atın.Bazen installer başarılı görünür ama ilgili servisin restart edilmesi gerekir — ufak detaylar büyük baş ağrısı çıkarır.. Ben geçen ay Gebze’de buna benzer bir durumda üç dakikalık ekstra kontrole sevindim çünkü sorun daha büyümeden yakalandı..
Maliyet açısından nasıl düşünmeli?
TL bazında baktığınızda patch işi çoğu zaman ucuzdur; asıl pahalı olan downtime’dır.Bir saatlik kesinti bile onlarca kişinin işini etkileyebilir.Gerçek maliyet burada ortaya çıkıyor.Küçük startup iseniz bunu mesai dışına koyup hızlıca geçebilirsiniz.E enterprise tarafta işe rollback planı olmayan her update kumardır biraz.Valla abartmıyorum!
Kısa bir not düşeyim buraya.
Bir de mümkünse bakım penceresini kullanıcı trafiğinin düşük olduğu saate alın.
Bu kadar basit mi? Değil tabiî… Ama çoğu krizi önlüyor.
Şimdi gelelim benim kişisel görüşüme:
Bu duyuru çok yerinde.
Ama keşke release notes özeti daha anlaşılır verilseydi.
Kurumsal müşteri cephesinde insanlar uzun PDF okumaya pek vakit bulamıyor.
Kritik farkları üç maddeyle özetleyen kısa notlar hayat kurtarırdı.
Bence Microsoft’un yaklaşımı doğru yönde.
Yine de gerçek dünya operasyonlarında daha fazla rehberlik iyi olurdu.
Bir de iç link bırakayım:
Functions" data-glossary-term="Azure Functions">Azure Functions’ta Retry Fırtınasını Durdurmak: Backoff ve Circuit Breaker
Sessiz kalan kısmı da söyleyeyim…
Bazılarının beklediği kadar heyecanlı bir haber olmayabilir.Hatta dürüst olayım—bir yama duyurusunda mucize beklemek fazla iyimser olur.Burada parlak yeni özellik yok ; düzen, stabilite, güvenlik var. Ve açıkçası, prod ortamda beni mutlu eden şey de çoğu zaman budur. Gösterişli şeyler değil, problemsiz çalışan sistemler (buna dikkat edin).
Buna rağmen eksik hissettiğim nokta şu : Patch notlarının operatör gözüyle daha okunabilir olması lazım. Mesela “hangi risk kapanıyor, hangi davranış değişiyor, neyi yeniden başlatmak gerekir ?” sorularının cevabı ilk bakışta belli olsa fena olmazdı (inanın bana). Kurumsal dünyada herkesin zamanı değerli ; detay ararken saat harcamak istemiyoruz. Ha unuttum neredeyse : Bazı ekipler hâlâ yalnızca “indirildi mi ?” diye soruyor. Yanlış soru bu. Doğru soru, “doğrulandı mı ? rollback hazır mı ?” olmalı.
Sıkça Sorulan Sorular
Azure DevOps Server yamalarını hemen yüklemem şart mı?
İnternete açık ya da yoğun kullanılan bir kurulumunuz varsa, açıkçası evet. Geciktirmemek iyi olur. En azından test edip bir bakım penceresine alın. Güvenlik düzeltmeleri hani beklemeye pek gelmez.
Sadece CheckInstall kullanmak yeter mi?
Şunu söyleyeyim, Hayır, tek başına yetmez bence. CheckInstall sadece kurulumu doğruluyor; öncesindeki uyumluluk testi. Sonrasındaki servis kontrolleri aslında hâlâ gerekli.
Eski sürüm kullanıyorsam ne yapmalıyım?
Önce hangi ana sürümde olduğunuzu netleştirin, sonra ona uygun paketi bulun. Eski sürümlerde, yanı mesela birkaç majör geride kalındığında, extension uyumluluğu daha kritik bir hâl alıyor.
Test ortamım yoksa nasıl ilerleyeyim?
Neyse, açık konuşayım, En azından snapshot ya da VM geri dönüş planıyla gidin. Tecrübeme göre test altyapısı olmadan canlıya doğrudan gitmek ciddi risk taşıyor; bunu pek tavsiye etmem açıkçası.
Kaynaklar ve İleri Okuma
Eh, Azure DevOps Server Resmî Dokümantasyonu
Azure DevOps Server Sürüm Notları (buna dikkat edin)
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.
Yorum gönder