GitHub Copilot Cloud Agent İçin Runner Kontrolü: Kurumsal Düzen

Q: 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.; ;

⏱️ 6 dk okuma📅 3 Nisan 2026👁️ 2 görüntülenme

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. Ilk 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 sisiyor 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?

Iş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ı takimlara 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 konusmustuk. Ekipler repository bazında kendi copilot-setup-steps.yml dosyasını kurmustu. Her repoda farklı davranış çıkınca denetim ekibi kafayı yemisti 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 ajaninizin 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 bolgesinden çı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. Isterseniz 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. Google Vids’e Gelen Yapay Zekâ Hamlesi: Ücretsiz Video Üretimi yazımızda bu konuya da değinmiştik. GitHub Actions Nisan 2026 Güncellemeleri: Üç Kü… yazımızda bu konuya da değinmiştik.

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. Işte burada performans ve erişim birlikte cozulunce olay toparlandı.

E tabii 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	Icer 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 kilmak başka şeydir. Default koyarsiniz ama ekiplerden biri gider kendi işine göre override eder… Sonra audit sırasında herkes birbirine bakar. Bu konuyla ilgili Microsoft Agent Framework 1.0: Ajanlar Artık Ciddileşti yazımıza da göz atmanızı tavsiye ederim.

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.” copilot ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.

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.

💡 Bilgi: Organization düzeyinde default + lock yaklaşımı özellikle çok repolu yapılarda standardizasyon sağlıyor; fakat self-hosted runner kullandığınızda güvenlik yamaları ve erişim kontrolleri sizin sorumlulugunuzda kalıyor.

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. Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor? yazımızda bu konuya da değinmiştik.

# Mantik ornegi
organization:
default_runner: large-github-actions-runner
lock_runner_setting: true
repositories:
— api-service
— data-platform
— release-automation

Bu örnek tabii 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 yonet (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 haritalayin.

Maliyet etkisini özellikle large runner tarafında izleyin.

Sekonder team’lere rollout öncesi kısa eğitim verin. — ciddi fark yaratıyor

Self-hosted kullanilacaksa 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. Isterseniz bunu kilitleyerek repo bazında değiştirilmesini engellersiniz…. Ve sonuç: standardizasyon kolaylaşır.;

;