GitHub Copilot Cloud Agent İçin Runner Kontrolü: Kurumsal Düzen
Bakın şimdi, GitHub tarafında küçük gibi duran ama kurumsalda baya iş yapan bir güncelleme var. Copilot cloud agent artık görev başına yeni bir geliştirme ortamı açıyor. O ortamın hangi runner üzerinde kosacagini kuruluş seviyesinde kontrol edebiliyorsunuz. İlk bakışta “tamam işte, bir ayar daha” deyip geçebilirsiniz. Ama sahada, özellikle çok ekipli yapılarda, bu ayar bazen gecenin köründe çıkan bir yangını sonduruyor.
Hani, Ben bu tip değişikliklerin etkisini genelde şöyle olcuyorum: Geliştirici deneyimi rahatlıyor mu, güvenlik ekibi içini rahat bırakabiliyor mu, bir de maliyet tarafı saçma sapan şişiyor mu? Eğer üçüne de dokunuyorsa, o özellik küçücük görünse bile kıymetli oluyor (yanlış duymadınız). Bu güncelleme tam o kulvarda koşuyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Neden bu kontrol önemli hâle geldi?
İşin aslı şu ki, Copilot cloud agent her görevde temiz bir ortam açınca işler düzenli kalıyor; kirli state kalmıyor, “bende çalışıyordu” klasiği azalıyor. Ama default olarak standart GitHub-hosted runner ile gelmesi bazı takımlara yetmiyor (buna dikkat edin). Mesela büyük repo’larda test süresi uzuyor, internal ag kaynaklarına erişim gerekiyorsa standart runner duvara tosluyor, veri yerlestimi hassasiyetiniz varsa da işler biraz çetrefilli hâle geliyor.
Geçen yıl 2025’in Kasım ayında Logosoft’ta bir finans müşterisinde benzer bir konuyu konuşmuştuk. Ekipler repository bazında kendi copilot-setup-steps.yml dosyasını kurmuştu. Her repoda farklı davranış çıkınca denetim ekibi kafayı yemişti diyeyim. Bir yerde self-hosted runner vardı, öbür yerde yoktu… Sonuç? Standartlaştırma ihtiyacı pat diye ortaya çıktı.
Bir de şu var: Kurumsal dünyada mesele sadece hız değil. Bazen ajanınızın nerede çalıştığı bile başlı başa politika konusu oluyor. Hani “su job internal registry’ye ulaşacak”, “su testler özel agdaki servisle konusacak”, “su pipeline EU bölgesinden çıkmayacak” gibi talepler gelir ya — işte organization-level runner control tam oralara dokunuyor.
Bunu biraz açayım.
Kurumsalda en pahalı hata çoğu zaman teknik hata değil; tutarsızlık hatasidir. Aynı işi farklı repolarda farklı kurallarla koşturuyorsanız, sorun ertesi gün değil önceki gece baslamistir.
Organization seviyesinde ne değişiyor?
Önceki modelde kontrol büyük ölçüde repository seviyesine sıkışmıştı. Yanı her repo için ayrı copilot-setup-steps.yml düzenlemek gerekiyordu. Küçük ekipte idare eder; hatta startup ortamında fazla bile gelebilir. Ama enterprise tarafta yüzlerce repo varsa? Buyurun size operasyonel sürpriz paketi.
Yeni modelde organization admin default runner tanimlayabiliyor. Böylece Copilot cloud agent tüm repolarda otomatik olarak aynı temeli kullanıyor. İsterseniz bunu kilitliyorsunuz; böylece repository sahipleri gelip kendi kafasına göre override edemiyor. Açık konuşayım, governance açısından güzel hamle bu.
Araya gireyim: Ben AZ-305’e hazırlanırken tasarım kararlarinin nasıl katman katman ilerlediğini çok düşünmüştüm: merkezî politika mi olacak, yerel esneklik mi? Burada da aynı ikilem var aslında. Çok esneklik verirseniz kaos büyüyor; çok sıkı kilitlerseniz ekipler yavaşlıyor. Yeni kontrol tam ortada bir yerde durmaya çalışıyor ve fena da durmuyor.
Kime ne fayda sağlar?
Küçük bir startup için standart GitHub-hosted runner gayet yeterli olabilir. Hızlı hareket etmek istiyorsanız ugrasmayiz bile. Peki bunu neden söylüyorum? Ama orta ölçekli veya regüle yapılarda large runner ya da self-hosted runner seçimi resmen nefes aldirmir.
Mesela 2026 Mart ayında Ankara’da görüştüğüm bir SaaS firmasında build süreleri yüzünden geliştiriciler PR açarken sinirlenmeye başlamıştı. Runner’i buyutunce süreler kısaldı ama asıl fark internal cache erisimiyle geldi. İşte burada performans ve erişim birlikte cozulunce olay toparlandı.
E tabiî dezavantajı da var: Self-hosted runner dediğiniz şey “kurdum bitti” değil. Patch yönetimi var, ölçekleme var, log toplama var… Biraz bakım ister. Kağıt üstünde süper görünür ama pratikte operasyon yükü çıkarır.
| Seçenek | Artışı | Ekşi tarafı |
|---|---|---|
| Standard GitHub-hosted runner | Kolay başlangıç, yönetim derdi az | Sınırlı hız ve ag erişimi |
| Büyük GitHub Actions runner | Daha iyi performans, daha fazla kaynak | Maliyet artabilir |
| Self-hosted runner | İcer kaynaklara erişim, tam kontrol | Bakım ve güvenlik sorumluluğu sizde |
Kilit mekanizma neden kritik?
Şahsen, Bana kalırsa asıl oyun değiştirici nokta lock özelliği. Çünkü default belirlemek başka seyidir, önü zorunlu kılmak başka şeydir. Default koyarsınız ama ekiplerden biri gider kendi işine göre override eder… Sonra audit sırasında herkes birbirine bakar.
2024 sonbaharında İzmir’deki bir üretim firmasına danışmanlık verirken buna benzer bir durum yaşamıştık; platform ekibi ortak policy istemisti ama ürün ekipleri “bizim testimiz farklı” diye direniyordu. Bir noktadan sonra governance ile hız arasında çizgi çekmek gerektiğini net gördük. Kilitleme seçeneği o çizgiyi sağlıyor.
Kilit açık olursa ne olur?
Ekipler belli sınırlar içinde özgür kalır; mesela bazı repolar daha güçlü runner’a geçebilir ya da özel ihtiyaçları için self-hosted yapı kullanabilir.
Ama disiplin zayıfsa kısa sürede standartlar parcalanir; biri büyük runner kullanır, biri standard’da kalır, biri de eski ayarı unutup yıllarca surundurur.
Kilit kapalı olursa ne olur?
Daha sert ama daha temiz bir yapı oluşur. Özellikle bankacılık, kamu veya sağlık gibi sektörlerde bu model bayağı iş yarar çünkü denetimde tek cevap verirsiniz: “Standart bu.”
Lakin her şeyi kilitlemek de iyi fikir değil; bazı takımlar gerçekten farklı compute ihtiyacı duyabiliyor (örneğin GPU gerektiren analiz işleri). O yüzden politikayı körlemesine değil akıllıca koymak lazım.
Sahada nasıl uygulanır?
Bunu uygularken ben olsam ilk adımı pilot yapardım. Önce tek business unit seçerim, birkaç kritik repo belirlerim ve build sürelerine bakarım. Hani hemen herkese yaymak yerine küçükten başlamak daha mantıklı olur ya — burada da aynı mantık geçerli.
# Mantik ornegi
organization:
default_runner: large-github-actions-runner
lock_runner_setting: true
repositories:
— api-service
— data-platform
— release-automation
Bu örnek tabiî konsept gösteriyor; gerçek yapı GitHub Docs’taki yonergelerle kurulmalı. Ama fikri veriyor: merkezî politika tanımla, gerekirse kilitle ve sonra istisnaları bilinçli yönet (bizzat test ettim)
İşte tam da bu noktada devreye giriyor.
Burada gözden kaçırılmaması gereken noktalar
- Ag erişimi gerektiren job’ları önceden haritalayın.
- Maliyet etkisini özellikle large runner tarafında izleyin.
- Sekonder team’lere rollout öncesi kısa eğitim verin. — ciddi fark yaratıyor
- Self-hosted kullanılacaksa patching ve scaling planını yazılı hâle getirin.
Kullanım senaryoları ve pratik yorumum
;
Burada, cOPILOT cloud agent için organizasyon düzeyinde runner secibilmek bence iki ana senaryoda pariliyor: performans hassasiyeti olan ekipler ve güvenlik/uyum baskısı yaşayan kurumlar…
;
Biri bana geçen ay Berlin’deki bir ISV firmasında şunu sormuştu: “Biz niye her repoda ayrı setup dosyasıyla ugrasiiyoruz?” Cevap basitmiş gibi dürüyor ama değil — çünkü merkezî yönetişim eksikliği zamanla teknik borca dönüşüyor;
;
baya sessiz sedasız büyüyor o borç… Sonra CI/CD akışı bozulunca herkes birbirine bakıyor;
;
Sıkça Sorulan Sorular
Copilot cloud agent için organization-level runner control ne işe yarar?;
Tüm repolar için varsayılan runner tanımlamanızı sağlar. İsterseniz bunu kilitleyerek repo bazında değiştirilmesini engellersiniz…. Ve sonuç: standardizasyon kolaylaşır.;
;
Büyük GitHub Actions runner mı yoksa self-hosted mı tercih edilmeli?;
Eğer amaç sadece hız işe büyük GitHub Actions runner yeterli…. İç sistemlere erişim gerekiyorsa self-hosted daha doğru seçim olur.;
;
Kilit özelliği neden önemli?;
Kilit özelliği kurumsal tutarlılık sağlar…. Repo sahiplerinin ayarı bozmasını engeller ve denetimde netlik verir.;
;
Küçük ekiplerde buna gerçekten ihtiyaç var mı?;
Çoğu küçük ekip için şart değildir…. Ama regülasyon veya özel ağ ihtiyacı varsa erken dönemde bile anlamlı olabilir.;
;
Kaynaklar ve İleri Okuma
;
GitHub Actions Resmî Dokümantasyonu
;
GitHub Copilot Resmî 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.
