GitHub Actions ve CI/CD Otomasyon Rehberi [2026]

GitHub Actions Nedir ve Neden Tercih Edilir?

GitHub Actions, GitHub'ın doğrudan platform içinde sunduğu CI/CD ve otomasyon çözümüdür. 2019'daki ilk çıkışından bu yana hızla olgunlaşan platform, 2026 itibarıyla dünyadaki açık kaynak projelerinin büyük çoğunluğunda ve kurumsal yazılım ekiplerinin önemli bir bölümünde standart CI/CD aracı haline gelmiştir. Kod deposuyla aynı platformda bulunması, yapılandırma karmaşıklığını azaltır ve geliştirici deneyimini iyileştirir.

GitHub Actions'ın öne çıkan avantajları arasında YAML tabanlı deklaratif yapılandırma, 20.000'den fazla hazır action içeren marketplace ekosistemi, matrix build desteğiyle paralel test çalıştırma ve GitHub ekosistemiyle sıfır yapılandırma gerektiren entegrasyon yer alır. Pull request'lerle doğal entegrasyon, kod inceleme süreciyle CI sonuçlarını aynı arayüzde birleştirir ve geliştirici iş akışını kesintisiz hale getirir. Bu rehberde, temel kavramlardan ileri düzey kalıplara kadar GitHub Actions ile CI/CD pipeline tasarımını kapsamlı biçimde ele alacağız.

Workflow Söz Dizimi ve Temel Kavramlar

Trigger Mekanizmaları

