GitHub Actions Nisan 2026 Güncellemeleri: Üç Küçük Ama Etkili Hamle
İlk bakışta küçük, sahada işe bayağı büyük değişiklikler
Bakın şimdi, GitHub Actions tarafında Nisan başı güncellemelerine dışarıdan bakan biri “eh, birkaç iyileştirme işte” deyip geçebilir. Ama işin aslı şu ki, bazen en çok can sıkan şeyler tam da bu tarz küçük görünen detaylar oluyor. Service container’larda entrypoint ve command override gelmesi, OIDC token’lara repository custom property eklenmesi ve Azure private networking için VNET failover desteği… Üçü de farklı derdine dokunuyor. Birinin derdi test konteyneri, diğerinin derdi güvenlik politikası, üçüncüsünün derdi de “ya region giderse?” paniği.
📋 İçindekiler
- İlk bakışta küçük, sahada işe bayağı büyük değişiklikler
- Service container giriş noktalarını artık sız yönetiyorsunuz
- OIDC token’larda repository custom properties dönemi
- Azure private networking’de VNET failover neden önemli?
- Küçük ekip mi enterprise mı? Etki aynı değil
- Sahada gördüğüm üç pratik ders
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Geçen ay bir müşteride, İstanbul’daki bir finans ekibiyle CI/CD akışını gözden geçirirken service container tarafında aynı tartışmayı yaptık. Docker image düzgün çalışıyor ama pipeline içinde ufak bir komut değişikliği gerektiğinde herkes YAML’a ters takla atıyordu. Hani klasik şey: çözüm var ama kirli çözüm. İşte bu güncelleme tam o tür workaround’ları biraz azaltıyor.
Bir de şunu söyleyeyim: ben AZ-104 ve AZ-500 hazırlık dönemlerinde hep aynı yere takılırım; “güvenlik güzel de operasyonel sürtünme ne olacak?” OIDC custom properties gibi şeyler kağıt üstünde politika işi gibi dürüyor ama pratikte access control modelini çok daha temiz hâle getiriyor. Bilhassa enterprise tarafta.
Ve işler burada ilginçleşiyor.
Service container giriş noktalarını artık sız yönetiyorsunuz
Şimdi gelelim en günlük dertlerden birine. GitHub Actions’da service container kullanıyorsanız, — en azından ben öyle düşünüyorum — bugüne kadar image’ın default entrypoint ve command davranışına fazla karışamıyordunuz. Bu da bazen sizi saçma sapan workaround’lara itiyordu: ayrı script yaz, wrapper image üret, başka yerde komutu kopyala… Epey uğraştıran işler.
Yeni gelen entrypoint ve command override desteği ile workflow YAML içinde doğrudan kontrol sizde oluyor. Docker Compose mantığına benzediği için alışması kolay; yanı “ben bunu zaten biliyorum” hissi veriyor. Açık konuşayım, bu tip tutarlılık önemli. Çünkü ekip içinde herkes farklı araçtan gelmiyor; biri Kubernetes biliyor, biri Compose biliyor, biri sadece pipeline yazmış oluyor (en azından benim deneyimim böyle)
2019’da kendi lab ortamımda benzer bir senaryoyu denemiştim. Bir PostgreSQL service container üzerinde init komutu değiştirmem gerekiyordu. İmage içine gömülü davranış yüzünden yarım gün kaybettim. Şimdi böyle bir ihtiyaçta direkt YAML üzerinden müdahale edebilmek fena değil, hatta baya işe yarıyor.
Kullanım mantığı nasıl görünüyor?
Aşağıdaki örnek kaba taslak bir fikir veriyor. Tabiî gerçek kullanımda image davranışıyla uyumu test etmek şart; her container aynı şekilde huysuzluk yapmıyor (inanın bana). Bazıları resmen nazlı.
jobs:
test:
runs-on: ubuntu-latest
services:
db:
image: postgres:16
entrypoint: ["/bin/sh", "-c"]
command: ["echo 'DB is starting'; docker-entrypoint.sh postgres"]
steps:
— name: Run tests
run: echo "Testing against service container"Buradaki ana fikir şu: artık image’ın default başlangıç davranışına mahkûm değilsiniz. Bir servis konteynerini bazen ayağa kaldırmak yetmez; önce ufak bir hazırlık yaptırmak gerekir. Mesela log basmak, env kontrol etmek ya da özel init süreci işletmek… Bunlar daha önce ekstra katman gerektiriyordu.
E tabiî her özgürlük gibi bunun da bedeli var: yanlış override ile konteyneri bayağı bozabilirsiniz (inanın bana). Yanı “kontrol geldi” diye seviniyoruz ama aynı zamanda dikkat seviyesi de yükseliyor. Enterprise tarafta bunu template hâline getirip standartlaştırmak iyi olur; startup tarafında işe hızlı kazanım sağlar. Bu konuyla ilgili github ile ilgili önceki yazımıza da göz atmanızı tavsiye ederim.
OIDC token’larda repository custom properties dönemi
Gelelim güvenlik tarafına. Burası benim özellikle sevdiğim bölüm öldü çünkü düzen kuruyor (yanlış duymadınız). GitHub Actions OIDC token’larına artık repository custom properties claim olarak geliyor. Bu özellik genel kullanıma açılmış durumda. Yanı cloud provider tarafındaki trust policy’nızı yalnızca repo adıyla ya da ID ile değil, organizasyonunuzun kendi sınıflandırmasıyla da bağlayabiliyorsunuz.
Bunu günlük dile çevirirsek şu anlama geliyor: “Bu repo kim?” sorusuna sadece isimle cevap vermek zorunda değilsiniz; “bu repo hangi takımın”, “hangi ortam tipi”, “hangi uyumluluk seviyesinde” gibi sorularla da erişim verebiliyorsunuz. Geçen sene Logosoft’ta Ankara merkezli bir üretim müşterisinde buna benzer bir model kurguladık; onlar repo sayısı arttıkça tek tek role tanımı yapmakta boğuluyordu. Custom property yaklaşımı orada ciddi rahatlama sağladı.
Peki neden? Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor? yazımızda bu konuya da değinmiştik.
AZ-305 çalışırken mimarı desenlerin en sevmediğim kısmı şuydu: güzel görünürler ama büyüyünce yönetimi ağırlaşır mı? OIDC claims ile custom property kullanımı burada iyi cevap veriyor gibi dürüyor. Çünkü trust policy’nın omurgasını organizasyon modeliyle eşleştiriyorsunuz; manuel liste uzayıp gitmiyor. Bu konuyla ilgili GitHub Copilot CLI Kullanımını Artık Kişi Bazında Görmek Mümkün yazımıza da göz atmanızı tavsiye ederim.
Nerede gerçekten fark yaratır?
- Küçük startup: Az repo varsa çok can alıcı görünmeyebilir ama ileride büyürken temeli sağlam kurarsınız.
- Orta ölçekli ekip: Takımlar ayrıldıkça access policy sadeleşir.
- Enterprise: Compliance tier, business unit ve environment type bazlı erişim modelinde ciddi düzen sağlar.
| Konu | Eski yaklaşım | Yeni yaklaşım |
|---|---|---|
| Erişim tanımı | Repo adı / ID bazlı | Custom property claim bazlı |
| Büyüdükçe bakım | Zorlaşıyor | Daha yönetilebilir kalıyor |
| Mimarı uyum | Kısmen manuel | Tutarlı governance modeli |
Şahsen, Açıkçası buradaki tek hayal kırıklığım şu öldü: özellik güçlü ama düzgün policy tasarlamazsanız size sihir yapmıyor. Yanı claim geldi diye her şey otomatik düzelmiyor; sınıflandırma mantığınız zayıfsa sadece karmaşayı biraz daha modern hâle getirmiş oluyorsunuz…
Azure private networking’de VNET failover neden önemli?
E tabiî üçüncü güncelleme biraz daha altyapı kokuyor. Azure private networking kullanan GitHub-hosted runner senaryolarında artık failover network desteği public preview’da var. Ne demek bu? Primary subnet veya bölge sorun çıkarırsa secondary subnet’e geçebiliyorsunuz; hatta isterseniz farklı bölgede bile olabilir.
Şunu söyleyeyim, Bunu küçümsemeyin. Ben yıllar önce hosting tarafında çalışırken bölgesel ağ problemlerinin nelere yol açtığını defalarca gördüm — saatlik kesinti bile release planını allak bullak edebiliyor (özellikle cuma akşamıysa). Şimdi hosted runner altyapısının arka planda buna karşı esneyebilmesi kötü mü? Değil tabiî ki! Ama yine de preview olduğu için “tamamdır çözüldü” demek için erken.
Sahada nasıl kullanılır?
Eğer enterprise ya da organization hesabıyla Azure private networking kullanıyorsanız bu özellik ciddi nefes aldırabilir. Manuel failover yapabiliyorsunuz ya da — itiraz edebilirsiniz tabiî — GitHub bölgesel outage algılarsa otomatik devreye sokabiliyor. Audit log olayları ve e-posta bildirimleri de geliyor; yanı sessiz sedasız gerçekleşen bir geçiş değil bu. Daha fazla bilgi için PowerShell 7.6 Neden Geç Geldi? Perde Arkası ve Dersler yazımıza bakabilirsiniz.
Bence burada kritik nokta şu: failover’ın teknik kısmından çok operasyonel prosedürü önem taşıyor. Kim tetikleyecek? Ne zaman geri dönülecek? Geri dönüş sırasında deployment akışı nasıl etkilenir? Biz Logosoft’ta geçen yıl EMEA bölgesindeki bir müşteride benzer yedeklilik akışı tasarlarken asıl tartışma firewall’dan çok süreçti… İnsanlar çoğu zaman network çizgisini konuşuyor ama aslında olay karar mekanizmasında bitiyor. github ile ilgili önceki yazımızda bu konuya da değinmiştik.
GitHub Actions tarafında asıl mesaj net: hem hız istiyorsunuz hem de kontrol kaybetmek istemiyorsanız yeni güncellemeler tam bu boşluğu dolduruyor.
Küçük ekip mi enterprise mı? Etki aynı değil
Eh, Küçük bir startup için service container override özelliği hemen fayda verir; çünkü zaman kazandırır. Gereksiz script kalabalığını azaltır. OIDC custom properties işe ilk günden şart olmayabilir ama doğru kurgulanırsa ileride sizi büyük refactor işinden kurtarır. VNET failover işe genelde daha olgun yapılarda anlam kazanır; çünkü private networking zaten belirli bir ölçek ister (kendi tecrübem)
Evet, doğru duydunuz.
Büyük kurumlarda tablo tersine döner biraz… Service container ayarı nice-to-have olmaktan çıkar, standardization aracına dönüşür.
OIDC claims governance’ın omurgası olur.
Failover işe sadece teknik feature değil, business continuity konusu hâline gelir.
Ha bu arada şunu unutmayalım:
her ek özellik beraberinde dokümantasyon borcu getirir.
Doküman yoksa bilgi kişilerin kafasında kalır,
ve orası pek güvenilir bir yer değildir!
Peki ben hangisini önce denerdim?
Bence, Lafı gevelemeden söyleyeyim: önce OIDC custom properties’i denerdim eğer cloud erişimi karmaşıklaşıyorsa. Sonra service container override ile workflow temizlik işine girerdim. Peki, vNET failover işe altyapınız Azure private networking üstüne kurulmuşsa pilot ortamda test edilir. Hepsini aynı anda açmak yerine kontrollü gitmek daha mantıklı olur;
özellikle change management sıkıysa…
Sahada gördüğüm üç pratik ders
Şunu söyleyeyim, Birincisi: Workflow YAML içine gelen her yeni özgürlük dikkat ister.
Bir parametreyi yanlış yazıp tüm testi patlatmak çocuk oyuncağı olabilir.
Bunu geçen mart ayında Berlin’deki bir ürün ekibinde yaşadık;
küçük bir override yüzünden servis ayağa kalktı ama uygulama beklediğimiz portu dinlemiyordu.
Kendi deneyimimden konuşuyorum, İkincisi: Güvenlik politikasını teknik ayrıntıya boğmayın. Custom properties işinizi kolaylaştırmalı, “bir (belki yanılıyorum ama) politika dosyasını kim okuyacak?” sorusuna dönüşmemeli. Ben bunu AZ-500 hazırlığında çok net gördüm;
fazla karmaşık policy = sonra kimse dokunmaya cesaret edemiyor.
Üçüncüsü: Failover özelliğini kurmak başka,
geri dönüş planını işletmek başka şey. Manuel geçiş tamam,
ama primary region toparlandığında ne olacak? O kısmı önceden yazmazsanız operasyon günü kısa süreli panik yaşanıyor… hem de baya gereksiz şekilde.
Sıkça Sorulan Sorular
GitHub Actions’da service container entrypoint override ne işe yarar?
Dışarıdan gelen imajın varsayılan başlangıç komutunu workflow içinden değiştirmeye yarar (kendi tecrübem). Böylece wrapper image yazmadan özel başlatma senaryolarını yönetebilirsiniz.
OIDC token içindeki repository custom properties neden önemli?
Erişim politikalarını repo adı yerine organizasyonun sınıflandırmasına göre kurmanızı sağlar. Bu da büyük yapılarda bakım yükünü azaltır ve trust modelini sadeleştirir.
Azure private networking VNET failover herkese açık mı?
Henüz değil; şu an public preview aşamasında ve yalnızca enterprise veya organization hesaplarıyla Azure private networking kullanan yapılarda kullanılabiliyor. Genel kullanıma açılma tarihi henüz netleşmedi ama preview sürecinde test edip geri bildirım vermek iyi bir adım olur.
Kaynaklar ve İleri Okuma
- GitHub Actions Documentation — Actions kavramları, workflow’ler, job/step yapısı ve genel referanslar.
- Service Containers (Containerized Services) Hakkında — Service container’ların nasıl tanımlandığı ve kullanıldığına dair resmî rehber.
- Workload Identity Federation (OIDC) ile Kimlik Doğrulama — OIDC tabanlı federasyon ve güvenlik odaklı erişim senaryoları için Microsoft dokümantasyonu.
- Azure Blog — Azure tarafındaki güncellemeler, özellik duyuruları ve mimari/operasyonel pratikler için resmî blog.
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.
