GitHub’da Deployment Context: Repo ve Alert Yönetimi

Bence, şunu açıkça söyleyeyim: güvenlik alertlerini önceliklendirmek, hele büyük yapılarda, insanın canını sıkıyor. Geçen ay bir finans kuruluşunda tam da buna takıldık. Dependabot 200’den fazla alert üretmişti. Ekip, hangisinin gerçekten production’da çalışan bir servise ait olduğunu anlamak için saatler harcıyordu. Hani düşünün — bir kütüphanede hayatı zafiyet var. O kütüphane sadece test reposunda kullanılıyor; aynı zafiyet, canlıda müşteri trafiği alan bir mikroserviste de var. İkisine aynı gözle mi bakacaksınız? Tabii ki hayır (yanlış duymadınız).

İşte GitHub’ın yeni duyurduğu “deployment context” özelliği bu işi biraz toparlamaya çalışıyor. Repo seviyesinde iki yeni yerleşik property ve güvenlik alert sayfalarında runtime risk bağlamı… Kağıt üstünde fena değil. Ama dur bir saniye — asıl soru şu: pratikte gerçekten iş görüyor mu? Benim ilk refleksim “eh, bakalım” oldu.

Deployable ve Deployed: İki Yeni Repo Property’si

Açıkçası GitHub, repository’lere iki yeni built-in property ekledi: deployable ve deployed. Bunlar artifact deployment metadata’sından otomatik besleniyor, yani elle “bu repo canlıda” diye bir yere not düşmenize gerek kalmıyor. Sistem zaten görüyor, işin güzel yani da bu. Kulağa küçük geliyor ama pratikte bayağı iş görüyor.

Şimdi, kısa bir not düşeyim buraya.

Peki neden? Deployable demek “bu repodan bir artifact çıkabilir, deploy edilebilir” demek. Deployed ise “bu repo şu anda gerçekten bir ortama deploy edilmiş durumda” demek. Arada ince ama hayatı bir fark var. Bir repo deployable olabilir ama henüz hiçbir yere deploy edilmemiş olabilir; mesela yeni geliştirilen bir mikroservis düşünün, CI/CD pipeline’ı hazır, container image’ı build ediliyor (hatta testler de geçiyor olabilir), ama daha staging’e bile çıkmamış. Bu repoyu deployed olanlarla aynı sepete koymak pek mantıklı durmuyor.

Logosoft’ta bir telekomünikasyon müşterimizde tam olarak bu tarz bir sınıflandırma sıkıntısıyla uğraşıyorduk. 400’den fazla repo var, hangisi production’da aktif, hangisi arşivlenmiş ama silinmemiş, hangisi sadece deneme için açılmış — kimse net söyleyemiyordu. Manuel bir Excel tablosu tutuluyordu, inanabiliyor musunuz? 2025’te Excel’le repo takibi… Şey yani, biraz yorucu bir yöntemdi (en azından benim deneyimim böyle). Neyse uzatmayayım, bu yeni property’ler o Excel dosyasını kenara itebilir.

Peki neden?

Kendi deneyimimden konuşuyorum. Tam da öyle.

Filtreleme ve Ruleset Entegrasyonu

Bu property’lerin asıl işe yaradığı yer filtreleme ve policy tarafı. Organizasyon seviyesinde şunu yapabiliyorsunuz:

• Deployed olan büyük çoğunluk repolara otomatik olarak branch protection kuralları uygulama
• Deployable ama henüz deployed olmayan repolara farklı bir ruleset atama
• Compliance policy’lerini sadece canlıya çıkan repolara hedefleme
• Organizasyon dashboard’unda “şu anda canlıda olan repolar” diye filtreleme

Bak şimdi, benim en hoşuma giden kısım şu: bu property’ler deployment durumu değiştikçe otomatik güncelleniyor. Yani bir servisi decommission ettiğinizde deployed property’si de düşüyor. Policy enforcement da buna göre şekil alıyor. Eskiden bunu yapmak için ya custom Actions" data-glossary-term="GitHub Actions">GitHub Actions yazıyordunuz ya da üçüncü parti bir araçla uğraşıyordunuz; açık konuşayım, ikisi de idare ederdi. Biraz el işi kokuyordu.

