Microsoft AZ-400: Kaynak Kontrolü ve Depo Yönetimi — Çalışma kılavuzu

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft DevOps Engineer Expert AZ-400 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Modern DevOps uygulamaları, öngörülebilir, iş birliğine dayalı kaynak kontrolü ve disiplinli depo yönetimine dayanır. Azure Repos ve GitHub; sürüm kontrolü, ilke zorlaması, iş birliği ve güvenlik için birbirini tamamlayan yetenekler sunar. Dallanma stratejileri, pull request iş akışları, izinler, kancalar (hooks), büyük dosya yönetimi, geçiş desenleri, güvenlik taraması ve sürüm oluşturma konularında uzmanlık, dayanıklı teslimat işlem hatları (pipeline) ve denetlenebilirlik için esastır. Amaç sadece kodu depolamak değil, aynı zamanda kaliteden ödün vermeden ekip verimini ölçeklendiren, uygulanabilir ve otomatik bir kontrol sistemi oluşturmaktır.

Azure Repos ve GitHub’da Kaynak Kontrolü Temelleri

Azure Repos, Git ve Team Foundation Version Control (TFVC) destekler. Git dağıtık bir yapıdadır; yerel commit’lere, kolay dallanmaya ve merkezi olmayan iş akışlarına olanak tanır. TFVC ise sunucu tarafında sürüm kontrolü yapan, kilitli check-out’lar (isteğe bağlı) sunan merkezi bir sistemdir ve çok büyük ikili (binary) varlıklara sahip eski çözümler veya merkezi iş akışları konusunda eğitimli ekipler için oldukça uygundur. Yeni geliştirmeler için varsayılan olarak Git tercih edilmelidir; TFVC, artımlı değişiklik kontrolü ve merkezi izinlerin çok önemli olduğu ve geçiş maliyetinin engelleyici olduğu durumlarda hala geçerli bir seçenektir.

Bir dallanma stratejisini bilinçli olarak seçin:

Trunk tabanlı geliştirme (Trunk-based development), çok kısa ömürlü özellik dalları (feature branch) ve sürekli entegrasyon ile tek bir uzun ömürlü ana dalı (main branch) tercih eder. Bu, akışı hızlandırır, birleştirme (merge) borcunu azaltır ve güçlü test otomasyonuna sahip yüksek tempolu ekipler için idealdir.
GitFlow, uzun ömürlü develop ve main (release) dallarını kullanır; bunlara ek olarak özellik (feature), sürüm (release) ve acil düzeltme (hotfix) dalları bulunur. Resmi sürüm döngüleri (release train) olan ve geriye dönük düzeltme (backporting) ihtiyacı duyan ürünler için uygundur ancak koordinasyon yükünü artırır.
GitHub Flow, tek bir ana dal (main branch), kısa ömürlü konu dalları (topic branch), sürekli dağıtım ve sık sürümler içeren basitleştirilmiş bir modeldir. Sürekli olarak dağıtım yapan hizmetler için etkilidir.

Monorepo ve multi-repo karşılaştırması, öncelikli olarak organizasyonel ve araçsal bir tercihtir:

Monorepo, birçok bileşeni tek bir depoda birleştirerek servisler arası atomik değişiklikleri, birleşik yeniden yapılandırmayı (refactoring) ve paylaşılan araçları kolaylaştırır. Ancak geçmiş (history) büyüdükçe Git operasyonlarını zorlayabilir. Seyrek checkout (sparse checkout), kısmi klonlama (partial clone) ve derleme (build) ile testlerin kapsamını belirlemek için CI yol filtreleri (path filters) gibi azaltma teknikleri mevcuttur.
Multi-repo, sahipliği, geçmişi ve izin sınırlarını ayırarak bağımsız sürüm oluşturmayı ve saklamayı (retention) kolaylaştırır. Ancak depolar arası koordinasyonu ve bağımlılık kaymasını (dependency drift) artırabilir; alt modüller (submodules) veya bağımlılık yöneticileri ve sürüm orkestrasyonu kritik öneme sahiptir.

Sahiplik ve değişiklik yönlendirmesi, kod sahipliği bildirimlerinden faydalanır. GitHub’ın CODEOWNERS dosyası, yolları (path) zorunlu gözden geçirenlere (reviewer) otomatik olarak eşler. Azure Repos’ta, gözden geçirmeleri bileşen ekiplerine yönlendirmek için dal ilkelerinde (branch policy) yol tabanlı zorunlu gözden geçirenleri (ve etkinleştirilmişse CODEOWNERS’ı) kullanın. Sahipliği, tutarlılık için dal adlandırma kuralları, net commit mesajları (ör. Conventional Commits) ve depo şablonları ile tamamlayın.

