Azure DevOps ve GitHub: Yapay Zekâ Çağında Nereye Gidiyor?
Şahsen, Yapay zekâ işin içine girince, yazılım geliştirme akışı da biraz yerinden oynadı. Planlama başka tarafa kaydı, kod yazma hızı arttı, inceleme süreçleri değişti… ve açık konuşayım, artık mesele sadece “hangi araç daha iyi” değil; asıl soru şu: ekipler bu yeni akışı hangi platform üstünde sağlıklı şekilde taşıyacak?
| Senaryo | Daha Mantıklı Yaklaşım | Neden? |
|---|---|---|
| Küçük startup | Tam veya büyük ölçekte GitHub’a geçiş | Daha az süreç yükü, daha hızlı AI deneyimi |
| Büyük enterprise | Hibrit model + kademeli migration | Düşük kesinti riski, governance kontrolü |
| Regülasyonlu sektör | Sıkı policy + audit + kontrollü rollout | Denetim izleri ve güvenlik şartları yüzünden |
Migrasyon Tarafında Neler Değerli?
Enterprise Live Migration gibi yaklaşımlar bana göre önemli. Büyük organizasyonlarda asıl problem teknik değil operasyoneldir (işin garip yanı hep böyle olur). Repo taşımak kolay görünür; zor olan kesinti süresini sıfıra yaklaştırmak ve tarihçe kaybetmeden işi yürütmektir. Branch’lerin korunması,, metadata’nın taşınması ve takımın aynı anda çalışmaya devam edebilmesi baya kritik.
Açık söyleyeyim: İlk defa böyle bir taşıma yaptığınızda ufak sürprizler çıkabiliyor.
Ben 2022 Şubat’ında Logosoft’ta yürüttüğümüz bir projede eski Azure Repos yapısından başka bir ortama geçiş senaryosunda permission eşleşmelerinin beklediğimiz kadar temiz gelmediğini gördüm.
Çözüm mü?
Önce pilot repo taşıdık,
sonra servis hesaplarını yeniden haritaladık…
klasik ama işe yarayan yöntem.
Neyse uzatmayayım,
sonuçta olay yine disiplin çıktı karşımıza.
# Geçiş öncesi kontrol listesi
1) Repo sahiplerini belirle
2) Branch policy'leri çıkar
3) Service connection bağımlılıklarını listele
4) Pipeline secret'larını doğrula
5) Test ortamında pilot taşıma yap
6) Cutover sonrası izleme planla
Eh, E tabi maliyet boyutu da var.
GitHub Enterprise lisansı içinde Azure DevOps basic usage rights bulunması bazı şirketlerde bütçe açısından rahatlatıcı olabiliyor.
Ama dikkat:
Lisans bedeli tek başına hikâyeyi anlatmaz.
Asıl masraf eğitimde,
uyarlamada,
ve bazen de alışkanlık kırmada çıkar.
TL bazından bakınca bugün kur farkıyla birlikte her ek servis kalemi büyüyor;
o yüzden FinOps bakışı olmadan yapılan geçişler sonradan can sıkabiliyor.
Nerede hata yapılır?
Bence en sık hata “önce aracı seçelim sonra süreci düşünürüz” yaklaşımı.
Bu tersine dönmeli.
Önce iş akışınızı çıkarın,
sonra aracın buna uyup uymadığına bakın.
Aksi hâlde parlak demo ile gerçek hayat arasında can sıkıcı mesafe oluşuyor…
Bir başka hata da güvenliği sonradan eklemek.
Ben bunun bedelini 2024 Mart’ta İzmir’deki orta ölçekli bir üretim firmasının pilotunda gördüm:
Copilot kullanımı başladıktan sonra code review disiplini gevşedi,
birkaç gereksiz izin genişlemesi öldü,
neyse ki erken yakalandı.
İşin aslı şu ki AI hız verirken kontrol ihtiyacını azaltmıyor;
aksine artırıyor.
Peki neden?
Çünkü hızlanan insan,
yanlış varsayımı da daha çabuk yayıyor.
Bana Göre Doğru Geçiş Stratejisi Ne?
;
Araya gireyim: Eğer aktif geliştirme yapan sağlam bir ürün ekibiniz varsa reposu GitHub’a almak mantıklı olabilir.
Çünkü AI destekli workflow orada daha bütünlüklü hissediliyor.
Kod yazma,
PR inceleme,
güvenlik sinyali,
agent deneyimi…
hepsi aynı zeminde daha doğal ilerliyor.
Kulağa basit geliyor ama sahada gerçekten fark ediyor.
Ama test süreçleriniz oturmuşsa,
Azure Boards’u yıllardır düzgün kullanıyorsanız,
Pipelines tarafında ciddi yatırımınız varsa acele etmeyin derim.
Az önce X dedim ama aslında Y daha doğru olabilir:
her şeyi taşımanız gerekmiyor.
Bazen source control dışarı gider,
geri kalan orkestrasyon içeride kalır.
Bu kötü değil;
hatta çoğu kurumsal yapı için gayet makul.
Sız ne dersiniz?
Ben burada hibriti biraz daha önde görüyorum açıkçası.
- Küçük ekip:
Hız için GitHub merkezli ilerleyin.
Biraz cesaret ister ama iş görüyor. - Büyük kurum:
Pilot -> kademeli göc -> genişletme yapın.
Yoksa operasyon sizi yoruyor. - Sıkı regülasyon:
Policy ve audit tasarımını baştan kurun.
Sonradan yamamak pek hoş olmuyor;
;
Dikkat etmeniz gereken üç nokta
;
Lafı gevelemeden söyleyeyim:
birincisi erişimler,
ikincisi pipeline bağımlılıkları,
üçüncüsü eğitim.
Ekip yeni araca geçtiğinde eski reflekslerini hemen bırakmıyor;
o yüzden kısa iç eğitimler baya işe yarıyor.
Bir saatlik atölye bile bazen haftalarca sürecek hataları önlüyor…
Tam da öyle.”
AI destekli geliştirmede hız kazanmak kolaydır; zor olan o hızı güvenlikten ve yönetişimden ödün vermeden sürdürülebilmektir.
Sahada Gördüğüm Pratik İpuçları
;
Bak şimdi, Denenmek istiyorsanız ilk iş repo envanteri çıkarın.
Kaç tane repo var?
Hangileri aktif?
Hangileri archive?
Bu sorular basit görünüyor ama migration planının omurgasını oluşturuyor.
Sonra branch policy seviyesini netleştirin:
zorunlu review var mı,
build validation şart mı,
secret scanning nasıl çalışacak?
Bunlar başlamadan belli olmalı…
Pilotu küçük tutun ama temsili seçin.
Sadece boş repo taşımayın;
gerçek branch geçmişi olan,
pipeline bağlantıları bulunan,
biraz da kirlenmiş repo seçin ki sorunlar erken çıksın…
Bunu ben özellikle seviyorum çünkü temiz laboratuvar ortamı yerine gerçek hayata yakın senaryo görmek çok şey öğretiyor.
Bak şimdi,
tam burada insanlar genelde “önce kusursuz düzen kuralım” diyor;
bence gerek yok.”
Eğer bütçe sınırlıysa tüm AI yeteneklerini aynı anda açmak yerine önce kullanım alanlarını daraltın.
Mesela code review tarafında başlayıp sonra planlama otomasyonuna geçebilirsiniz.
Ya da tam tersi;
takımınız ticket triage konusunda boğuluyorsa önce oraya dokunun.
Kullanmadığınız özelliğin değeri sıfırdır — basit matematik bu kadar net!
Evet.
Sıkça Sorulan Sorular
Azure DevOps mu, GitHub mı daha iyi?
Aslında biri diğerinden kesin olarak üstün değil. Hani büyük ölçüde ihtiyacınıza göre değişiyor: AI odaklı geliştirme yapıyorsanız ve geniş entegrasyon istiyorsanız GitHub daha çok öne çıkıyor; mevcut planlama, test ve CI düzeniniz sağlamsa Azure DevOps bence hâlâ çok güçlü bir seçenek.
Tüm repolarımı hemen GitHub’a taşımam gerekiyor mu?
Hayır, gerekmiyor. Açıkçası çoğu kurum için kademeli geçiş çok daha sağlıklı oluyor. Yanı önce bir pilot repo ile başlayıp sonra kapsamı büyütmek, tecrübeme göre genelde çok daha az riskli bir yol.
Aynı anda Azure Boards ve GitHub kullanılabilir mi?
Net bir şekilde evet. Hatta birçok senaryoda bu zaten en mantıklı yaklaşım oluyor. Mesela kod GitHub’da, planlama Azure Boards’ta, teslimat Pipelines’da kalabiliyor. Kurumsal tarafta bu hibrit model bence gerçekten iş görüyor.
Migrasyonda en çok neye dikkat etmeliyim?
Erişim modelleri, pipeline bağımlılıkları, branch policy’leri ve audit gereksinimleri. Açıkçası bunlardan biri eksik kalırsa cutover günü sizi gerçekten can sıkıcı sürprizler bekliyor — buna hazırlıklı olun.
Kaynaklar ve İleri Okuma
Yanı, Orijinal Microsoft DevBlogs yazısı
Azure DevOps Migration genel bakış dokümantasyonu
GitHub Enterprise Control Plane dokümantasyonu
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.
2 comments