Bilmem anlatabiliyor muyum, Bir şey dikkatimi çekti: Evet.

Neyse, çok dağıttım gibi oldu ama konu aslında basit: GitHub artık repo’nun neye uygun olduğunu. Gerçekten nerede yaşadığını daha net biliyor. Peki, siz ne dersiniz? Böyle bir ayrım size de mantıklı geliyor mu?

Runtime Risk Context: Alertler Artık Bağlam Taşıyor

Bu ikinci kısım daha ilginç, açık konuşayım (buna dikkat edin). Dependabot ve GitHub Code Scanning alert sayfalarında artık runtime risk bağlamı da görünüyor. Bir alert’i açınca, etkilenen artifact’ın deployment durumunu. Hangi ortamda çalıştığını görüyorsunuz; risk seviyesini de tek bakışta ayıklıyorsunuz.

Şunu fark ettim: Bunu Türkiye’deki şirketler açısından düşününce tablo tanıdık geliyor (ben de ilk duyduğumda şaşırmıştım). Çoğu kurumsal müşterimde güvenlik ekibi ile geliştirme ekibi arasında ince bir çizgi yok, baya kalın bir kopukluk var; güvenlik ekibi alert’i görüyor, “kritik” deyip ticket açıyor, geliştirici de “abi bu repo 6 aydır kullanılmıyor, o servis kapandı” diye dönüyor, sonra iş başka bir ekibe gidiyor ve ping-pong uzayıp gidiyor. İşte runtime context tam burada devreye girip bu döngüyü kırabiliyor (en azından benim deneyimim böyle).

Bir dakika — bununla bitmedi.

Bir güvenlik alert’ının gerçek riskini anlamak için sadece CVSS skoruna bakmak yetmez — o zafiyetin production’da, müşteriye açık bir serviste çalışıp çalışmadığını bilmek gerekir. GitHub’ın runtime context özelliği tam olarak bu eksik parçayı tamamlıyor.

Triage Sürecinde Somut İyileşme

Geçen yıl bir bankacılık projesinde güvenlik triage sürecini ölçmüştük (buna dikkat edin). Ortalama bir can alıcı Dependabot alert’ının çözülme süresi 4.2 gündü; bunun yaklaşık %60’ı da “bu gerçekten canlıda mı” sorusunun cevabını aramakla geçiyordu. Hmm, bir düşününce mesele aslında çok net: neredeyse 2.5 gün sadece bağlam toplama var ortada. Runtime context ile bu sürenin en az yarıya inmesini bekliyorum; tabi %100 doğru olmayabilir, pratikte nasıl oturacağını biraz kullanım belirleyecek.

Bir dakika — bununla bitmedi.

Küçük bir detay: Güvenlik ekibiniz artık alert listesini açtığında şöyle bir tabloyla karşılaşabilir:

?

Kurumsal Yapılar vs Küçük Ekipler: Kim Nasıl Kullanmalı?

Size bir şey söyleyeyim. Açık konuşayım, bu özellik küçük bir düşüneyim… ekiplerde biraz “olsa da olur” tarafında kalıyor (şaşırtıcı ama gerçek). 10-15 reponuz varsa, hangi repo canlıda, hangisi testte, çoğu zaman zaten aklınızda dönüyor — itiraf edeyim, beklentimin üstündeydi —. Ama 100+ repo, 5+ ekip ve birden fazla deployment ortamı varsa? İşte orada işler değişiyor; bak şimdi, o noktada bu özellik baya iş görüyor.

Enterprise tarafında tablo daha net. Bir holding grubunda 15 farklı şirket düşünün; her birinin ayrı GitHub organizasyonu var ve ortak güvenlik ekibi bütün alertleri tek yerden izlemeye çalışıyor (evet, doğru duydunuz), ama deployment context yoksa bunu nasıl yönetecekler? Manuel envanter listeleri, spreadsheet’ler, belki bir CMDB entegrasyonu (ama onun da bakımı ayrı dert), yani kısacası sürekli el isteyen çözümlerle uğraşıyorsunuz. .NET ve.NET Framework Nisan 2026 Güvenlik Yamaları yazımızda bu konuya da değinmiştik.