Yönetişim: İlkeler, İzinler ve Pull Request’ler

Azure Repos’taki dal ilkeleri (branch policy), kalite kapılarını (quality gate) kod haline getirir:

Zorunlu gözden geçirenler (Required reviewers), asgari bir gözden geçiren sayısını zorunlu kılar ve belirli kişileri/grupları veya yol tabanlı otomatik gözden geçirenleri içerebilir. Anlamlı geri bildirimlerin birleştirmeden önce ele alındığından emin olmak için yorum çözümlemesini (comment resolution) zorunlu kılın.
Derleme doğrulaması (Build validation), birleştirmeden önce bir veya daha fazla CI işlem hattının (pipeline) başarılı olmasını gerektirir. Gereksiz derlemelerden kaçınmak için yol filtreleri (path filter) kullanın ve yeni güncellemelerde otomatik tetiklemeyi ayarlayın. Güvenlik taramaları veya performans testleri gibi harici kontrolleri durum ilkeleri (status policy) aracılığıyla entegre edin.
Birleştirme stratejileri (Merge strategies) kısıtlanabilir: Merge (no fast-forward), birleştirme geçmişini kaydeder; Squash, değişiklikleri tek bir commit’te yoğunlaştırarak geçmişi doğrusal tutar; Rebase and fast-forward, düz bir geçmiş çizgisi için konu dalını (topic branch) main üzerinde yeniden yazar; Rebase and merge, commit’leri yeniden oynatır ve ayrı commit’leri bir birleştirme commit’i olmadan korur. Stratejiyi denetim ihtiyaçları ve alt sistem araçlarıyla uyumlu hale getirin.
Ek kontroller arasında zorunlu bağlantılı iş öğeleri (work item), asgari başarılı oy sayısı ve aktif yorumlar veya bekleyen gözden geçirenler varsa engelleme bulunur.

Pull request’ler, entegrasyon sürecindeki iletişimi yönetir:

Taslak PR’lar (Draft PRs), devam eden bir çalışmayı belirtir ve hazır olarak işaretlenene kadar tamamlanmayı engeller. İlkeleri vaktinden önce tetiklemeden erken geri bildirim alınmasını teşvik edin.
Otomatik tamamlama (Auto-complete), tüm ilkeler karşılandığında birleştirmeyi otomatik olarak yapar, bu da koordinasyon gecikmesini azaltır ve akışı artırır.
İlkeleri atlama (Bypass policies), acil durumlar veya otomasyon hesapları için mevcuttur. Bu yetkiyi “Bypass policies when completing pull requests” izniyle sıkı bir şekilde kontrol edin ve onaylar ile değişiklik yönetimi aracılığıyla denetleyin.
PR şablonları (PR templates) bağlamı standartlaştırır: test kanıtları, risk notları, dağıtım adımları ve geri alma (roll-back) planı. Azure Repos’ta, pull_request_template.md dosyasını deponun kök dizinine veya .azuredevops/ klasörüne yerleştirin. Güvenlik, performans ve dokümantasyon için kontrol listeleri sağlayın.

İzinler ve korumalı dallar (protected branch) son savunma hattınızdır:

Azure DevOps RBAC gruplarını (Project Administrators, Contributors, Readers) ve ayrıntılı depo izinlerini (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies) kullanın. Bireyler yerine gruplar üzerinde izin verme/reddetme (allow/deny) tercih edin.
Main ve release dallarını, Force push ve Delete işlemlerini reddederek, Contribute iznini yalnızca PR birleştirmeleriyle sınırlandırarak ve derleme ile gözden geçirme gerektiren dal ilkelerini etkinleştirerek koruyun. Değişiklikleri geçici olarak dondurmak için “Kilitleme” (Lock) seçeneğini değerlendirin.
Hassas dallara karşı kimlerin PR oluşturabileceğini veya tamamlayabileceğini kısıtlamak ve geliştiriciler ile sürüm yöneticileri (release manager) arasındaki görevleri ayırmak için dal düzeyinde izinler kullanın.

Otomasyon, Hook’lar, Büyük Dosyalar ve Güvenlik

Git hook’ları, kaliteyi uç noktalarda (geliştirici tarafında) güçlendirir:

Pre-commit hook’ları, bir geliştiricinin bir commit kaydetmesinden önce yerel olarak linting (kod stili denetimi), formatlama, gizli anahtar (secret) kontrolleri ve birim testlerini zorunlu kılar. Bunları hızlı ve deterministik tutun.
Pre-push hook’ları, entegrasyon testlerinde veya ilke kontrollerinde başarısız olan kodların push’lanmasını engeller. Ekip genelinde kullanılacak hook betiklerini araçlar aracılığıyla (ör. JavaScript için Husky) sağlayın ve katılımın isteğe bağlı olduğunu belgeleyin.
Yönetilen hizmetlerdeki sunucu taraflı hook’lar farklılık gösterir: GitHub, sunucu webhook’larını ve zorunlu durum kontrollerini destekler; Azure DevOps Services, özel sunucu taraflı hook’lara izin vermez ancak dal politikalarını (branch policies), derleme doğrulamalarını (build validations), hizmet kancalarını (service hooks) ve harici sistemlerden gelen durum kontrollerini destekler. Azure DevOps Server’da (şirket içi) sunucu hook’ları mümkündür.

Büyük Dosya Depolama (Git LFS), büyük ikili dosyaları (binary) Git nesne veritabanının dışında depolayarak deponun (repo) performansını yüksek tutar:

undefined

veya belirli ikili dosya türleri ile desenleri (pattern) izleyin. Tüm katkıda bulunanların LFS’i tutarlı bir şekilde uygulamasını sağlamak için .gitattributes dosyasını commit’leyin.

Büyük ikili dosyaları işaretçilere (pointer) dönüştürerek yeniden yazmak için

undefined

komutunu yol filtreleriyle çalıştırarak geçmişi taşıyın. Ekiple koordine olun ve push işlemlerini duraklatın; force-push’u dikkatli bir şekilde yapın ve klonları güncelleyin.

Gereksiz “smudging” (dosyaların tam olarak indirilmesi) işlemlerinden kaçınarak bant genişliğini yönetin.

undefined

kullanın ve

undefined

komutlarını seçici olarak çalıştırın. CI (Sürekli Entegrasyon) süreçlerinde LFS’i önbelleğe alın ve Git içinde yaşaması gerekmeyen ikili dosyalar için yapıt (artifact) depolarını kullanmayı düşünün.

Güvenlik güvencesi, “shift-left” (sola kaydırma) yaklaşımını benimsemeli ve ilke tabanlı olmalıdır:

GitHub Advanced Security (GHAS), açığa çıkmış kimlik bilgilerini, kod güvenlik açıklarını ve tedarik zinciri risklerini yakalamak için gizli anahtar taraması (secret scanning) (push koruması dahil), CodeQL ile kod taraması (code scanning) ve bağımlılık incelemesi (dependency review) özelliklerini sunar. Bunları PR’larda (Pull Request) zorunlu kontroller olarak uygulayın. Azure Repos için, benzer gizli anahtar taraması, CodeQL aracılığıyla SAST ve bağımlılık öngörüleri elde etmek amacıyla Advanced Security for Azure DevOps’u kullanın.
Gizli anahtar taraması, yüksek kesinlikli (high-confidence) gizli anahtarlar içeren push’ları engelleyecek ve güvenlik ekiplerini uyaracak şekilde yapılandırılmalıdır. Kuruma özgü desenler için özel dedektörleri destekleyin.
CodeQL kod taraması, pull_request ve schedule tetikleyicilerinde çalışmalı ve SARIF sonuçlarını durum kontrolleri olarak yüklemelidir. Gürültüyü (noise) azaltmak için sorgu paketlerini (query packs) ayarlayın ve kritik yollarda kapsamı zorunlu kılın.
Bağımlılık incelemesi, sürüm değişikliklerini ve bilinen güvenlik tavsiyelerini (advisory) PR incelemesi sırasında ortaya çıkarır; bunu düzeltme SLA’ları ve lisans yönetişimi için kullanın.

Migrasyon, Versiyonlama ve Sürüm Yönetimi

TFVC’den Git’e geçiş, risk toleransına uygun bir strateji ve araç seti gerektirir:

Derin geçmiş ve iş öğesi bağlantılarıyla birlikte tüm ayrıntılarıyla bir geçiş için, değişiklik kümelerini koruyarak ve kullanıcıları eşleyerek TFVC yollarını Git’e klonlamak üzere git-tfs kullanın. Git depolarını yönetilebilir tutmak için uygulamaya veya dala göre bölümleme yapın. Geçiş sırasında veya sonrasında büyük ikili dosyaları LFS ile temizleyin.
Mevcut durumun hafif bir geçişi için, isteğe bağlı olarak geçmişi sınırlayarak TFVC’den (veya başka bir Git sunucusundan) yeni bir Git deposu başlatmak üzere Azure DevOps Import aracını kullanın. Bu, süreyi ve riski azaltır ancak derin geçmiş ayrıntılarından feragat eder.
Etiketleri/işaretleri geçirerek, TFVC dallarını Git dallarıyla eşleyerek ve denetim için salt okunur bir TFVC yedeği tutarak izlenebilirliği koruyun. Bir pilot proje ile doğrulayın, geçiş anında kaynak kodunu dondurun ve bir doğrulama matrisi (derlemeler, testler ve dağıtım) çalıştırın.

