Azure DevOps Git Policy Yönetimi: 10x Hız Kazanmanın Yolu

⏱️ 6 dk okuma📅 27 Nisan 2026👁️ görüntülenme

İ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 GitHub Pull Requests Dashboard: Herkes İçin Açılan Yeni Deneyim yazımıza bakabilirsiniz.

Policy’lerin Scope Hiyerarşisi

Azure Repos’ta policy’ler farklı scope’larda tanımlanabiliyor. Bir policy’yi tek bir repo’nun tek bir branch’ine verebilirsin. Ya da proje genelinde tüm repo’lardaki belirli pattern’e uyan branch’lere uygulayabilirsin. Hatta repo seviyesinde tüm branch’lere de atanabiliyor. Inheritance devreye girince işler iyice karışıyor. Daha fazla bilgi için Kubelet API Yetkilendirmesi GA Oldu: Güvenlik Devrimi yazımıza bakabilirsiniz.

Bunu şöyle düşünün: apartmanda oturuyorsunuz diyelim (inanın bana). Apartman yönetimi genel kuralları koyuyor (proje seviyesi policy), ama her daire sahibi kendi dairesi için ekstra kurallar koyabiliyor (repo seviyesi policy), hatta odalar için bile ayrı düzen olabilir (branch seviyesi policy). Şimdi bunu 100000 dairelik bir site gibi düşünün… Evet, biraz kafayı yedirir.

Policy Kapsamı	Etki Alanı	Örnek
Proje geneli	Tüm repo’lar, tüm branch’ler	Secret tarama zorunluluğu
Proje + Branch pattern	Tüm repo’lar, belirli branch’ler	Main ve release/* için minimum reviewer
Repo seviyesi	Tek repo, tüm branch’ler	Büyük dosya kısıtlaması
Repo + Branch	Tek repo, tek branch	Main branch’te build validation

Eskı API’nın Performans Sorunu: N+1 Problemi

Sorunun özü şuradaydı: eskiden policy konfigürasyonlarını çekmek için GET _apis/policy/configurations endpoint’i çağrılıyordu. Bu endpoint proje seviyesindeki TÜM policy’leri dönduruyordu; güzel tarafı buydu zaten. Ama hangi policy hangi repo’ya ait, hangi branch’e ait gibi şeyleri filtrelemek için ya hepsini çekip client-side filtreleme yapıyordunuz ya da repo bazlı tek tek sorgu atıyordunuz.

# Eski yöntem — Her repo için ayrı API çağrısı (N+1 problemi)
for repo in all_repos:
response = requests.get(
f"{org_url}/{project}/_apis/policy/configurations",
params={
"repositoryId": repo.id,
"refName": "refs/heads/main",
"api-version": "7.1"
}
)
# Her çağrı sunucuda ayrı sorgu = yavaş

Bakın, 500 repo’nuz varsa 500 API çağrısı demek bu. 5000 repo’nuz varsa sayı direkt uçuyor zaten. Her çağrıda sunucu tarafında ayrı veritabanı sorgusu çalışıyor, CPU yanıyor, rate limit’e çarpıyorsunuz… Sız hiç denediniz mi? Klasik N+1 problemi işte.

Mesele sadece teori değildi tabiî ki; biz bunu sahada gördük. 2023’te Logosoft’ta bankacılık projesinde aynısını yaşadık.. Müşterinin yaklaşık 1200 reposu vardı ve audit scripti gece çalışırken bazen timeout yiyordu, bazen de rate limit yüzünden yarım kalıyordu.Gece 3’de alert geliyordu: “policy sync failed”. Açık konuşayım, insanın sınırı bozuluyor böyle şeylerde. CodeAct ile AI Agent’ları Hızlandırmak: %50 Daha Az Gecikme yazımızda bu konuya da değinmiştik. Entra External ID Native Auth SSO: Tam Entegre Deneyim yazımızda bu konuya da değinmiştik.

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ı. Kubernetes v1.36 User Namespaces GA: Root Artık Gerçek Root Değil yazımızda bu konuya da değinmiştik.

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

İçeriği paylaş:

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102