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?
Hani, Ben bu dönüşümü son iki yılda birkaç kurumsal projede net gördüm. En çok da 2024 Mayıs’ta bir finans müşterisinde, ekipler Copilot’u aktif kullanmaya başlayınca backlog yönetimi ile kod gözden geçirme arasındaki çizgi baya bulanıklaştı. Eskiden ayrı ayrı yürüyen işler şimdi birbirine bağlandı. Güzel tarafı hız. Zayıf tarafı işe kontrol kaybı riski. İşte tam burada platform seçimi kritikleşiyor.
Aslında dur, önce şunu söyleyeyim: Azure DevOps ile GitHub arasında “ya o ya bu” diye sert bir ayrım yapmak çoğu şirkette yanlış oluyor. Benim gördüğüm yapıların çoğunda hibrit yaklaşım daha gerçekçi. Kod GitHub’da olabilir, planlama Azure Boards’ta kalabilir, teslimat hattı da Pipelines üzerinden akar. Yanı mesele göç etmekten çok, iş akışını doğru bölmek (buna dikkat edin)
Bir dakika — bununla bitmedi.
AI Çağında Asıl Değişen Şey Ne?
Aslında, AI destekli geliştirme deyince herkesin aklına önce kod üretimi geliyor. Oysa işin aslı şu ki, en büyük değişim planlama ve gözden geçirme tarafında yaşanıyor. Bir geliştirici artık yalnızca satır yazmıyor; öneri alıyor, karşılaştırıyor, güvenlik uyarısı görüyor. Bazen agent’lara görev bırakıyor. Bu da doğal olarak platformdan beklentiyi yükseltiyor.
Geçen yıl Eylül ayında Ankara’daki bir SaaS ekibinde buna benzer bir durum yaşadık. Takım küçüktü ama teslim baskısı yüksekti. Copilot’u açınca ilk hafta herkes uçtu gitti; ikinci hafta işe “tamam güzel de bunu kim yönetecek?” sorusu geldi. Çünkü AI tek başına çözüm değil — hatta bazen fazla özgüven veriyor, küçük bir refakatçi gibi davranıp yanlış yöne sürükleyebiliyor.
Şimdi gelelim işin can alıcı noktasına.
Bir de şu var: Agentic development dediğimiz şey sadece otomatik kod üretmek değil. Planlama, görev dağıtımı, güvenlik bir düşüneyim… taraması, PR incelemesi ve test sinyallerini birlikte düşünmek gerekiyor. Bu yüzden platformun olgunluğu önemli hâle geldi. Ben AZ-305’e hazırlanırken mimarı kararların ne kadar zincirleme ilerlediğini çok çalışmıştım; burada da aynı mantık var (yanlış duymadınız). Hani ne farkı var diyorsunuz, değil mi? Tek parça görünen şey aslında birçok bağımlılığın üst üste binmiş hali (bizzat test ettim)
GitHub neden öne çıkıyor?
GitHub’ın öne çıkmasının sebebi sadece popüler olması değil. Copilot deneyimi daha geniş model seçenekleriyle güçleniyor; VS Code’dan CLI’a, Teams ve Slack entegrasyonlarına kadar uzanan bir alan açılıyor. Bu kulağa pazarlama cümlesi gibi — ki bu tartışılır — gelebilir ama pratikte ciddi fark yaratıyor. Peki bunu neden söylüyorum? Çünkü geliştirici neredeyse nerede çalışıyorsa AI da orada oluyor.
Ha bu arada, kurumsal tarafta governance kısmını atlamamak lazım. Agent control plane fikri bence doğru yönde atılmış bir adım ama hâlâ biraz ham hissediliyor. Mesela regülasyon yoğun sektörlerde görünürlük istiyorsunuz: kim ne yaptı, hangi model çağrıldı, hangi policy devreye girdi… Bunlar net değilse ekip rahat ederken güvenlik ekibi huzursuz oluyor (şaşırtıcı ama gerçek)
Kısa bir not düşeyim buraya.
Hibrit Model: Her Şeyi Taşımak Zorunda Değilsiniz
Hani, Bence Microsoft’un bu dönemde verdiği en pragmatik mesaj şu: Her şeyi tek seferde taşımak zorunda değilsiniz. Bazı ekipler reposunu GitHub’a alır, Azure Boards ile devam eder; bazıları işe migration sürecini parça parça yapar. Kurumsal müşteri gerçekliği böyle zaten… Büyük yapıda kimse “bugün karar verdik yarın her şey değişti” diyemiyor.
Ne yalan söyleyeyim, 2023 Kasım’ında İstanbul’daki bir telekom projesinde benzer bir geçiş konuşmuştuk. Repozitoların tamamını taşımak teknik olarak mümkündü ama operasyonel olarak riskliydi çünkü release takvimi yoğundu ve test ekipleri farklı saat dilimlerinde çalışıyordu (evet, bayağı karışık). O projede hibrit kullanım en mantıklı yol öldü: source control kademeli taşındı, build/test zinciri bozulmadan devam etti.
Bir bakıma, ne yalan söyleyeyim, Küçük startup ile enterprise arasında burada ciddi fark var. Küçük ekipte hızlı karar verip reposu direkt GitHub’a almak çoğu zaman iş görür; çünkü yönetilecek süreç azdır. Peki bunu neden söylüyorum? Büyük kurumda işe compliance, erişim modeli, denetim izi ve eğitim konusu devreye girer — yanı kağıt üstünde basit görünen göç pratikte epey katmanlı olur. PowerToys 0.98: Yeni Düzen, Daha Hızlı Akış yazımızda bu konuya da değinmiştik.
| 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. Bu konuyla ilgili Kubernetes Dashboard’dan Headlamp’a: Neden Geçiş Mantıklı? yazımıza da göz atmanızı tavsiye ederim.
# 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… GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı yazımızda bu konuya da değinmiştik.
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ı. Daha fazla bilgi için azure ile ilgili önceki yazımız yazımıza bakabilirsiniz.
- 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.” Daha fazla bilgi için Foundry’de Model, Maliyet ve Kaliteyi Ben Nasıl Yönetiyorum? yazımıza bakabilirsiniz.
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.
İ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