Azure DevOps Git Policy Yönetimi: 10x Hız Kazanmanın Yolu
İlginç olan şu ki, Geçen ay bir finans kuruluşunda tam bu işle uğraştık. 800’den fazla repo vardı, her birinde branch policy’ler, push policy’ler… Hepsini REST API üzerinden yönetiyoruz. Otomasyon scriptimiz her çalıştığında süre neredeyse 45 dakikayı buluyordu. CPU da tepede geziyordu. E tabi bu kadar repo olunca insanın elle yönetmesi zor, otomasyon şart. Ama otomasyonun kendisi darboğaza dönünce ne yapacaksın?
İşte tam burada Microsoft’un Azure DevOps REST API tarafında yaptığı tek bir iyileştirme resmen nefes aldırdı. Rakamları görünce ben de “hmm, cidden mi?” dedim: 2 kat daha az CPU, 10-15 kat daha hızlı çalışma süresi. Tek bir API değişikliğiyle öldü bu. Gelin konuyu biraz eşeleyelim.
Çok konuştum, örnekle göstereyim.
Git Policy Nedir ve Neden Bu Kadar Kritik?
Önce temelden gideyim, çünkü herkes policy engine’i aynı seviyede bilmiyor. Azure Repos’ta iki tip Git policy var: — itiraz edebilirsiniz tabi — push policy’ler ve branch policy’ler. Push policy’ler repo genelinde geçerli oluyor — mesela biri yanlışlıkla (ya da bilerek) bir secret key push etmeye kalkarsa, hangi branch’e giderse gitsin reddediliyor. Branch policy’ler işe belirli branch’leri koruyor. main branch’ine direkt push yapamazsın, pull request açman gerekir, belli sayıda reviewer onay vermeli, build geçmeli vesaire.
Bi saniye — Bakın şimdi, küçük bir ekipseniz — diyelim 5-10 repo’nuz var — bunları Azure DevOps portalından tek tek ayarlarsınız, çok da mesele olmaz. Ama kurumsal ölçekte? Yüz binlerce repo? Microsoft’un kendisi bile Azure Repos ve GitHub üzerinde yüz binlerce repo ile yaşıyor. O noktada elle yönetim diye bir şey kalmıyor zaten.
Bir de şu var: insan hata yapar (ben de ilk duyduğumda şaşırmıştım). Kaçınılmaz yanı. Geçenlerde bir müşteride gördüm — biri yanlışlıkla “Reset votes on new push” ayarını kapatmış bir repoda çalışıyormuş. Yanı sız PR’a onay veriyorsunuz, sonra geliştirici sessizce yeni commit atıyor ve eski onaylar hâlâ geçerli kalıyor. Güvenlik açısından pek iç açıcı değil açıkçası. İşte bu yüzden policy governance işini otomasyona bağlamak gerekiyor.
Bunu biraz açayım.
Ölçekte Policy Yönetiminin Anatomisi
Enterprise tarafta iş şöyle yürüyor: ortada bir “policy governance” servisi oluyor, bu servis hedef durumu tanımlıyor. Mesela “pek çok repo’larda main — ki bu tartışılır — branch için en az iki reviewer zorunlu olacak” gibi bir kural koyuyorsun. Servis belli aralıklarla tüm repo’ları tarıyor, mevcut duruma bakıyor ve sapma varsa düzeltmeye çalışıyor.
İnanın, Kulağa basit geliyor değil mi? Ama asıl mesele burada başlıyor; detaylar işi biraz dağıtıyor. Daha fazla bilgi için
Yeni API İyileştirmesi: Tek Çağrıyla Toplu Sorgulama
Garip gelecek ama, Microsoft’un yaptığı değişiklik aslında şaşırtıcı derecede sade —. Etkisi baya büyük olmuş gibi görünüyor. Artık GET _apis/policy/configurations endpoint’ine repositoryId ve refName` parametrelerini çoklu değerlerle gönderebiliyorsunuz. Bu ne anlama geliyor? Yanı tek API çağrısıyla birkaç repository ve branch için policy çekmek mümkün hâle geliyor.
# Yeni yöntem — Toplu sorgulama (Batch approach)
# Birden fazla repoyu tek çağrıda sorgula
response = requests.get(
f"{org_url}/{project}/_apis/policy/configurations",
params={
"repositoryId": "repo1-guid,repo2-guid,repo3-guid",
"api-version": "7.re1"
}
)
# Tek çağrı, tek sorgu, ciddi hız artışı
}
Ddur bir saniye; şunu da ekleyeyim — bu değişiklik sadece network round-trip sayısını azaltmıyor. Sunucu tarafında da sorgu iyileştirmeu yapılmış durumda. Eskiden her çağrıda ayrı ayrı çalışan veritabanı sorguları artık toplu hâlde birleşiyor,CPU kullanımı yarıya düşüyor,execution time işe 10-15 kat aşağı iniyor.
Tek bir REST API iyileştirmesiyle 2x CPU düşüşü ve 10-15x hız artışı — bu durum, basit optimizasyonların kurumsal ölçekte ne kadar fark yaratabildigini net gösteriyor.
Türkiye’deki Kurumsal Gerçeklik
unter
Sıkça Sorulan Sorular
Git policy otomasyonu için hangi API versiyonunu kullanmalıyım?
Eh, Toplu sorgulama yapabilmek için api-version 7.1 veya üstü şart. Aslında eski versiyonlarda bu parametre hiç desteklenmiyor — yanı her repo için ayrı ayrı çağrı yapmak zorunda kalıyorsunuz, ki bu gerçekten can sıkıcı.
Policy-as-Code küçük ekipler için de gerekli mi?
10 repo’nun altındaysanız elle de idare edebilirsiniz, bence sorun olmaz. Ama 50’yi geçince iş değişiyor. İnsan hatası kaçınılmaz hani, üstelik policy drift’ını elle takip etmek açıkçası çok yorucu bir şey.
Bu iyileştirme on-prem Azure DevOps Server için de geçerli mi?
Şu an sadece Azure DevOps Services, yanı cloud tarafı için mevcut. On-prem’e ne zaman geleceği tam belli değil (belki yanılıyorum ama) — genellikle bir sonraki majör release’de geliyor ama garanti veremem açıkçası (evet, doğru duydunuz). Microsoft’un release notes’larını takip etmenizi öneririm.
Policy governance için hazır araç var mı, yoksa kendi scriptimi mi yazmalıyım?
İnanın, Açık kaynak tarafında birkaç araç var ama çoğu küçük ölçekli kalıyor. Tecrübeme göre enterprise seviyede neredeyse genelde kendi çözümünüzü yazmanız gerekiyor — çünkü her organizasyonun policy ihtiyaçları farklı hani. Peki bunu neden söylüyorum? Python ya da PowerShell ile başlayıp Azure Functions üzerinde çalıştırabilirsiniz, mesela bu gayet makul bir başlangıç noktası.
REST API rate limit’lerine nasıl takılmam?
Önce yeni toplu sorgulama özelliğini kullanın — bu tek başına çağrı sayınızı ciddi ölçüde düşürüyor. Bunun yanında retry logic’e exponential backoff eklemenizi de öneririm. Mümkünse sorgulamaları mesai dışı saatlere almak da akıllıca bir hamle. Birden fazla service principal kullanmak da bir seçenek aslında, ama bence bunu gerçekten son çare olarak saklayın.
Kaynaklar ve İleri Okuma
Optimizing Git Policy Management at Scale — Azure DevOps Blog
Azure DevOps REST API — Policy Configurations List
Branch Policies Overview — Azure Repos Documentation
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.
3 comments