Açık konuşayım: Azure DevOps tarafında REST API ile policy yöneten bir ekibin başındaysanız, bu yazı tam size göre. Birkaç gün önce — kendi adıma konuşayım — müşteride bir otomasyon scriptini debug ederken fark ettim — eskiden 4-5 dakika süren policy senkronizasyon işi, son güncellemelerden sonra 30 saniyenin altına inmiş. Önce “bir şeyleri yanlış mı ölçüyorum” diye düşündüm, sonra Microsoft’un blog yazısındaki detayları okuyunca taşlar yerine oturdu.
Microsoft, Azure DevOps’un Git policy yönetimi tarafında REST API’de tek bir iyileştirme yapmış. Sonuç? %50 daha az CPU kullanımı ve 10-15 kat daha hızlı çalışma süresi. Tek bir endpoint değişikliğinden bahsediyoruz. Şaşırtıcı, değil mi? Hem öğretici hem de biraz insanı dürten bir durum, çünkü işin aslı şu: bu sıkıntı yıllardır oradaydı.
Kendi deneyimimden konuşuyorum, Ben de Logosoft’ta birkaç kurumsal müşteride benzer otomasyonlar yazmıştım. Hatta 2022 sonlarında bir bankacılık projesinde, gece 02:00’de policy drift’i toparlamak için kurduğumuz bir job vardı — sabaha kadar bitmiyordu. Şimdi geriye dönüp bakınca “demek meğer sorun bizim kodda değilmiş” demeden edemiyorum. Neyse, çok dağıtmadan asıl meseleye gelelim.
İşte tam da bu noktada devreye giriyor.
Git Policy Nedir, Niye Bu Kadar Önemli?
Çok kısa özetleyeyim: Git policy, kodun repoya ya da korunan branch’lere girmeden önce uyması gereken kuralları tanımlar. Azure Repos’ta iki ana tıp var:
- Push policies (repository policies): Branch fark etmeksizin repoya ne girip ne giremeyeceğini belirler. Mesela push sırasında secret tespit edilirse direkt reddedilir.
- Branch policies (pull request policies): Belirli bir branch’i (genelde
main) korur. Pull request olmadan, build geçmeden, minimum reviewer sayısı tutmadan kod giremez.
Şunu fark ettim: Kağıt üstünde basit duruyor. Ama 5-10 reposu olan bir startup ile yüzlerce repo barındıran bir kurumun gerçekliği aynı değil; hatta baya farklı. Bir finans müşterimde yaklaşık 380 aktif repo vardı ve her biri compliance gereği ayrı policy setleri istiyordu. Manuel yönetim mi? Zor iş. İnsan eli değdi mi drift çıkması da kaçınılmaz oluyor. Daha fazla bilgi için Axios npm Saldırısı: Azure Pipelines Kullananlar İçin Rehber yazımıza bakabilirsiniz. GitHub App Token Formatı Değişiyor: ghs_ Sonrası Yeni Dönem yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Kubernetes v1.36’da User Namespaces GA: Rootless Devri Geldi yazımıza bakabilirsiniz.
İşte tam bu yüzden büyük şirketler — Microsoft kendisi dahil — REST API üzerinden çalışan otomasyon servisleri yazıyor. Hedef state’i tanımlıyorsun, servis aktüel state’i okuyup farkı kapatıyor. Klasik desired state configuration mantığı.
Eski API’nın Sıkıntısı Neydi?
Şimdi teknik tarafa geçelim. Bir reponun policy’lerini almak için GET /policy/configurations endpoint’ını çağırıyordunuz. Sorun şuydu: bu endpoint, sorduğunuz repo için o repoya hiç dokunmayan policy’leri de dönduruyordu.
Diyelim ki proje seviyesinde tanımlı ve başka repolar için scope edilmiş 200 policy var (bizzat test ettim). Siz tek bir repo için sorgu attığınızda response içinde alakasız 199 tanesi de geliyordu. Sonra bunları client tarafında ayıklamak zorunda kalıyordunuz. Bandwidth gidiyor, CPU gidiyor, zaman gidiyor; hani üçü bir arada kayboluyor gıbı düşünün. Daha fazla bilgi için azd Hooks Artık Python, JS, TS ve.NET Destekliyor yazımıza bakabilirsiniz. Bu konuyla ilgili Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımıza da göz atmanızı tavsiye ederim.
Daha kötüsü ne biliyor müsünüz? Bunu binlerce repo için tekrar ettiğinizde tablo iyice çamura dönüyor. Bir kurumsal müşteride bunun pratik etkisini şöyle gördüm:
Kök Neden: Filtrelemenin Yanlış Tarafta Yapılması
Klasik mimarı hatalardan biri aslında bu (inanın bana). Filtreleme nerede olmalı? Server’da tabii ki. Çünkü veriyi zaten server tutuyor; oradaki bir WHERE clause indeks kullanır ve milisaniyelerde döner. Client’a gereksiz veri yollayıp sonra filtrelemek işe hem network hem CPU hem hafıza israfı demek.
Şunu söyleyeyim, Açık konuşayım, Azure DevOps’un policy engine’i baya yetenekliydi zaten; scope, inheritance. Branch matching gıbı işler fena değil çalışıyordu. Ama API tasarımı uzun süre bu yeteneğin gerisinde kaldı. İyi ki sonunda toparlamışlar.
Yeni Endpoint ve Filtreleme Parametreleri
Aslında, Baktığınızda yapılan şey aslında basit görünüyor: repositoryId ve refName diye iki query parametresi eklenmiş. Artık server’a “bana sadece bu reponun şu branch’ının policy’lerini ver” diyebiliyorsunuz.
# Eski yaklaşım — tüm projeyi getir, sonra filtrele
GET https://dev.azure.com/{org}/{project}/_apis/policy/configurations?api-version=7.1
# Yeni yaklaşım — server tarafında filtrele
GET https://dev.azure.com/{org}/{project}/_apis/policy/configurations
?repositoryId={repoId}
&refName=refs/heads/main
&api-version=7.1
Peki neden önemli? Çünkü artık gereksiz kayıtlar client’a taşınmıyor; iş server tarafında çözülüyor ve sonuç ciddi şekilde hızlanıyor muhtemelen bundan geliyor diyebilirsiniz — evet, tam olarak öyle ama yine de ufak bir not düşeyim: refName parametresi opsiyonelmiş.
Sadece repositoryId verirseniz o reponun tüm branch policy’lerini alırsınız.
Branch bazlı filtre istiyorsanız ikisini birlikte geçmeniz gerekiyor.
Performans Karşılaştırması
| Senaryo | Eski API | Yeni API | Kazanç |
|---|---|---|---|
| 50 repo senkronizasyonu | ~4 dk | ~25 sn | ~10x |
| 250 repo senkronizasyonu | ~22 dk | ~90 sn | ~14x |
| `CPU kullanımı (avg) | %100 baseline`|%100 baseline|%100 baseline|%100 baseline%50 baseline | %50 baseline | |
| Network transfer>Yüksek>Minimum>~20x | >Yüksek>Minimum>~20x | >Minimum>~20x | >~20x |
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.