Türkiye Özelinde Bir Gözlem

Ne yalan söyleyeyim, Türkiye’deki kurumsal müşterilerde benzer ama biraz daha karışık bir resim görüyorum. Çünkü birçok şirket hâlâ GitHub Enterprise Cloud yerine self-hosted tarafta kalıyor; regülasyonlar, veri lokalizasyonu kaygıları derken iş uzuyor. Bilhassa bankacılıkta ve kamu tarafında bu yaklaşım yaygın. Bu yeni özellikler şimdilik GitHub.com üzerinde GA (Generally Available); Enterprise Server’a ne zaman gelir, doğrusu henüz belli değil (inanın bana). Ha bu arada, GitHub Secret Scanning API ve Webhook İyileştirmeleri yazımda da buna benzer bir GHES gecikmesinden söz etmiştim; GitHub çoğu zaman bu tip şeyleri 3-6 ay sonra GHES’e taşıyor.

Küçük bir startup için benim tavsiyem basit: Özelliği açın, arka planda dursun. Sırf bunun için workflow’u baştan yazmayın. Zaten az repo var; yani günlük hayatınızı kökten değiştirmesi gerekmiyor. Fakat büyüme başladığında elinizde hazır bir zemin olmuş olur. MSVC 14.51 ile C++23 Desteği: Sahadan Notlar yazımızda da buna değinmiştik (şaşırtıcı ama gerçek)

Pratik Uygulama: İlk Adımlar

Dürüst olayım, teori güzel de pratikte iş biraz dağılıyor. Tamam, adım adım gidelim. Peki neden bu kadar uğraşıyoruz? Çünkü küçücük bir eksik, bütün akışı sessizce bozabiliyor; fark etmiyorsunuz bile, sonra bir bakmışsınız deployment olmuş. GitHub tarafı hâlâ habersiz duruyor.

Şöyle başlayalım: Önce artifact’larınızı production context ile eşleştirmeniz gerekiyor. GitHub Actions workflow’unuz deployment event’lerini doğru tetikliyorsa sistem bunu kendi kendine yakalıyor; eh, fena değil. Daha açık söyleyeyim, (söylemesi ayıp) siz ne dersiniz? Custom bir CI/CD pipeline kullanıyorsanız — mesela Azure DevOps ya da Jenkins — o zaman GitHub API üzerinden bu metadata’yı beslemeniz gerekecek, yoksa ortada çalışan bir deployment olsa bile GitHub tarafı bunu görmeyebiliyor. Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor? yazımızda bu konuya da değinmiştik (inanın bana)

# GitHub Actions workflow örneği — deployment context için
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
environment: production # Bu satır kritik!
steps:
— uses: actions/checkout@v4
— name: Deploy
run: |
# deployment komutlarınız
echo "Deploying to production..."
— name: Verify deployment
run: |
# deployment doğrulama
curl -s https://api.myapp.com/health | jq.status

Burada environment: production satırı gerçekten kilit nokta. GitHub bu bilgiyi alıp repo’nun deployed property’sını güncelliyor; siz bunu koymazsanız özellik pat diye susuyor. Ben ilk kurcaladığımda environment tanımlamayı atlamıştım, sonra da “neden property güncellenmiyor” diye iki saat debug yaptım; hatta bir ara sorun bende değilmiş gibi düşündüm. Meğer mesele tek satırdaymış.

Şimdi, bilmem anlatabiliyor muyum, Bütçe tarafı sıkışık mı? O zaman küçük bir not düşeyim. GitHub Enterprise kullanmıyorsanız, bu özelliklerin bir kısmını GitHub Free ve Team planlarında da kullanabiliyorsunuz; yani her şey duvara çarpmıyor. Ama ruleset entegrasyonu ile organizasyon seviyesinde filtreleme işi biraz başka hikâye, orada Enterprise planına ihtiyaç duyuyorsunuz. Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle yazımda da güvenlik özelliklerinin plan bazlı farklarına değinmiştim, hani orası da ayrı bir dünya.

Eksik Kalan ve Beni Hayal Kırıklığına Uğratan Kısımlar