Anlaşılırlık ve otomasyon için semantik versiyonlamayı benimseyin:

SemVer 2.0.0 kullanın: MAJOR.MINOR.PATCH, isteğe bağlı ön sürüm (ör. -rc.1) ve derleme üst verisi (+build.45) ile birlikte. Sürümleri açıklamalı etiketlerle etiketleyin (git tag -a v1.4.2 -m “Release 1.4.2”) ve denetim için etiketleri imzalayın.
CI/CD’de sürüm artırımlarını otomatikleştirin:
- Commit türlerine ve kapsamlarına göre bir sonraki sürümü hesaplamak için Conventional Commits ve bir sürüm aracı (ör. GitVersion veya semantic-release) kullanarak sürümü commit’lerden türetin.
- Derleme numaralarını ve paket sürümlerini otomatik olarak güncelleyin; sürüm kayması veya etiket çakışmaları olursa derlemeyi başarısız kılın.
Versiyonlamayı dallanma stratejisiyle uyumlu hale getirin:
- Trunk tabanlı: main dalı her zaman yayınlanabilir durumdadır; sürüm etiketlerini main’den oluşturun; kısa ömürlü sürüm dallarını yalnızca stabilizasyon için kullanın.
- GitFlow: release/* dalları dondurulmuş bir minor sürüm taşır; acil yamalar için main’den hotfix/* dalı oluşturulur; hem develop hem de main dallarına geri birleştirilir ve birleştirme tamamlandığında etiketlenir.
- GitHub Flow: Dağıtımda main dalını etiketleyin; kanarya sürümleri için ön sürüm etiketleri kullanın.

Sürüm otomasyonunu depo politikalarıyla entegre edin: sürüm pipeline’ları ile başarılı derlemeler (green builds) zorunlu kılın, commit’lerden oluşturulmuş güncel değişiklik günlükleri olmadan birleştirmeleri engelleyin ve düzenlemeye tabi ortamlarda imzalı commit’ler/etiketler gerektirin.

Pratik Problem Senaryosu

Starbucks, hem servisler hem de mobil uygulamalar için tek tip yönetişim, güvenlik taraması ve ölçeklenebilir iş akışları oluştururken, TFVC’de yönetilen birden çok eski uygulamayı Azure Repos Git altında birleştirmelidir.

Dallanma ve depo topolojisini seçin

Eylem: Paylaşılan kütüphaneler için bir monorepo ve bağımsız olarak yayınlanan servisler için birkaç odaklanmış servis deposu ile trunk tabanlı geliştirmeyi benimseyin. Geliştirici işe alım betiklerinde monorepo için sparse checkout’u etkinleştirin.
Neden: Trunk tabanlı geliştirme, birleştirme borcunu azaltır ve entegrasyonu hızlandırır; monorepo, paylaşılan kodu merkezileştirir ve atomik yeniden düzenlemelere olanak tanır. Sparse checkout ise yalnızca alt kümelere dokunan ekipler için tam geçmiş ve çalışma ağacı ek yükünü önler.

Değer kattığı yerlerde geçmişi koruyarak TFVC projelerini Git’e geçirin

Eylem: Ana web ve mobil kod tabanlarını tam geçmişle geçirmek için git-tfs kullanın, geçiş sırasında büyük varlık yollarını Git LFS’e eşleyin. Küçük yardımcı programlar için, yalnızca mevcut durumu getirmek üzere Azure DevOps Import aracını kullanın.
Neden: git-tfs, amiral gemisi uygulamalar için kritik izlenebilirliği korur; Import aracının seçici kullanımı, düşük riskli geçişleri hızlandırır ve proje süresini kısaltır.

Korumalı dallar ve dal politikaları oluşturun

Eylem: main ve release/* dallarını Force push/Delete işlemlerini reddederek koruyun; iki gözden geçiren, tüm yorumların çözümlenmesi, bir iş öğesinin bağlanması ve yol filtreleriyle derleme doğrulamasından geçme şartı koyun. Servis depoları için birleştirmeleri Squash ile, monorepo’da ise doğrusal bir geçmiş tutmak için Rebase and fast-forward ile sınırlayın. “Politikaları atla” (Bypass policies) seçeneğini küçük bir sürüm mühendisliği grubu dışında devre dışı bırakın.
Neden: Kod olarak politika (Policy-as-code), kalite kapılarını ve denetlenebilirliği güçlendirir. Birleştirme stratejileri ekip tercihlerini yansıtır: Squash, geri alma (revert) ve cherry-pick işlemlerini basitleştirir; monorepo’daki doğrusal geçmiş ise blame ve bisect işlemlerini hızlandırır.

Pull request uygulamalarını standartlaştırın

Eylem: .azuredevops/ altına risk, test kanıtı, performans etkisi ve geri alma (rollback) bölümleri içeren bir pull_request_template.md ekleyin. Erken aşamada Taslak PR’ları (Draft PRs) teşvik edin; tüm PR’larda Otomatik tamamlamayı (Auto-complete) etkinleştirin. Kod sahipliğini taklit etmek için yola dayalı zorunlu gözden geçirenleri yapılandırın ve GitHub’da barındırılan depolar için CODEOWNERS ekleyin.
Neden: Şablonlar, gözden geçirme kalitesinin taban seviyesini yükseltir; Taslak PR’lar erken işbirliğini teşvik eder; Otomatik tamamlama bekleme süresini ortadan kaldırır; sahiplik yönlendirmesi doğru gözden geçirenleri doğru değişikliklere yönlendirir.

Hook’ları ve CI kapılarını uygulayın

Eylem: Linting, gizli bilgi denetimleri ve birim testlerini zorunlu kılmak için pre-commit/pre-push hook’larını depo araçları aracılığıyla dağıtın; yürütme süresini hızlı tutun. Yetkili zorunluluk olarak Azure Pipelines derleme doğrulamasını kullanın ve güvenlik tarayıcılarından durum denetimleri ekleyin. Özel sunucu taraflı hook’lardan kaçının; harici sistemleri bilgilendirmek için servis hook’larını kullanın.
Neden: Yerel hook’lar, işbirliğini engellemeden sorunları erken yakalar; Azure DevOps’ta sunucu taraflı zorunluluk, güvenilirlik ve denetim için en iyi şekilde dal politikaları ve durum denetimleri ile sağlanır.

Büyük varlıkları Git LFS ile yönetin

Eylem: İkili dosya desenlerini (resimler, tasarım varlıkları, test medyası) git lfs track ile izleyin; eski ikili dosyaları git lfs migrate import ile geçirin. Bant genişliğini azaltmak için CI’ı GIT_LFS_SKIP_SMUDGE=1 ayarlayacak ve seçici olarak çekme (fetch) yapacak şekilde yapılandırın; LFS yapıtlarını derleme ajanlarında önbelleğe alın.
Neden: Tekrarlanabilir derlemeleri korurken depoları hızlı tutar ve aşırı ağ kullanımını önler.

Advanced Security’yi entegre edin

Eylem: GitHub depolarında GitHub Advanced Security’yi ve Azure Repos’ta Advanced Security for Azure DevOps’u etkinleştirin. Push koruması ile gizli bilgi taramasını (secret scanning) açın, PR’larda ve gecelik olarak CodeQL çalıştırın ve bağımlılık inceleme denetimlerini (dependency review checks) etkinleştirin. Yüksek önem dereceli bulgularda PR tamamlanmasını engelleyin.
Neden: Güvenliği sola kaydırarak (shift left) kimlik bilgisi sızıntılarının ve istismar edilebilir desenlerin main dalına girmesini önler ve gözden geçirme sırasında uygulanabilir içgörüler sunar.

Semantik versiyonlama ve etiketlemeyi otomatikleştirin

Eylem: Dal ve commit geçmişinden SemVer’i hesaplamak için Azure Pipelines’da GitVersion kullanın; sürüm pipeline’larında açıklamalı etiketleri imzalayın ve push’layın; Conventional Commits’ten sürüm notları oluşturun. release/* dallarını yalnızca stabilizasyon için kullanın; hotfix’leri etiketlenmiş main’den oluşturun.
Neden: Belirleyici, otomatikleştirilmiş sürümler izlenebilirliği ve dağıtım tekrarlanabilirliğini artırır ve imzalı etiketler uyumluluğu destekler.

Bu sıralama, migrasyon riskini düşürür, tutarlı kalite ve güvenliği zorunlu kılar ve teslimatı kolaylaştırır; depo yönetimini ölçeklenebilir DevOps operasyonlarıyla tam olarak uyumlu hale getirir.

Tüm alanlar · Azure Pipelines ile CI →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →