GitHub Copilot Modernize 101: Kodun Yorgunluğunu Kırmanın Yeni Yolu
Modernizasyon artık “bir gün yaparız” işi değil
Bakın şimdi, modernizasyon deyince çoğu ekipte hâlâ aynı refleks çıkıyor: büyük proje, uzun takvim, böl risk. En sonda da kimsenin tam hatırlamadığı bir cutover gecesi. Ben bu filmi yıllardır izliyorum. 2016’da İstanbul’da bir finans müşterisinde eski Java uygulamasını “bir kerede temizleyelim” diye yola çıkmıştık; kağıt üstünde plan fena durmuyordu. Bağımlılıklar öyle dağınıktı ki asıl kazanç, sistemi parça parça ele almaya başlayınca geldi.
İşin aslı şu: bugün modernizasyon sadece buluta taşımak değil. Uygulamayı AI ile çalışabilir hâle getirmek, sürüm hızını artırmak ve bakım yükünü azaltmak da işin içine girdi. Yanı mesele artık “taşıyıp kurtulalım” değil; “yaşatılabilir hâle getirelim”. Küçük gibi dürüyor ama pratikte bayağı fark ediyor.
Kısa bir not düşeyim buraya.
Şunu fark ettim: Ben AZ-305 ve AZ-104 hazırlıkları sırasında da bunu net gördüm. Mimarı kararlar tek seferlik alınmıyor, sürekli gözden geçiriliyor. Modernizasyon da aynı kafaya geçti. Bir defalık proje olmaktan çıktı; döngü öldü. Açık konuşayım, bu iyi haber. Çünkü eski usül topyekûn dönüşüm projeleri çoğu zaman ekipleri yoruyor, bütçeyi şişiriyor, sonra da yarım kalıyor.
Ha bu arada, Türkiye’deki şirketlerde konu biraz farklı ilerliyor. Mesela orta ölçekli kurumsal yapılarda “önce çalışsın” yaklaşımı baskın oluyor. Haklılar aslında; üretim kesintisi kimsenin sevdiği şey değil. Ama sırf o yüzden yıllanmış Java 5 / Struts 1.x sistemini olduğu gibi tutmak da çözüm değil… bir yerden başlamak gerekiyor.
Copilot Modernize yaklaşımı neden dikkat çekiyor?
Araya gireyim: GitHub Copilot Modernize 101 serisinin bana göre kıymeti burada başlıyor: insanları teoride boğmadan doğrudan işe sokuyor. Bir kod tabanına bakıp “bu ne ya?” dediğiniz anı bilirsiniz (ki bu çoğu kişinin gözünden kaçıyor). Evet, ben de dedim. Hem de birkaç kez. 2023’te Ankara’da bir lojistik firmasında eski Spring tabanlı servisleri incelerken ilk gün elimizde sadece loglar. Yarım yamalak wiki sayfaları vardı; modernizasyon için önce neyin ne olduğunu anlamamız gerekiyordu (buna dikkat edin)
Bu tip serilerde güzel olan şey şu: analiz et, yükselt, taşı, doğrula ve tekrar et mantığını gösteriyorlar. Kağıt üstünde süper dürüyor; pratikte işe en çok mekanik işleri azaltması önemli oluyor. Çünkü dürüst olayım, asıl yorucu kısım fikir üretmek değil; build kırıldı mı neden kırıldığını bulmak, deployment dosyasını düzeltmek, dependency çakışmasını ayıklamak… işte bunlar can sıkıyor.
Modernizasyonu tek seferlik büyük patlama olarak görmek yerine küçük ama sürekli iyileştirmelerle yürütmek çoğu kurum için daha sağlıklı çalışıyor.
Ne yalan söyleyeyim, Gel gelelim burada bir hayal kırıklığı payı da var: Copilot gibi araçlar işleri hızlandırıyor ama sihirli değnek değiller. Eski framework sürümleriyle uğraşırken bazen önerdiği dönüşümler tam oturmuyor ya da güvenlik tarafında insan kontrolü şart oluyor. Hele bir de enterprise ortamda otomasyon güzel ama denetimsiz otomasyon pek hoş sonuç vermiyor. GPT-5.2 ve GPT-5.2-Codex Emekli Oluyor: Şimdi Ne Olacak? yazımızda bu konuya da değinmiştik.
Şimdi gelelim işin can alıcı noktasına. Daha fazla bilgi için Kubernetes v1.36 Route Sync Metriği: CCM’de Yeni Bir Pencere yazımıza bakabilirsiniz. Bu konuyla ilgili Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek yazımıza da göz atmanızı tavsiye ederim.
Ajanik akış ne demek?
Peki, ne yalan söyleyeyim, Kısaca söyleyeyim: ajanik akış demek işi tek tek sizin yapmanız yerine aracın sizin yerinize bazı adımları koşması demek. Sanki stajyeriniz varmış gibi düşünün ama stajyer yorulmuyor (keşke). Kod analizi yapıyor, bağımlılıkları tarıyor, upgrade önerisi çıkarıyor, bazen deployment dosyasına kadar dokunabiliyor. Daha fazla bilgi için SIG Architecture API Governance: Kubernetes’in Sessiz Kahramanı yazımıza bakabilirsiniz.
Bence bunun en güçlü tarafı tekrar edilebilir olması. Çünkü kurumsal dünyada her uygulama için sıfırdan keşif yapmak pahalıya geliyor. Aynı desenleri tekrar tekrar görüyorsunuz: eski JDK sürümü, kırık testler, unutulmuş config dosyaları… Bu yüzden döngüsel model mantıklı.
Küçük ekip mi kurumsal yapı mı?
Küçük ekiplerde avantaj net: hızlı deneme yaparsınız, az sayıda uygulamada etkisini hemen görürsünüz ve karar almak kolaydır. Startup tarafında mesela iki kişiyle üç servis yönetiyorsanız Copilot destekli modernizasyon bayağı iş görüyor. Daha fazla bilgi için MCP Tool Çağrılarını .NET’te Yönetmek: AGT ile Pratik Yol yazımıza bakabilirsiniz.
Büyük kurumsal yapılarda işe resim değişiyor. Orada standartlaşma lazım; aksi hâlde her takım kendi modernizasyon yorumunu yapar ve ortaya güzel kaos çıkar (evet tam öyle). Bu yüzden enterprise tarafta önce politika belirlemek gerekir: hangi runtime destekleniyor, hangi dependency kabul ediliyor, hangi güvenlik kontrolleri zorunlu…
Sahada gerçekten nerede işe yarıyor?
Bir dakika, şunu da ekleyeyim: benzer araçların en faydalı olduğu yerler genelde sıkıcı görünen işlerdir. Mesela Java versiyon yükseltme öncesi kod taraması yapmak veya Struts’tan Spring’e geçerken bağımlılık haritası çıkarmak gibi işler insanı yoruyor ama makineyi pek yormaz.
| Alan | Manuel yaklaşım | Ajanik/Copilot destekli yaklaşım |
|---|---|---|
| Kod analizi | Zaman alır | Daha hızlı başlangıç verir |
| Build düzeltme | Deneme-yanılma çok olur | Öneri ve otomasyonla hızlanır |
| Migrasyon planı | Ekip tecrübesine bağlıdır | Daha sistematik ilerler |
| Risk kontrolü | Sıklıkla sonradan fark edilir | Daha erken görünür hâle gelir |
İtiraf edeyim, Neyse uzatmayalım; tablo güzel ama gerçek hayat biraz daha kirli oluyor çünkü legacy sistemlerde dokümantasyon eksikliği başlı başına problem yaratıyor.
Bende bıraktığı ilk izlenim ne öldü?
Açık konuşayım: ilk denediğimde beklentim çok yüksek değildi! Hatta 2024 Mart’ta İzmir’de bir üretim müşterisinde test ederken “tamam yine birkaç öneri verip kenara çekilir” diye düşünmüştüm. Ama özellikle dependency upgrade öncesi risk alanlarını göstermesi fena değildi; bayağı işe yaradı diyebilirim.
Yine de ilk hata mesajını görünce biraz gülmüştüm. Build pipeline içinde eksik toolchain yüzünden işlem yarıda kaldı (klasik). Çözüm basitti aslında: agent’ın kullandığı ortamla bizim CI ortamını eşitledik ve sonra akış toparlandı…. İşte tam burada deneyim devreye giriyor; araç ne kadar iyi olursa olsun çevresel uyum yoksa sonuç yarım kalıyor.
Bence Türkiye’de asıl mesele maliyet değil süreklilik
Bu yüzden ilk hedef “büyük dönüşüm” değil,
küçük kazanımları alışkanlık hâline getirmek olmalı.
Bunu Türkiye’deki şirketler açısından değerlendirirsek şöyle görüyorum: lisans maliyeti veya Azure tüketimi çoğu zaman konuşulur ama asıl maliyet geciken kararlar oluyor. Eski runtime’da çalışan uygulama bugünün işini görüyor olabilir; fakat yeni güvenlik gereksinimleri gelince durum değişiyor ve maliyet sessizce büyüyor.
E tabi Azure tarafında fiyatlandırmayı TL bazında düşününce bazı ekiplerin eli frene gidiyor… haklılar çünkü kur etkisi hissediliyor. O yüzden ben genelde şöyle öneriyorum: tüm portföyü aynı anda dönüştürmeye kalkmayın; önce hayatı olmayan ama temsil gücü yüksek bir uygulamada başlayın.
- Önce en sorunlu dependency listesini çıkarın.
- Daha sonra test kapsamını kontrol edin; test yoksa önce önü güçlendirin.Paket yöneticisi ve build zincirini sadeleştirin.COPILOT çıktısını körlemesine kabul etmeyin; inceleyip onaylayın.Kritik olmayan bir pilot uygulama seçip oradan öğrenin.
Küçük startup iseniz daha agresif ilerleyebilirsiniz çünkü karar mekanizması kısa olur. Hata yaptığınızda geri dönmek kolaydır.
Ama büyük bankacılık ya da telekom ortamındaysanız önce governance gerekir — yoksa herkes farklı şekilde modernize etmeye kalkar.
Ben Logosoft’ta buna benzer bir projede bunu yaşadım; ekipler ayrı ayrı hareket edince standardizasyon kayboldu,
sonra yeniden hizalama yapmak zorunda kaldık.
Kolay olmadı.
Ama öğreticiydi.
Bayağı öğreticiydi.
E tabi böyle deneyimler insana şunu öğretiyor:
araç önemli,
ama süreç daha önemli (ilk duyduğumda inanamadım)
Nereden başlamalı? Pratik yol haritası
# Basit başlangıç akışı
1) Uygulamayı keşfet
2) Bağımlılıkları listele
3) Öncelikli upgrade hedeflerini belirle
4) Testleri koştur
5) CI/CD ile doğrula
6) Küçük adımlarla canlıya al
7) Tekrar et
Garip gelecek ama, Eğer bütçeniz kısıtlıysa tam kapsamlı platform yatırımı yerine önce assessment odaklı başlayabilirsiniz.
Yanı her şeyi aynı anda otomasyona bağlamak zorunda değilsiniz.
Bazen yalnızca raporlama bile yeterlidir;
hangi modülün eski olduğunu görmek bile doğru sırayı verir.
Bu noktada GitHub Copilot Modernize tarzı seri içerikler iyi referans olur,
çünkü ekibe ortak dil kazandırır.
“Ben olsam ilk hafta şu üç şeyi yapardım:
bir,
runtime envanteri;
iki,
test sağlığı;
üç,
deployment bağımlılıkları.
Sonra ancak AI yardımıyla refactor veya migrate kısmına girerdim.
Aksi hâlde parlak araçlarla duvara toslamak kolay.”
Sıkça Sorulan Sorular
Copilot Modernize serisi kime hitap ediyor?
Eski Java uygulamalarıyla boğuşan geliştiriciler ve platform ekipleri için biçilmiş kaftan aslında.
Bilhassa modernizasyon yoluna yeni adım atan takımlar hızlıca bir şeyler öğrenebiliyor.
Kurumsal tarafta işe mimarlar da faydalanıyor — hani genel resmî görmek isteyenler için de güzel bir başlangıç noktası.
Tamamen otomatik migration mümkün mü?
Açıkçası pek sanmıyorum.
Araçlar ciddi bir hız kazandırıyor, ama güvenlik, uyumluluk ve test doğrulaması gibi kritik noktalarda insan gözü şart kalıyor.
Tecrübeme göre tam otomasyona güvenmek yerine kontrollü bir otomasyon kurmak çok daha sağlıklı sonuç veriyor.
Küçük ekipler bu işe nereden başlamalı?
Bence en mantıklısı pilot bir uygulamayla başlamak.
Yanı az sayıda servis üzerinden öğrenmek hem maliyeti düşürüyor hem de süreci hızlandırıyor.
Sonra o deneyimi diğer servislere yavaş yavaş yayabilirsiniz — mesela iki serviste öğrendikleriniz geri kalanlar için zaten yol haritası oluyor.
Büyük kurumlarda en büyük tuzak ne?
Standartsızlık. Hepsi bu kadar aslında.
Her takım farklı araçla, farklı yöntemle ilerlerse kısa vadede hız kazanıyormuş gibi görünüyor, ama orta vadede operasyonel kaos kaçınılmaz oluyor.
Bence bu riski en baştan konuşmak ve ortak bir çerçeve belirlemek çok kritik.
Kaynaklar ve İleri Okuma
Microsoft Developer Blog — GitHub Copilot Modernize 101 duyurusu
Azure for Java Developers resmî dokümantasyonu
Microsoft GitHub organizasyonu — örnek projeler ve araçlar
Ayrıca blogumuzdaki Visual Studio’da Bulut Ajanları: Kod Akışını Değiştiren Güncelleme, Durable Workflows ile Microsoft Agent Framework: Gerçek Hayatta Ne İşe Yarıyor? ve Azure Developer CLI Nisan 2026: Çok Dilli Hook Devri Başladı yazıları da aynı damardan besleniyorlar — konuyu farklı açılardan ele almak isteyenlere büyük ihtimalle öneririm.
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