Her şey güllük gülistanlık değil tabi. Birkaç nokta beni dürttü, açık konuşayım; hani ilk bakışta “idare eder” diyorsunuz ama biraz kurcalayınca eksik taraflar kendini belli ediyor, özellikle de kurumsal tarafta iş büyüyünce o boşluklar daha net hissediliyor.

Birincisi şu: multi-cloud deployment tracking yok. Yani bir repo hem Azure’a hem AWS’ye gidiyorsa, hangi ortamda hangi versiyon dönüyor sorusuna net cevap alamıyorsunuz; sadece “deployed” ya da “not deployed” gibi iki uçlu bir bilgi var, bu da pratikte biraz yetersiz kalıyor. GitHub Pages ile Ücretsiz Site Kurulumu: Tam Rehber yazımızda bu konuya da değinmiştik.

İşin garibi, Oysa bizim tarafta işin rengi başka. Çoğu müşteri multi-cloud kullanıyor, bazen aynı uygulama üç ayrı yerde koşuyor; az önce “iyi fikir” dedim ama burada küçük bir fren var, çünkü bu kısıt sahada baya can sıkıyor ve insanın aklına hemen şu soru geliyor: Peki neden daha detaylı değil?

Çok konuştum, örnekle göstereyim.

İkincisi — geçmiş deployment history yok. Property sadece anlık durumu gösteriyor, hepsi bu. “Bu repo 3 ay önce production’daydı, şimdi değil” gibi bir izi göremiyorsunuz; audit yaparken, compliance kontrol ederken, hatta iç denetimde bile eliniz boş kalabiliyor, biraz sinir bozucu yani (eh, fena değil)

Bakın, ne yalan söyleyeyim, Evet.

Üçüncüsü ise şu: Dependabot alert sayfasındaki runtime context kısmı fena değil,. Code Scanning tarafı biraz ham duruyor. CodeQL ile yakalanan bir zafiyet için “bu production’da” bilgisi geliyor, güzel; (inanın bana). Hangi endpoint’ten erişiliyor, public-facing mi yoksa internal mı gibi hayati detaylar ortada yok, yani resim tam oturmuyor. Bu konuyla ilgili Ingress2Gateway 1.0: Ingress’ten Gateway API’ye Geçiş yazımıza da göz atmanızı tavsiye ederim.

Nasıl desem… burada veri var ama bağlam eksik. Biraz daha pişmesi lazım derken abartmıyorum; çünkü güvenlik ekipleri için asıl soru sadece “var mı?” değil, “nerede, nasıl erişiliyor?” oluyor. Işin kritik kısmı da tam orada başlıyor.

Bir bakıma, dürüst olmak gerekirse bu hâliyle iş görüyor. Ama bazı senaryolarda insanı yarı yolda bırakabiliyor; yani kötü değil, sadece tam tamamlanmış hissi vermiyor (en azından benim deneyimim böyle)

FinOps ve Güvenlik Kesişimi: Gözden Kaçan Bir Açı

Bence, Bakın, burada küçük ama can sıkıcı bir detay var. Güvenlik konuşuluyor, tamam,. FinOps tarafı çoğu zaman arka cebeye atılıyor; işin aslı biraz da bu yüzden maliyetler sessizce şişiyor, sonra biri çıkıp “bu niye bu kadar tuttu?” diye soruyor.

Şahsen beni en çok kurcalayan şey şu: Azure’da maliyet optimizasyonu yaparken, “bu kaynak kime ait, hâlâ kullanılıyor mu” sorusu (kendi tecrübem) — dürüst olayım, biraz hayal kırıklığı —. GitHub tarafında da tablo (belki yanılıyorum ama) çok farklı değil gibi geliyor bana; GitHub Advanced Security lisansı repo bazında ücretlendiriliyor, yani 500 reponuz var ama sadece 200 tanesi gerçekten deployed durumdaysa, kalan 300 için boş yere lisans ödüyor olabilirsiniz — deployment context tam burada devreye giriyor, hem de beklediğimden daha anlamlı bir şekilde. Evet, böyle bir boşluk var.

