GitHub Agent Apps ile Yazılım Akışını GitHub'da Toplamak

⏱️ 4 dk okuma📅 16 Ağustos 2026

Bir pull request üzerinde çalışırken kaç sekme açık tutuyorsunuz? Ürün analitiği, bağımlılık taraması, feature flag yönetimi ve olay (incident) durumu genellikle farklı araçlarda durur; geliştirici de aynı bağlamı dört ayrı yere elden taşır. GitHub’ın tanıttığı agent apps, bu araçları doğrudan GitHub arayüzüne getiriyor ve geliştiricinin ortamdan çıkmadan aynı kararları verebilmesini amaçlıyor.

Bu yazıda, kaynak makaledeki örnek senaryo üzerinden agent apps’in nasıl konumlandığını ve GitHub üzerinde hangi noktalarda devreye girdiğini ele alıyoruz. Örnek, bir ücretsiz deneme onboarding akışındaki “takım arkadaşlarını davet et” adımının opsiyonel hale getirilmesi görevi üzerinden ilerliyor.

Agent apps nedir ve nerede çalışır?

Agent apps, GitHub Copilot cloud agent ile aynı altyapı ve harness üzerinde çalışan, üçüncü taraf servislerin GitHub içinde ajan olarak konumlanmasını sağlayan uygulamalar. Amaç, Amplitude, LaunchDarkly, Endor Labs, PagerDuty gibi hâlihazırda kullanılan servislerin sunduğu bağlamı ve yetenekleri pull request’in yanına taşımak.

Bir agent app’i çağırmanın üç yolu var:

Bir issue’ya atayarak bir görevi başlatmak.
Pull request yorumunda @mention ile analiz veya aksiyon istemek.
Repository içindeki Agents sekmesinden seçmek.

Örnek senaryo: Onboarding adımını opsiyonel yapmak

Kaynak makalede geliştiricinin dört aşamalı bir soru zinciriyle ilerlediği bir senaryo aktarılıyor: doğru değişiklik mi, bağımlılıklar temiz mi, güvenli şekilde nasıl yayına alınır ve şu an deploy etmek güvenli mi? Her sorunun cevabı farklı bir araçta olduğu için agent apps devreye giriyor.

1. Kod yazmadan önce: Ürün verisiyle doğrulama

Destek ekibi, davet adımının kullanıcıları rahatsız ettiğini söylüyor ama somut veri sunmuyor. Amplitude arayüzüne geçip sorgu kurmak yerine geliştirici, doğrudan Agents sekmesinden Amplitude ajanına soruyor:

@amplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments we're measuring.

Kaynağa göre gelen yanıt net bir ayrım sunuyor: takım kullanıcıları için adımı tamamlamak sonraki retention ile ilişkiliyken, tekil (solo) kullanıcılarda böyle bir korelasyon görülmüyor. Bu bulgu, adımın solo kullanıcılar için opsiyonel hale getirilip takımlar için korunması yönünde bir rescope’u destekliyor.

2. Geliştirme sırasında: Bağımlılık sağlığı

Copilot değişiklik için bir taslak pull request açıyor. Onboarding akışında kullanılan bazı bağımlılıklar da güncellenmiş durumda. CI taramasının başarısız olmasını beklemek yerine geliştirici, Endor Labs ajanına yorum içinde soruyor:

@endor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request?

Ajan değişen bağımlılıkları belirliyor, bilinen güvenlik açıkları ve genel paket riski açısından değerlendirip pull request içinde raporluyor. Kaynağa göre bu örnekte remediation gerektiren bir bulgu yok. Böylece bağımlılık incelemesi CI başarısızlığından sonra değil, değişiklik hâlâ önünüzdeyken proaktif biçimde yapılmış oluyor.

3. Yayına alma: Feature flag kurulumu

Bir önceki adımdan çıkan sonuç uygulamaya taşınıyor: solo kayıtlar opsiyonel yolu görürken takımlar mevcut akışta kalıyor. Segmentler kayıt anında belirlendiği için bir feature flag ile hedeflenebiliyor. Geliştirici, LaunchDarkly ajanına şu talimatı veriyor:

@launchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code. 
- key: defer-team-invite 
- type: boolean 
- default: false 
- target: solo-intent signups 
- rollout: internal > 5% > 25% > 100%

Ajan flag’i LaunchDarkly’de oluşturuyor ve kod tarafındaki uygulamayı, incelenmek üzere bir commit olarak ekliyor. Kaynağa göre hedef ortam onay gerektiriyorsa targeting değişikliği doğrudan uygulanmıyor, bir onay isteği oluşturuluyor. Yayının ilerleyip ilerlemeyeceğine yine bir insan karar veriyor.

4. Merge öncesi: Deploy riski değerlendirmesi

Kodun doğru olması, servisin deploy için uygun durumda olduğu anlamına gelmiyor. Merge öncesi geliştirici PagerDuty ajanına soruyor:

@pagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed.

Kaynağa göre ajan repository’yi ilgili PagerDuty servisine eşliyor, aktif olayları kontrol ediyor, son 90 günlük olay geçmişini inceliyor ve pull request’te değişen dosyaları geçmiş olaylarla ilişkili alanlarla karşılaştırıyor. Örnek durumda aktif olay yok, anlamlı bir korelasyon da bulunmuyor; öneri ilerlemek yönünde.

Neyi değiştiriyor?

Kaynağın vurguladığı asıl fikir şu: Amplitude, LaunchDarkly, Endor Labs ve PagerDuty hâlâ kullanılıyor, ama aralarındaki bağlam artık elden taşınmıyor. Fikirden üretime giden yolda hangi servisin bağlamı gerekirse geliştirici onu GitHub içinde çağırıyor. GitHub böylece geliştiricilerin ve ajanların bir sonraki adımı koordine ettiği ortak zemine dönüşüyor.

Marketplace’te öne çıkan diğer agent apps

Kaynak makalede, ilk parti olarak yer alan bazı agent apps örnekleri de sıralanıyor:

Packfiles: Backlog’u okuyarak bir migrasyon stratejisi oluşturuyor.
Miro: Görsel iş birliği ile kod akışlarını birbirine bağlıyor.
Bright Security: Uçtan uca dinamik güvenlik testini GitHub içinde otonom olarak yürütüyor.
SonarQube: Analiz, kalite kapıları ve remediation’ı GitHub ajan oturumlarına taşıyor.
Octopus Deploy: Deploy hatalarını tespit edip teşhis ve çözüm önerileri sunuyor.

Agent apps, GitHub Marketplace üzerinden kurulup organizasyon için etkinleştirilebiliyor. Ardından issue atamak, PR yorumunda mention etmek veya Agents sekmesinden seçmek yoluyla kullanılabiliyor.

Sonuç

Agent apps’in getirdiği değişiklik köklü bir araç değişikliği değil; bağlamın konumu değişiyor. Ürün verisi, bağımlılık analizi, feature flag yönetimi ve olay durumu gibi girdiler, geliştiricinin pull request’i açık tuttuğu sekmede erişilebilir hale geliyor. Bu da hem sekme yorgunluğunu azaltıyor hem de deploy riski gibi kontrolleri “bir şeyler ters gittiğinde” değil, rutin bir adım olarak yapılabilir kılıyor.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102