GitHub Actions workflow'ları, belirli olaylar (events) tetiklendiğinde çalışır. En yaygın tetikleyiciler push, pull_request ve schedule olaylarıdır. Ancak platform, workflow_dispatch ile manuel tetikleme, repository_dispatch ile API tabanlı tetikleme ve diğer workflow'ların tamamlanmasına bağlı workflow_run tetikleyicisini de destekler. Schedule tetikleyicisi cron söz dizimiyle tanımlanır ve periyodik görevler (gece build'leri, haftalık güvenlik taramaları) için kullanılır.

Olay filtreleri, gereksiz çalışmaları önlemek için kritik öneme sahiptir. Branch filtreleri belirli dallarda, path filtreleri belirli dizinlerdeki değişikliklerde workflow'un tetiklenmesini sağlar. Örneğin, docs dizinindeki değişiklikler için test pipeline'ının çalışmasına gerek yoktur; paths-ignore ile bu tür durumlar kolayca yönetilir. Tag filtreleri, yalnızca sürüm etiketleri oluşturulduğunda release pipeline'ını tetiklemek için kullanılır. Birden fazla tetikleyiciyi bir arada kullanarak hem push hem de pull_request olaylarında farklı davranışlar tanımlamak mümkündür.

Jobs, Steps ve Matrix Builds

Bir workflow bir veya daha fazla job içerir. Her job, varsayılan olarak paralel çalışır ve needs anahtar kelimesiyle bağımlılık zinciri oluşturulabilir. Her job, belirli bir runner üzerinde çalışan steps dizisinden oluşur. Step'ler sıralı olarak çalışır ve bir step'in başarısız olması varsayılan olarak sonraki step'lerin çalışmasını durdurur. continue-on-error ve if koşulları ile bu davranış özelleştirilebilir.

Matrix build stratejisi, tek bir job tanımıyla birden fazla konfigürasyonda test çalıştırmayı sağlar. Node.js 18, 20 ve 22 sürümlerinde, Ubuntu ve macOS platformlarında testlerin paralel olarak çalıştırılması matrix tanımıyla birkaç satırda ifade edilir. fail-fast stratejisi, herhangi bir kombinasyonda hata oluştuğunda diğer çalışmaları durdurmak veya devam ettirmek için yapılandırılabilir. exclude parametresi belirli kombinasyonları matriksten çıkarırken, include parametresi ek kombinasyonlar ekler. Bu esneklik, kapsamlı test matrisleri oluşturmayı son derece kolaylaştırır.

Runner Türleri

GitHub-hosted runner'lar, sıfır yapılandırmayla kullanıma hazır ortamlar sunar. Ubuntu, Windows ve macOS seçenekleri mevcuttur. Her çalışmada temiz bir sanal makine tahsis edilir, bu da izolasyon ve tekrarlanabilirlik sağlar. Larger runner'lar (2-64 vCPU), kaynak yoğun build işlemleri için daha güçlü makineler sunar ve GitHub Teams veya Enterprise planlarında kullanılabilir. ARM tabanlı runner'lar, ARM mimarisi için native derleme yapılması gereken projelerde tercih edilir.

Self-hosted runner'lar, özel donanım gereksinimlerinde veya güvenlik politikaları gereği build sürecinin kendi altyapınızda çalışması gereken durumlarda tercih edilir. GPU gerektiren ML pipeline'ları, iç ağdaki servislere erişim gerektiren entegrasyon testleri ve maliyet optimizasyonu senaryoları, self-hosted runner kullanımını gerekli kılar. Runner gruplaması ve etiketleme, hangi workflow'ların hangi runner'lar üzerinde çalışacağını kontrol eder. Kubernetes üzerinde Actions Runner Controller (ARC) ile otomatik ölçeklenen runner havuzları oluşturmak, kurumsal ortamlarda yaygın bir yaklaşımdır.

Reusable Workflows ve Composite Actions

Reusable Workflows

Tekrar eden pipeline kalıplarını merkezileştirmek için reusable workflow'lar kullanılır. Bir workflow, workflow_call tetikleyicisiyle yeniden kullanılabilir hale getirilir ve inputs ile secrets parametreleri tanımlanarak farklı projelerden çağrılabilir. Bu yaklaşım, organizasyon genelinde standart CI/CD süreçlerini tutarlı biçimde uygulamayı sağlar.

Merkezi bir repository'de tanımlanan build, test ve deploy workflow'ları, onlarca mikro servis reposundan referans edilerek tek noktadan yönetilir. Versiyon sabitleme (@v1, @main) ile workflow değişikliklerinin kontrollü biçimde dağıtılması mümkündür. Bir güvenlik güncellemesi veya yeni bir standart gerektiğinde, merkezi workflow güncellenerek tüm projelere aynı anda yansıtılır. Outputs tanımlayarak reusable workflow'dan çağıran workflow'a veri aktarılması da desteklenir.

Composite Actions

Composite action'lar, birden fazla step'i tek bir action olarak paketler. Reusable workflow'lardan farklı olarak, bir job içinde step düzeyinde çağrılırlar. Ortak setup adımlarını (dil ortamı kurulumu, cache yapılandırması, linting araçlarının yüklenmesi gibi) composite action olarak tanımlamak, workflow dosyalarını sadeleştirir ve DRY prensibini destekler.

action.yml dosyasında inputs, outputs ve runs bölümleri tanımlanır. Composite action'lar, shell komutları ve diğer action'ları bir arada kullanabilir. Bu esneklik, organizasyona özgü build araçlarını standartlaştırmak için idealdir. Marketplace'te yayınlanabilir veya private repository'de internal kullanım için saklanabilir.

Secrets, Ortam Yönetimi ve Deployment

Secret Yönetimi

Hassas bilgiler (API anahtarları, veritabanı şifreleri, deploy token'ları) GitHub Secrets üzerinden yönetilir. Repository, environment ve organization seviyelerinde secret tanımlanabilir. Secrets, workflow loglarında otomatik olarak maskelenir ve fork edilen repository'lerdeki pull request'lerde erişilemez. Organization secrets, birden fazla repository'de ortak kullanılan credential'ları merkezi olarak yönetir.

OIDC (OpenID Connect) federasyonu, uzun ömürlü credential'lar yerine kısa süreli token'lar kullanarak güvenliği önemli ölçüde artırır. AWS, Azure ve GCP, GitHub Actions OIDC provider'ını destekler. Bu sayede bulut sağlayıcılarına erişim için secret saklama ihtiyacı ortadan kalkar ve en az yetki (least-privilege) prensibi daha kolay uygulanır. OIDC token'ı, workflow çalışması boyunca geçerlidir ve otomatik olarak expire olur, bu da credential sızıntısı riskini minimize eder.

Environment ve Deployment Korumaları

GitHub Environments, deployment hedeflerini (staging, production) tanımlar ve her birine koruma kuralları atar. Required reviewers ile production deployment'ı belirlenen kişilerin onayına tabi tutulabilir. Wait timer, deployment'lar arasında zorunlu bekleme süresi tanımlar. Branch protection ile yalnızca belirli dallardan deployment yapılmasını sağlar. Custom deployment protection rules, harici sistemlerden onay alınmasını mümkün kılar.

Deployment stratejisi olarak tipik bir akış, feature branch'ten main'e merge sonrası staging ortamına otomatik deploy, staging'de otomatik smoke testleri ve ardından production'a manuel onaylı deploy biçiminde kurgulanır. Canary ve blue-green deployment kalıpları, environment kurallarıyla birleştirilerek güvenli üretim geçişleri sağlar. Deployment durumu GitHub UI'da izlenebilir ve başarısız deployment'lar otomatik olarak rollback tetikleyebilir.

Caching, Artifact ve Performans Optimizasyonu

Bağımlılık Önbellekleme

Cache action'ı, build sürelerini dramatik biçimde kısaltır. Node.js projelerinde node_modules, Python projelerinde pip cache, Java projelerinde Maven veya Gradle cache'i workflow çalışmaları arasında korunur. Cache anahtarı, bağımlılık dosyasının hash'ine bağlandığında yalnızca bağımlılıklar değiştiğinde cache yenilenir. Restore keys ile kısmi cache eşleşmesi sağlanarak, bağımlılık dosyasında küçük değişiklikler olduğunda bile mevcut cache'ten faydalanılır.

Setup action'ların çoğu yerleşik cache desteğine sahiptir. Örneğin, actions/setup-node@v4 ile cache parametresi npm veya yarn olarak belirtildiğinde ayrıca cache action'ı eklemeye gerek kalmaz. Docker layer caching, container build sürelerini kısaltmak için kullanılır ve docker/build-push-action'ın cache-from ve cache-to parametreleriyle yapılandırılır.

Artifact Yönetimi

Build çıktıları, test raporları ve coverage dosyaları artifact olarak saklanır ve job'lar arasında paylaşılır. Upload-artifact ve download-artifact action'ları bu iş akışını yönetir. Artifact retention süresi varsayılan olarak 90 gündür ancak özelleştirilebilir. V4 artifact action'ları, büyük dosyalar için önemli performans iyileştirmeleri sunar ve immutable artifact desteği ile güvenliği artırır.

Paralel ve Bağımlı Job Tasarımı

Performans optimizasyonunun anahtarı, mümkün olan her yerde paralellik ve akıllı bağımlılık zinciri tasarımıdır. Lint, unit test ve integration test job'ları paralel çalıştırılabilirken, deploy job'u bunların tamamının başarılı olmasına bağlıdır. Concurrency ayarı, aynı branch için birden fazla workflow çalışmasını engelleyerek kaynak israfını önler. cancel-in-progress seçeneği, yeni bir push geldiğinde önceki çalışmayı iptal eder. Timeout ayarları, takılı kalan job'ların kaynakları uzun süre meşgul etmesini engeller.

Güvenlik En İyi Uygulamaları

Token ve İzin Yönetimi

GITHUB_TOKEN varsayılan olarak geniş yetkilerle gelir. Workflow düzeyinde permissions bloğu tanımlayarak en az yetki prensibini uygulamak kritik bir güvenlik adımıdır. Yalnızca ihtiyaç duyulan izinleri (contents: read, pull-requests: write gibi) açıkça belirtmek, olası güvenlik açıklarının etkisini sınırlar. Organization düzeyinde varsayılan token izinlerini read-only olarak ayarlamak, güvenlik temelini güçlendirir.

Üçüncü parti action'lar kullanılırken tag yerine commit SHA ile sabitleme yapılmalıdır. Bu, supply chain saldırılarına karşı koruma sağlar. Bir action'ın maintainer'ı, mevcut tag'ı kötü amaçlı koda işaret edecek şekilde değiştirebilir; SHA sabitleme bu riski ortadan kaldırır. Dependabot, action sürümlerini otomatik olarak güncelleyerek güvenlik yamalarının zamanında uygulanmasını destekler. GitHub'ın code scanning ve secret scanning özellikleri, workflow dosyalarındaki güvenlik sorunlarını da tespit eder.

Fork ve Pull Request Güvenliği

Public repository'lerde fork'lardan gelen pull request'ler, özel dikkat gerektirir. pull_request_target tetikleyicisinin yanlış kullanımı, secret sızıntısına yol açabilir. Bu tetikleyici, fork PR'ının kodunu base repository'nin bağlamında çalıştırır ve secret'lara erişim sağlar. Güvenli yaklaşım, fork PR'larında yalnızca güvenilir action'ları çalıştırmak ve hassas işlemleri ayrı bir onay mekanizmasına tabi tutmaktır. Script injection saldırılarına karşı, kullanıcı girdilerini (PR başlığı, commit mesajı) doğrudan shell komutlarında kullanmaktan kaçınılmalıdır.

Monorepo CI Kalıpları

Birden fazla servis veya paketin aynı repository'de bulunduğu monorepo yapılarında, path filtreleri kritik öneme sahiptir. Yalnızca değişen servisin pipeline'ının çalışması, hem zaman hem maliyet açısından büyük tasarruf sağlar. dorny/paths-filter action'ı, değişen dosyalara göre koşullu job çalıştırmayı kolaylaştırır ve çıktıları boolean değerler olarak sonraki job'lara iletir.

Ortak kütüphane değişikliklerinde bağımlı tüm servislerin testlerinin tetiklenmesi gerekir. Bu, dependency graph analizi ve akıllı tetikleme mekanizmalarıyla yönetilir. Turborepo veya Nx gibi monorepo araçları, GitHub Actions ile entegre çalışarak yalnızca etkilenen projeleri build ve test eder. Remote caching ile bir geliştiricinin yerel ortamında oluşturulan cache, CI ortamında da kullanılabilir hale gelir.

Bulut Sağlayıcı Entegrasyonları

AWS Entegrasyonu

AWS ile entegrasyon için configure-aws-credentials action'ı ve OIDC federasyonu kullanılır. ECS deployment, Lambda function güncelleme, S3 sync ve CloudFront invalidation gibi yaygın senaryolar için hazır action'lar mevcuttur. CDK veya Terraform ile altyapı değişiklikleri de CI/CD pipeline'ına dahil edilir. ECR'a Docker image push, EKS'e Helm chart deployment ve CodeDeploy ile rolling update gibi senaryolar, birkaç satırlık workflow tanımıyla otomatikleştirilir.

Azure ve GCP Entegrasyonu

Azure için azure/login action'ı ve federated credentials, GCP için google-github-actions/auth ve Workload Identity Federation kullanılır. Multi-cloud senaryolarda, environment bazlı secret yönetimi ve koşullu deployment adımları ile farklı bulut sağlayıcılarına tek bir pipeline'dan deploy yapılabilir. Smart Maple'da CI/CD pipeline tasarımında projenin ölçeğine, ekip yapısına ve mevcut altyapıya göre en uygun aracın seçilmesini öneriyoruz.

Maliyet Optimizasyonu

GitHub Actions, public repository'ler için ücretsizdir. Private repository'lerde ise plan bazlı dakika kotaları uygulanır ve fazla kullanım ücretlendirilir. Maliyet optimizasyonu için dikkat edilmesi gereken birkaç temel nokta vardır.

Runner seçimi maliyeti doğrudan etkiler. Linux runner'lar, Windows runner'lara göre iki kat, macOS runner'lara göre on kat daha ucuzdur. Self-hosted runner'lar, yoğun kullanım senaryolarında maliyet avantajı sağlayabilir ancak bakım maliyeti hesaba katılmalıdır. Cache stratejisi, build sürelerini kısaltarak dakika tüketimini azaltır. Akıllı tetikleme, gereksiz workflow çalışmalarını path ve branch filtreleriyle engeller. Concurrency yönetimi, tekrarlayan çalışmaları iptal ederek israfı önler. Workflow run loglarının düzenli analizi, optimizasyon fırsatlarını ortaya çıkarır.

GitLab CI, Jenkins ve CircleCI ile Karşılaştırma

GitHub Actions, GitLab CI ile benzer YAML tabanlı yapılandırma sunar ancak marketplace ekosistemi çok daha geniştir. GitLab CI'ın avantajı, yerleşik container registry, Auto DevOps özellikleri ve merge train desteğidir. Jenkins, esneklik ve plugin ekosistemi açısından güçlüdür fakat bakım maliyeti, yapılandırma karmaşıklığı ve güvenlik güncellemeleri dezavantajdır. CircleCI, performans optimizasyonu, Docker layer caching ve orb ekosistemiyle öne çıkar ancak GitHub dışı bir platform olması ek entegrasyon gerektirir.

Seçim yaparken ekibin GitHub kullanım yoğunluğu, mevcut CI/CD altyapısı, güvenlik gereksinimleri ve bütçe gibi faktörler değerlendirilmelidir. GitHub Actions, GitHub ekosistemini aktif kullanan ekipler için çoğu durumda en verimli seçenektir.

İleri Düzey Kalıplar

Container Tabanlı Job'lar

Job'lar, belirli bir Docker container içinde çalıştırılabilir. Bu, build ortamının tam olarak kontrol edilmesini ve tekrarlanabilirliğini sağlar. Service container'lar, test sırasında PostgreSQL, Redis veya Elasticsearch gibi bağımlılıkları geçici olarak ayağa kaldırır ve health check ile hazır olduklarından emin olunur. Container registry ile entegrasyon, özel build image'larının kullanılmasına olanak tanır ve bu image'lar da CI pipeline ile güncel tutulabilir.

Dinamik Matrix ve Workflow Oluşturma

Matrix değerleri, önceki bir job'un çıktısından dinamik olarak üretilebilir. Bu, monorepo'da değişen servislerin listesini çıkarıp yalnızca onlar için build job'u oluşturmak gibi senaryolarda kullanılır. fromJSON fonksiyonu, dinamik matrix oluşturmayı mümkün kılar. Bu kalıp, ölçeklenebilir ve bakımı kolay pipeline'lar tasarlamak için son derece güçlü bir araçtır.

CI/CD pipeline tasarımı hakkında daha detaylı bilgi için CI/CD Pipeline Kurulumu ve versiyon kontrol stratejileri için Git Versiyon Kontrol Stratejileri yazılarımıza göz atabilirsiniz.

Sonuç

GitHub Actions, modern yazılım geliştirme süreçlerinde CI/CD otomasyonunu erişilebilir ve güçlü bir şekilde sunan bir platformdur. Workflow söz diziminin öğrenilmesi, güvenlik en iyi uygulamalarının benimsenmesi ve maliyet optimizasyonunun yapılması, platformdan maksimum verim almanın temel adımlarıdır. Reusable workflow'lar ve composite action'lar ile organizasyon genelinde standart pipeline kalıpları oluşturmak, uzun vadede hem tutarlılık hem de bakım kolaylığı sağlar.

Başarılı bir CI/CD stratejisi, araç seçiminin ötesinde kültürel bir dönüşümü de gerektirir. Küçük ve sık deployment'lar, otomatik testlere güven ve hızlı geri bildirim döngüleri, GitHub Actions'ın teknik yetenekleriyle birleştiğinde gerçek anlamda sürekli teslimat kültürünü mümkün kılar.