Şöyle ki, 2024’te bir e-ticaret müşterisinde bunu birebir yaşadık. Manuel audit yaptık, iki hafta sürdü, biraz yorucuydu açık söyleyeyim; deployed olmayan repoları GHAS scope’undan çıkarınca aylık yaklaşık 1.200 dolar tasarruf ettik. Şimdi aynı işi (söylemesi ayıp) bu property’lerle otomatik hale getirebiliyorsunuz, hani insanın aklına “neden baştan böyle değildi?” sorusu geliyor. Fena değil.

Dürüst olmak gerekirse, İtiraf edeyim, burada başka bir bağlantı daha var: GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazısında da GitHub’ın platform governance yaklaşımındaki değişimlerden bahsetmiştim (ben de ilk duyduğumda şaşırmıştım). Bu deployment context meselesi de aynı çizginin devamı gibi duruyor; yani GitHub artık sadece kod tuttuğun bir yer olmaktan çıkıp yavaş yavaş platform governance aracına dönüşüyor, hatta bazen fark etmeden FinOps kararlarını da etkiliyor. Siz ne dersiniz?

Sıkça Sorulan Sorular

Deployment context için hangi GitHub planı gerekiyor?

Hani, Temel deployment property’leri zaten Free ve Team planlarda da görünüyor. Ama organizasyon seviyesinde ruleset entegrasyonu, otomatik policy uygulaması, gelişmiş filtreleme istiyorsanız — bunlar için Enterprise’a geçmeniz gerekiyor. GHAS alertlerindeki runtime context de aynı şekilde Enterprise’a özel.

Deployed ile deployable arasındaki fark ne?

Deployable, hani bir repodan build edilebilir bir artifact çıkıyor demek — mesela container image ya da paket gibi şeyler. Deployed ise o artifact’ın şu — itiraz edebilirsiniz tabi — an gerçekten aktif olarak bir ortamda çalışıyor olduğunu gösteriyor. Şimdi, yani bir repo deployable olup deployed olmayabilir — CI pipeline’ı hazır ama henüz canlıya çıkmamış bir servis düşünün mesela.

Bir dakika — bununla bitmedi.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır (kendi tecrübem)

GHES’te de çalışıyor mu?

Tuhaf ama, şu an sadece GitHub.com (Cloud) üzerinde GA durumda. GHES takvimi henül açıklanmadı. Açıkçası GitHub’ın genel pratiğine bakarsak, bence 3-6 ay içinde GHES sürümlerine de gelir. Kesin tarih için GitHub’ın changelog’ünü takip etmenizi öneririm.

Jenkins veya Azure DevOps gibi araçlarla da çalışıyor mu?

Kısacası, ne yalan söyleyeyim, Şöyle söyleyeyim — GitHub Actions dışında bir CI/CD aracı kullanıyorsanız, deployment bilgisini GitHub API üzerinden manuel olarak beslemeniz gerekiyor (ben de ilk duyduğumda şaşırmıştım). GitHub’ın Deployments API’sını kullanarak deployment event’lerini bildirebilirsiniz. Siz ne dersiniz? Tecrübeme göre biraz ekstra iş çıkarıyor, ama aslında gayet yapılabilir bir şey.

Kısa bir not düşeyim buraya.

Runtime context alertleri otomatik kapatıyor mu?

Hayır. Runtime context yalnızca ek bilgi sunuyor — alertleri ne otomatik kapatıyor ne de önceliklendiriyor. Triage kararını hâlâ siz veriyorsunuz, ama artık çok daha iyi bir bağlamla karar verebiliyorsunuz. Bence bu bile başlı başına büyük bir fark. İleride auto-dismiss gibi şeyler gelebilir, ama şimdilik sadece görsel bağlam mevcut.

Kaynaklar ve İleri Okuma

GitHub Docs — Exploring Dependencies of a Repository (şaşırtıcı ama gerçek)

Bence, GitHub Blog — Deployment Context in Repository Properties and Alerts (Orijinal Duyuru)

GitHub REST API — Deployments

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

İlgili Yazılar

Azure Developer CLI Nisan 2026: Çok Dilli Hook Devri Başladı1 May 2026

Node.js Addon'larını .NET Native AOT ile Yazmak21 Nis 2026

mssql-python'a Apache Arrow Desteği: SQL Server için Yeni Devir12 May 2026

SharePoint Framework 1.23 ve Ötesi: Asıl Mesaj Ne?28 May 2026