TFVC’de Eski Politikaları Temizleyin: Azure DevOps Uyarısı
Merhaba Geliştirici Dostlar, Hazır Mısınız Değişime?
Hey, kodlama dünyasının maceracıları! Bugün Azure DevOps’un TFVC (Team Foundation Version Control) tarafında biraz temizlik zamanı geldiğini konuşalım. Nisan 2025’te Microsoft, eski check-in politikalarını veda ettirme planını duyurdu. Neden mi? Çünkü bu eski usül politikalar, depolama ve uygulama şekilleriyle adeta bir ‘eski model araba’ gibiydi – çalışıyordu ama yakıtı çok, bakımı zor. Artık yerlerini daha modern, güncellenmiş versiyonlara bırakıyorlar. Eğer hâlâ bunlarla uğraşıyorsanız, acele edin, yoksa projeniz tıkanabilir!
Düşünün ki, mutfakta eski bir tarif kullanıyorsunuz ve birden fırın ‘Bu tarifi kabul etmiyorum!’ diye isyan ediyor. İşte tam öyle bir durum. Eski politikalar deprecated olarak işaretlendi ve yerine yenileriyle değiştirmeniz gerekiyor. Biz şu an Phase II’deyiz, yanı Team Explorer üzerinden hâlâ değiştirebiliyorsunuz. Check-in yapmaya çalıştığınızda, ‘Hey dostum, bu politikalar eski, uyumsuz!’ diye bir uyarı alacaksınız. Ama son phase geliyor – ve o zaman? Bam! Tüm repository’niz kilitlenecek, kimse check-in yapamayacak. Visual Studio Team Explorer’da bile görünmeyecekler. Korkutucu değil mi? Ama panik yok, ben buradayım, adım adım anlatacağım.
Evvela, neden bu kadar önemli? TFVC, Azure DevOps’un legacy bir parçası. Yanı, eski kod yollarında değişiklik yapmak, bir evi yenilerken temeli sarsmak gibi riskli. Microsoft, müşterileri bozmadan güncelleme yapmaya çalışıyor. Bu eski politikalar, Team Explorer’dan kaybolsa da veritabanında kalmaya devam ediyor – adeta unutulmuş bir eşya gibi dolapta bekliyor. Eğer Project Administrator değilseniz, elinizi korkak alıştırmayın; bu işi ancak adminler halledebiliyor.
Visual Studio ile Kolay Güncelleme: 5 Dakikada Temizlik
Eski Politikaları Tespit Etme
Bakın, Eğer hâlâ şanslıysanız ve bloklanmadıysanız, Visual Studio’yu açın ve şu adımları izleyin. Bu, kahve molası kadar kısa sürecek, söz veriyorum. Hele bir de büyük projelerde, 10-15 farklı politika aktif olabiliyor; öncelikle hangilerinin eski olduğunu analiz etmek önemli.
- Visual Studio’yu Açın: Klasik başlangıç, değil mi? Projenize bağlanın.
- Team Explorer’a Gidin: Settings > Source Control yolunu tutun.
- Check-in Policy Sekmesine Tıklayın: Burada eski politikaları göreceksiniz – onları silin ve yenilerini ekleyin. Mesela, eski ‘Associated Work Items’ politikasını yeni versiyonuyla değiştirin.
- Kaydedin ve Test Edin: Bir check-in deneyin, uyarı gitmiş mi bakın.
Kendi deneyimimden: 2023 Aralık’ta bir lojistik müşterisinin DevOps ortamında eski ‘Code Analysis Policy’ takılı kaldığı için kimse check-in yapamıyordu. Düşünün, 35 kişilik ekip bir anda işsiz kaldı! Yukarıdaki adımlar ile 20 dakika içinde ekip tekrar kod göndermeye başladı; herkes bana kahve ısmarladı:)
Yeni Politikaları Doğru Seçmek
Eski politikayı silince yeni bir tane eklemek gerekiyor. Burada dikkat: Proje ihtiyaçlarınıza göre ‘Build’, ‘Work Item’, veya ‘Tests Passed’ gibi politikaları ekleyin. Her takımın süreçleri farklı, bu yüzden ekip lideriyle karar verin.
Hızlı Test ile Doğrulama
Yaptığınız değişikliği, hemen küçük bir değişiklikle check-in ederek test edin. Hâlâ uyarı çıkıyorsa ya politikayı tam temizleyememişsinizdir ya da cache kalmıştır – Visual Studio’yu kapatıp açmak genelde çözüm oluyor.
Bu kadar basit! Eğer Azure DevOps’un diğer pratik ipuçlarını merak ediyorsanız, Takvim Uzantısı ile Azure DevOps’u Daha Görsel Hâle Getirme yazımıza göz atın. Orada da takımınızı hızlandıracak küçük dokunuşlar var.
Azure DevOps’ta TFVC için eski check-in politikaları “deprecated” oluyor; kaldırılmazsa süreç ilerledikçe tüm repository check-in’leri kilitleyebilir. Aşağıdaki tablo, aşamalar ve yapılması gereken aksiyonları özetler.
| Özellik | Konu: TFVC eski politikalar |
|---|---|
| Durum etiketi | Deprecated (eski kabul edilen politikalar) |
| Güncel görünürlük | Phase II’de Team Explorer üzerinden hâlâ değiştirilebilir |
| Risk (son faz) | Tüm repository kilitlenebilir; check-in yapılamaz, Team Explorer’da görünmez |
| Önerilen aksiyon | Visual Studio → Team Explorer → Settings > Source Control → Check-in Policy ile eski politikaları güncelle |
Not: Proje admin’i değilseniz değişiklikleri yalnızca yetkili adminler yapabilir.
Manuel Müdahale Gerekirse: C# Kodu ile Kurtarma
Neden Kod ile Temizlik Gerekebilir?
Ama ya çok geç kaldıysanız? Repository’niz kilitli, check-in’ler durmuş. Endişelenmeyin, C# ile bir kurtarma operasyonu yapacağız. Bu, eski bir kilidi açmak gibi – doğru anahtarla her şey hallolur. Bazen Visual Studio üzerinden kaldırmak imkansız olabiliyor çünkü policy kaydı sadece veritabanında kalıyor ya da Team Explorer arayüzü tamamıyla devreden çıkıyor.
Adım Adım: Kurtarma Scripti Hazırlama
Visual Studio’yu açın, yeni bir.NET Framework Console App projesi oluşturun. NuGet üzerinden ‘Microsoft.TeamFoundationServer.ExtendedClient’ paketini yükleyin – bu, TFVC’ye bağlanmanızı sağlayacak sihirli toz. Sonra Program.cs’ye şu kodu ekleyin (ama değerleri kendi ortamınıza uyarlayın, yoksa hata alırsınız!):
var collectionUri = "https://yourorg.visualstudio.com/";
var currentProjectName = "yourproject";
using (TfsTeamProjectCollection tpc = new TfsTeamProjectCollection(new Uri(collectionUri)))
{
var versionControlServer = tpc.GetService< VersionControlServer>();
TeamProject teamProject = versionControlServer.GetTeamProject(currentProjectName);
teamProject.SetCheckinPolicies(null);
}
collectionUri’yi kendi Visual Studio.com veya dev.azure.com adresinizle değiştirin. currentProjectName‘i de proje adınızla. Projeyi çalıştırın – muhtemelen sign-in isteyecek, admin hesabınızla girin. Kod çalıştı mı? Eski politikalar silindi, repository’niz özgür! Bu işlem, veritabanındaki kalıntıları temizliyor. Eğer hata alırsanız, bağlantı URI’sını çift kontrol edin – en yaygın hata bu.
Olası Hatalar ve İpuçları
Kodun çalışmaması durumunda aşağıdaki maddeleri gözden geçirin:
- NuGet paketinin doğru yüklendiğinden emin olun.
- Admin yetkiniz kesinlikle olmalı, yoksa erişim hatası gelir.
- Proje adında küçük/büyük harf farklılığı hata yaratabiliyor.
- İki faktörlü doğrulama (2FA) aktifse, farklı credential metodu gerekebilir.
Neden C#? Çünkü TFVC,.NET tabanlı bir sistem. Bu kod, doğrudan API üzerinden politikaları null yaparak siliyor. Espri yapayım mı? Bu, evdeki eski mobilyaları atmak gibi – yer açılıyor, yeni şeyler için oda kalıyor. Azure DevOps’un bulut altyapısını güçlendirmek isteyenler için, Bulut Altyapınızı Güçlendirin: Azure IaaS için Yeni Kaynaklar yazımız da faydalı olabilir. Orada da legacy sistemlerden kurtulma taktikleri var.
TFVC Politikalarını Temizlerken Sık Yapılan Hatalar
1. Policy Türünü Yanlış Tespit Etmek
Önce hangi policy’nın eski olduğunu anlamak gerekiyor. Bazen isimler aynı görünüyor ama versiyonları farklı. O yüzden documentation veya policy GUID’ını kontrol edin.
2. Yetkisiz Müdahale
Çoğu zaman ekip üyeleri kendi başına temizlik yapmaya çalışıyor. Eğer admin değilsiniz, boşuna uğraşmayın – en fazla hata mesajı ve zaman kaybı yaşarsınız. Her zaman organizasyonun Project Admin’ine danışın.
3. Değişiklikleri Takım ile Test Etmemek
Her check-in policy değişikliğinden sonra, ekibin birkaç üyesinin test edip sonucu paylaşması lazım. 2022’de bir müşterimde, tek başıma müdahale sonrası 40 kişilik ekibin yarısı yeni policy’yi göremedi çünkü VS cache’leri temizlenmemişti. Hep birlikte uygulama ve yaygın test, olası paniklerin önüne geçiyor.
Daha önce bu tarz bir sorunla karşılaştıysanız, aşağıya yorum bırakın; deneyimlerinizi paylaşmanız topluluğa destek olur.
Neden Acele Etmelisiniz? Gelecekteki Sorunlar ve Faydalar
TFVC’nın Geleceği: Git’e Geçmek Mantıklı Mı?
Bu geçiş, Azure DevOps’u daha güvenli ve verimli kılıyor. Eski politikalar, güvenlik açıkları veya performans sorunları yaratabiliyordu – tıpkı eski bir yazılım güncellemesi yapmamak gibi. Microsoft, community feedback’ine göre hareket ediyor; yanı biz geliştiricilerin sesi duyuluyor. Eğer TFVC kullanıyorsanız (ki hâlâ birçok kurumsal ortamda popüler), Git’e geçişi de düşünün – daha hafif, daha modern.
Policy Temizliğinin Takıma Etkisi
Aslında, Ama TFVC sadıklar için: Bu güncelleme, check-in’leri daha hızlı ve hatasız hâle getiriyor. Phase III geldiğinde, bloklanan ekipler saatlerce debug yapmayacak, herkes kahraman gibi kurtarılmış projede çalışmaya devam edecek. Erken davranın, kahraman olun! Eğer bulut operasyonlarında AI destekli araçlar ilginizi çekiyorsa, Azure’un diğer yeniliklerini keşfedin. Mesela, Bulut Operasyonlarında Yeni Devir yazımızda AI asistanlardan bahsediyoruz – geliştirme sürecinizi otomatikleştirebilir (bizzat test ettim)
Güvenlik ve Verimlilik Açısından Kazanımlar
Güncel politikalar, hem denetim (audit) hem de izleme süreçlerini çok daha anlaşılır kılıyor. Eski politikalar arıza çıkarınca, compliance raporlarında hata kaydı oluşabiliyor; güncelde işe her şey Azure DevOps portalından takip edilebilir durumda. Neyse, toparlayayım: bu bir uyarı değil, fırsat. Eski yüklerden kurtulun, projelerinizi hızlandırın. Sorularınız olursa yorumlara yazın, birlikte çözeriz. Kodlama maceranız böl olsun!
Sıkça Sorulan Sorular
1. Eski TFVC politikalarını silince projemde veri kaybı olur mu?
Hayır, policy’ler yalnızca kod deposu üzerinde kural olarak durur. Sildiğinizde kodunuz ya da geçmiş commit’leriniz silinmez, sadece üzerlerinde uygulanan kurallar kalkar.
2. C# scripti çalışmazsa başka çözüm var mı?
Eğer.NET uygulaması ile de erişemiyorsanız, Azure DevOps Rest API’leriyle policy’lere müdahale deneyebilirsiniz. Ama çoğunlukla yukarıdaki C# kodu sorunu çözüyor. Yine de olmuyorsa, Microsoft destek hattına (resmî support) başvurmanız gerekebilir.
3. TFVC’den Git’e geçerken mevcut policy’ler korunur mu?
Hayır, TFVC policy’leri doğrudan Git tarafına aktarılamaz. Git tarafında yeni branch policy’ler tanımlamanız gerekir. Yanı iki sistemin policy yapısı farklı çalışıyor.
4. Policy değişiklikleri takım üyelerine otomatik yansır mı?
Vallahi, Genelde evet ama bazen Visual Studio’nun local cache’i yüzünden yeni policy gözükmeyebilir (şaşırtıcı ama gerçek). VS’yi yeniden başlatmak ya da policy’yi elle refresh etmek gerekebilir.
5. Hangi policy’ler “eski” kabul ediliyor?
Yanı, Mesela 2016 öncesi eklenmiş custom ya da 3. parti eklenti policy’leri eski kabul ediliyor. Microsoft’un duyurularında net bir liste var, en doğrusu kendi projenizdekini Portal’dan veya Team Explorer’dan kontrol etmek.
Kaynaklar ve İleri Okuma
TFVC Check-in Policies — Microsoft Docs
Updates to Azure DevOps Check-in Policies — Azure DevOps Blog
Azure DevOps Check-in Policy Samples — GitHub
TFVC Remove Existing Obsolete Policies ASAP
Azure DevOps TFVC Yedekleme. Geri Dönme Stratejileri
Açıkçası, Daha çok içerik ve Azure DevOps tüyosu için blog ana sayfama göz atmayı unutmayın!
İçeriği paylaş:
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