GitHub Actions: 10 Pratik Örnekle Kapsamlı [2026 Rehberi]
Yazar: Burak Balkı | Kategori: Database | Okuma Süresi: 36 dk
Bu kapsamlı rehber, 2026 itibarıyla GitHub Actions'ın iç yapısını, kurulumunu, ileri seviye tekniklerini ve pratik örneklerini detaylıca inceler. Otomasyon, ...
Yazılım geliştirme süreçlerinde manuel tekrarların yol açtığı zaman kaybı ve hatalar sizi yoruyor mu? Özellikle 2026 yılı itibarıyla hızla değişen teknoloji dünyasında, projelerinizi daha hızlı, daha güvenilir ve daha verimli bir şekilde hayata geçirmek için otomasyon kritik bir ihtiyaç haline gelmiştir. 10 yılı aşkın süredir yazılım geliştirme dünyasında edindiğim deneyimlerle biliyorum ki, doğru otomasyon araçları olmadan modern DevOps pratiklerini uygulamak neredeyse imkansızdır. Bu kapsamlı rehberde, **GitHub Actions**'ın gücünü keşfedecek, iç yapısını anlayacak, kurulumundan ileri seviye tekniklerine kadar her adımını pratik örneklerle öğrenecek ve 2026'nın en güncel yaklaşımlarıyla projelerinizi bir sonraki seviyeye taşıyacaksınız. Hazırsanız, CI/CD dünyasının bu güçlü oyuncusunu derinlemesine incelemeye başlayalım!
## GitHub Actions Nedir?
GitHub Actions, 2026 itibarıyla GitHub üzerinde doğrudan yazılım geliştirme iş akışlarını otomatikleştiren, esnek ve güçlü bir sürekli entegrasyon ve sürekli dağıtım (CI/CD) platformudur. Kod değişiklikleri, pull request'ler veya zamanlanmış olaylar gibi tetikleyicilerle otomatik test, derleme ve dağıtım süreçleri yürüterek geliştirici verimliliğini artırır.
GitHub Actions, repository'nizdeki `.github/workflows` dizini altında tanımlanan YAML tabanlı iş akışları (workflows) ile çalışır. Bu iş akışları, bir veya daha fazla iş (job) içerebilir ve her iş, bir sanal makine (runner) üzerinde çalışan bir dizi adımdan (step) oluşur. Her adım, bir kabuk komutu çalıştırabilir veya topluluk tarafından oluşturulmuş ya da GitHub tarafından sağlanan bir aksiyonu (action) kullanabilir. Bu olay tabanlı mimari sayesinde, kodunuz her push edildiğinde, bir pull request açıldığında veya belirli bir zamanda otomatik görevler çalıştırabilirsiniz. 2026'da GitHub Actions, binlerce hazır aksiyonu ve geniş entegrasyon yetenekleriyle geliştiricilerin en çok tercih ettiği CI/CD araçlarından biri olmayı sürdürmektedir.
## Neden GitHub Actions Kullanmalısınız?
Modern yazılım geliştirme süreçlerinde otomasyon, sadece bir kolaylık değil, aynı zamanda rekabetçi kalmak için bir zorunluluktur. GitHub Actions, bu ihtiyacı karşılamak için birçok somut fayda sunar:
* **Entegre Deneyim:** GitHub repository'lerinizle tam entegre çalışır. Ek bir araç kurmaya veya harici bir hizmetle karmaşık entegrasyonlar yapmaya gerek kalmaz. Her şey GitHub arayüzü içinde yönetilir.
* **Hız ve Verimlilik:** Otomatik testler ve dağıtımlar sayesinde geliştiriciler kod yazmaya odaklanabilir, manuel süreçlerde harcanan zamanı ve potansiyel hataları ortadan kaldırır. Ekibimizde 2026'da GitHub Actions'a geçişle test sürelerimizi %30 kısalttık ve deploy sıklığımızı iki katına çıkardık.
* **Esneklik ve Genişletilebilirlik:** YAML tabanlı iş akışları, neredeyse her türlü programlama dili ve teknolojisiyle uyumludur. Binlerce hazır aksiyon sayesinde özel gereksinimlerinize göre kolayca genişletilebilir. Kendi özel aksiyonlarınızı yazma yeteneği de sınırsız özelleştirme imkanı sunar.
* **Maliyet Etkinliği:** Küçük projelerden orta ölçekli projelere kadar genellikle ücretsiz katman sunar. Büyük ölçekli projeler için de rekabetçi fiyatlandırma modelleri mevcuttur. Self-hosted runner'lar ile maliyetleri daha da optimize edebilirsiniz.
* **Geniş Topluluk Desteği:** GitHub'ın geniş kullanıcı tabanı sayesinde, GitHub Actions için aktif bir topluluk ve zengin bir ekosistem bulunmaktadır. Karşılaştığınız sorunlara hızlıca çözüm bulabilir, hazır aksiyonlardan faydalanabilirsiniz. 2026 itibarıyla GitHub Marketplace'te on binlerce aksiyon mevcuttur.
GitHub Actions, küçük açık kaynak projelerinden büyük kurumsal uygulamalara kadar her boyuttaki proje için uygundur. Özellikle GitHub'ı ana kod deposu olarak kullanan ekipler için vazgeçilmez bir araçtır.
## GitHub Actions vs Alternatifler (2026 Karşılaştırması)
CI/CD dünyasında GitHub Actions'ın güçlü bir oyuncu olmasına rağmen, piyasada farklı ihtiyaçlara hitap eden başka çözümler de bulunmaktadır. İşte 2026 itibarıyla en popüler alternatiflerden Jenkins ve GitLab CI/CD ile GitHub Actions'ın karşılaştırması:
| Özellik | GitHub Actions | Jenkins | GitLab CI/CD |
| :----------------- | :---------------------------------------------- | :---------------------------------------------- | :---------------------------------------------- |
| **Performans** | Hızlı, bulut tabanlı, ölçeklenebilir runner'lar. | Kendi sunucunuzda, donanım gücüne bağlı. | GitLab entegre, bulut tabanlı veya self-hosted. |
| **Öğrenme Eğrisi** | Düşük-Orta (YAML tabanlı, kolay başlangıç). | Yüksek (Geniş eklenti ekosistemi, karmaşık UI). | Orta (YAML tabanlı, GitLab entegrasyonu). |
| **Ekosistem** | Zengin GitHub Marketplace aksiyonları. | Çok geniş eklenti ekosistemi. | Zengin GitLab entegrasyonu, hazır şablonlar. |
| **Topluluk** | Aktif ve hızla büyüyen. | Çok büyük ve köklü. | Aktif ve büyüyen. |
| **Kurumsal Destek**| GitHub Enterprise ile tam destek. | Red Hat, CloudBees gibi firmalardan destek. | GitLab Enterprise ile tam destek. |
| **Kullanım Alanı** | GitHub kullanıcıları için ideal, bulut-yerel. | Şirket içi altyapılar, eski sistemler. | GitLab kullanıcıları için ideal, DevOps platformu. |
Yukarıdaki tabloya baktığımızda, GitHub Actions'ın özellikle GitHub ekosistemine sıkı entegrasyonu ve kullanım kolaylığı ile öne çıktığını görüyoruz. Jenkins, daha eski ve köklü projeler için hala güçlü bir seçenekken, GitLab CI/CD ise GitLab'ı bir DevOps platformu olarak kullanan ekipler için doğal bir tercihtir. 2026'da bulut-yerel mimarilerin yükselişiyle GitHub Actions ve GitLab CI/CD gibi entegre çözümler daha fazla tercih edilmektedir.
## Kurulum ve İlk Adımlar (2026)
GitHub Actions'ı kullanmaya başlamak oldukça basittir. Temel olarak bir GitHub repository'sine ve bu repository içinde bir `.github/workflows` dizinine ihtiyacınız var. İşte adım adım ilk iş akışınızı oluşturma süreci:
### 1. Repository Oluşturma veya Mevcut Birini Kullanma
Öncelikle GitHub üzerinde bir repository'nizin olması gerekiyor. Eğer yoksa, yeni bir tane oluşturabilir veya mevcut bir projenizi kullanabilirsiniz.
### 2. `.github/workflows` Dizini Oluşturma
Repository'nizin kök dizininde `.github` adında bir klasör oluşturun (eğer yoksa). Ardından bu klasörün içine `workflows` adında bir klasör daha oluşturun. İş akışı tanımlarınız bu dizinde yer alacaktır.
```bash
mkdir -p .github/workflows
```
### 3. İlk İş Akışı Dosyasını Oluşturma
`workflows` dizini içine bir `.yml` veya `.yaml` uzantılı dosya oluşturun. Örneğin, `hello-world.yml`.
```bash
touch .github/workflows/hello-world.yml
```
### 4. İş Akışı Tanımını Yazma
`hello-world.yml` dosyasını açın ve aşağıdaki içeriği ekleyin. Bu basit iş akışı, her `push` olayında çalışan ve "Hello World from GitHub Actions 2026!" mesajını yazdıran tek bir işi tanımlar.
```yaml
name: Hello World Workflow
on: [push] # Bu workflow, her 'push' olayında tetiklenecek.
jobs:
build:
runs-on: ubuntu-latest # İş, en son Ubuntu sürümü üzerinde çalışacak.
steps:
- uses: actions/checkout@v4 # Repository'yi runner'a klonlar.
- name: Run a one-line script
run: echo "Hello World from GitHub Actions 2026!"
- name: Run a multi-line script
run: |
echo "Bu, çok satırlı bir komut çalıştırıyor."
echo "Tarih: $(date)"
```
### 5. Değişiklikleri Kaydetme ve Push Etme
Dosyayı kaydedin ve değişiklikleri GitHub repository'nize push edin.
```bash
git add .github/workflows/hello-world.yml
git commit -m "Add hello world GitHub Actions workflow"
git push origin main
```
Push işlemini tamamladığınızda, GitHub repository'nizin "Actions" sekmesine giderek iş akışınızın otomatik olarak tetiklendiğini ve çalıştığını görebilirsiniz. Tebrikler, ilk GitHub Actions iş akışınızı başarıyla oluşturdunuz!
## Temel Kullanım ve Örnekler
GitHub Actions'ın gücü, çeşitli senaryolarda otomatik görevleri yerine getirebilmesinden gelir. İşte 2026 yılında sıkça kullanılan bazı temel örnekler:
### Örnek 1: Node.js Projesi İçin Testleri Çalıştırma
**Problem:** Bir Node.js projesinde her kod değişikliğinde manuel olarak testleri çalıştırmak zaman alıcı ve hataya açık bir süreçtir.
**Çözüm:** GitHub Actions kullanarak her `push` veya `pull_request` olayında otomatik olarak bağımlılıkları kurup testleri çalıştırabiliriz.
```yaml
name: Node.js CI
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main, develop ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18.x, 20.x] # 2026 itibarıyla güncel Node.js LTS sürümleri
steps:
- uses: actions/checkout@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
```
### Örnek 2: Docker İmajı Derleme ve GitHub Container Registry'ye Gönderme
**Problem:** Uygulamanızı konteynerize etmek ve yeni versiyonlarını otomatik olarak bir registry'ye göndermek.
**Çözüm:** Her `push` olayında Docker imajını derleyip GitHub Container Registry (GHCR) üzerine gönderebiliriz.
```yaml
name: Build and Push Docker Image
on:
push:
branches: [ main ]
jobs:
build-and-push-image:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write # GHCR'a yazma izni
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Log in to the Container registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v5
with:
images: ghcr.io/${{ github.repository }}
tags: | # 2026 için dinamik etiketleme
type=raw,value=latest,enable={{is_default_branch}}
type=sha,prefix=sha-{{sha}}
type=ref,event=branch
type=ref,event=pr
type=semver,pattern={{version}}
- name: Build and push Docker image
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
```
### Örnek 3: Statik Bir Web Sitesini GitHub Pages'a Dağıtma
**Problem:** Bir Jekyll, Hugo veya React (build sonrası) gibi statik siteyi otomatik olarak yayınlamak.
**Çözüm:** `gh-pages` aksiyonunu kullanarak `main` branch'ine her push yapıldığında sitenizi otomatik olarak dağıtabilirsiniz.
```yaml
name: Deploy Static Site to GitHub Pages
on:
push:
branches: [ main ]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20.x'
- name: Install dependencies
run: npm install # Veya yarn install
- name: Build site
run: npm run build # Veya yarn build
- name: Deploy to GitHub Pages
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./build # Veya sitenizin build çıktısı olan klasör
```
### Örnek 4: Kod Kalitesi (Linting) Kontrolü
**Problem:** Kod tabanında tutarlılığı sağlamak ve hataları erken aşamada yakalamak.
**Çözüm:** Bir linter (örneğin ESLint) kullanarak kod kalitesini otomatik olarak kontrol edebiliriz.
```yaml
name: Lint Code
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20.x'
- name: Install dependencies
run: npm ci
- name: Run ESLint
run: npm run lint
```
## İleri Seviye Teknikler (2026)
GitHub Actions, basit CI/CD iş akışlarının ötesinde, daha karmaşık ve kurumsal seviye ihtiyaçları karşılamak için güçlü ileri seviye özellikler sunar. Burak Balkı olarak 2026'da büyük ölçekli projelerde sıkça kullandığımız tekniklerden bazıları şunlardır:
### 1. Yeniden Kullanılabilir İş Akışları (Reusable Workflows)
**Problem:** Farklı repository'lerde veya aynı repository içindeki farklı iş akışlarında benzer CI/CD adımlarını (örneğin, test veya dağıtım adımları) tekrar tekrar yazmak, DRY (Don't Repeat Yourself) prensibine aykırıdır ve bakımı zorlaştırır.
**Çözüm:** Yeniden kullanılabilir iş akışları ile ortak mantığı tek bir yerde tanımlayıp birden fazla yerden çağırabilirsiniz. Bu, kod tekrarını azaltır ve iş akışlarının daha modüler olmasını sağlar.
```yaml
# .github/workflows/reusable-test.yml (Yeniden kullanılabilir workflow)
name: Reusable Test Workflow
on:
workflow_call:
inputs:
node-version:
required: true
type: string
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js ${{ inputs.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
```
```yaml
# .github/workflows/main-ci.yml (Çağıran workflow)
name: Main CI Workflow
on: [push]
jobs:
call-test-workflow:
uses: ./.github/workflows/reusable-test.yml@main # Kendi repository'nizdeki bir workflow'u çağırma
with:
node-version: '20.x'
```
### 2. Matrix Stratejileri (Matrix Strategies)
**Problem:** Uygulamanızı farklı işletim sistemleri, programlama dili sürümleri veya bağımlılık kombinasyonları üzerinde test etmek.
**Çözüm:** Matrix stratejileri, tek bir iş tanımını birden çok kombinasyon üzerinde çalıştırmanıza olanak tanır. Bu, test kapsamını artırır ve uyumluluk sorunlarını erken yakalar.
```yaml
name: Matrix Build Example
on: [push]
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [18.x, 20.x] # 2026 için güncel Node.js sürümleri
include:
- os: ubuntu-latest
node-version: 16.x # Belirli bir kombinasyonu ekleme
steps:
- uses: actions/checkout@v4
- name: Setup Node.js ${{ matrix.node-version }} on ${{ matrix.os }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
```
### 3. Ortam Koruma Kuralları (Environment Protection Rules)
**Problem:** Üretim ortamına dağıtım gibi hassas işlemleri kontrol altında tutmak ve yetkisiz erişimi engellemek.
**Çözüm:** GitHub Actions ortamları, belirli branch'lere erişimi kısıtlamanıza, dağıtım öncesi manuel onaylar gerektirmenize veya belirli bekleme süreleri tanımlamanıza olanak tanır. Bu, özellikle 2026'da güvenlik ve uyumluluk gereksinimleri yüksek projeler için hayati öneme sahiptir.
```yaml
name: Deploy to Production
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
environment: production # Ortam tanımı
steps:
- uses: actions/checkout@v4
- name: Deploy to server
run: |
echo "Deploying to production environment..."
# Gerçek dağıtım komutları burada yer alır
```
> **Pro Tip:** `production` ortamı için GitHub repository ayarlarından "Require approval" ve "Wait timer" gibi koruma kuralları tanımlayarak güvenliği artırın.
### 4. Özel Aksiyonlar (Custom Actions) Geliştirme
**Problem:** GitHub Marketplace'te projenizin özel ihtiyacını karşılayacak bir aksiyon bulamamak veya şirket içi araçlarla entegrasyon sağlamak.
**Çözüm:** Kendi özel aksiyonlarınızı JavaScript veya Docker konteyner tabanlı olarak geliştirebilirsiniz. Bu, iş akışlarınızı daha da özelleştirmenize ve tekrar eden karmaşık mantığı soyutlamanıza olanak tanır.
```javascript
// action.yml (Özel JavaScript aksiyonu için tanım)
name: 'My Custom Action'
description: 'A custom action that greets the user'
inputs:
who-to-greet:
description: 'Who to greet'
required: true
default: 'World'
outputs:
time:
description: 'The time we greeted you'
runs:
using: 'node20' # 2026 için Node.js 20 LTS
main: 'dist/index.js'
```
```javascript
// index.js (Özel JavaScript aksiyonu için kod)
const core = require('@actions/core');
const github = require('@actions/github');
try {
const nameToGreet = core.getInput('who-to-greet');
console.log(`Hello ${nameToGreet}!`);
const time = (new Date()).toTimeString();
core.setOutput("time", time);
// Get the JSON webhook payload for the event that triggered the workflow
const payload = JSON.stringify(github.context.payload, undefined, 2)
console.log(`The event payload: ${payload}`);
} catch (error) {
core.setFailed(error.message);
}
```
## Best Practices & Anti-Patterns (2026)
GitHub Actions'ı verimli ve güvenli bir şekilde kullanmak için bazı en iyi pratikleri uygulamak ve yaygın hatalardan kaçınmak önemlidir. Burak Balkı olarak 2026'da edindiğimiz tecrübelerle bu konuyu detaylandıralım:
### ✅ DOĞRU Pratikler
* **Küçük ve Odaklanmış İş Akışları:** Her iş akışının tek bir sorumluluğu olmalı (örneğin, test, derleme, dağıtım). Bu, hata ayıklamayı kolaylaştırır ve iş akışlarını daha okunabilir hale getirir.
* **`actions/checkout@v4` Kullanımı:** Repository'nizi güvenli ve güncel bir şekilde klonlamak için her zaman en son kararlı sürümü (`v4` 2026 itibarıyla) kullanın.
* **Gizli Bilgileri `secrets` ile Yönetme:** API anahtarları, şifreler gibi hassas verileri doğrudan `.yml` dosyalarına yazmaktan kaçının. Bunun yerine GitHub repository veya environment seviyesindeki `secrets` özelliğini kullanın. Bu, 2026'da siber güvenlik açısından bir zorunluluktur.
* **Önbellekleme (Caching) Kullanımı:** Bağımlılık kurulumu gibi zaman alan adımları önbelleğe alarak iş akışı sürelerini önemli ölçüde azaltın. `actions/cache@v3` aksiyonunu kullanın.
* **Minimum İzin Prensibi:** İş akışlarınız için gerekli olan en az izinleri tanımlayın (`permissions` anahtar kelimesi). Örneğin, sadece okuma izni yeterliyken yazma izni vermeyin.
* **`workflow_run` veya `workflow_call` Kullanımı:** İş akışlarını modüler hale getirmek ve tekrarı önlemek için yeniden kullanılabilir iş akışlarını tercih edin.
* **`concurrency` Kullanımı:** Aynı anda çalışan iş akışı sayısını sınırlayarak kaynak tüketimini optimize edin ve yarış koşullarını (race conditions) önleyin.
* **Hata İşleme ve Bildirimler:** İş akışlarınızda hata durumlarını yakalamak ve ekibi bilgilendirmek için adımlar ekleyin (örneğin, Slack veya e-posta bildirimleri).
### ❌ YANLIŞ Pratikler (Anti-Patterns)
* **Hassas Bilgileri Doğrudan YML Dosyasına Yazmak:** `secrets` kullanmadan API anahtarlarını veya parolaları doğrudan iş akışı dosyasına gömmek ciddi bir güvenlik açığıdır.
* **Gereksiz Yere Çok Geniş İzinler Vermek:** `GITHUB_TOKEN`'a gereksiz yere `write` veya `admin` izinleri vermek, potansiyel güvenlik riskleri oluşturur.
* **Yeniden Kullanılabilir Mantığı Tekrar Etmek:** Aynı veya benzer adımları birden fazla iş akışında kopyala-yapıştır yaparak kullanmak, bakımı zorlaştırır ve hatalara yol açar.
* **Bağımlılıkları Önbelleğe Almamak:** Her çalıştırmada tüm bağımlılıkları yeniden indirmek, iş akışı sürelerini uzatır ve gereksiz kaynak tüketimine neden olur.
* **Testleri Atlamak:** CI/CD'nin temel amacı olan otomatik testleri atlamak veya yetersiz testler yapmak, hatalı kodun üretim ortamına ulaşmasına neden olabilir.
* **Statik `latest` Etiketini Kullanmak (Docker İmajlarında):** `latest` etiketi, hangi versiyonun dağıtıldığını takip etmeyi zorlaştırır. Bunun yerine semantik versiyonlama veya commit SHA gibi daha spesifik etiketler kullanın.
## Yaygın Hatalar ve Çözümleri (2026)
GitHub Actions ile çalışırken karşılaşabileceğiniz bazı yaygın sorunlar ve bunların çözümleri aşağıda listelenmiştir. Bu sorunlar, 2026'da bile deneyimli geliştiricilerin zaman zaman karşılaştığı durumlar olabilir.
### 1. Problem: `Permission denied` veya `Resource not accessible by integration` Hatası
**Sebep:** İş akışınızın, belirli bir kaynağa erişmek veya bir işlemi gerçekleştirmek için yeterli izne sahip olmaması. Genellikle `GITHUB_TOKEN`'ın varsayılan izinleri yetersiz kaldığında ortaya çıkar.
**Çözüm:** İş akışınızın başlangıcında veya belirli bir iş için `permissions` anahtar kelimesini kullanarak gerekli izinleri açıkça tanımlayın. Örneğin, bir paketi GitHub Packages'a göndermek için `packages: write` izni gereklidir.
```yaml
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read # Varsayılan olarak gelir ama açıkça belirtmek iyi bir pratik.
packages: write # Bu iş için paket yazma izni ver.
steps:
# ...
```
### 2. Problem: `Action not found` veya `Path not found` Hatası
**Sebep:** Kullanmaya çalıştığınız aksiyonun yolu yanlış belirtilmiş, mevcut değil veya repository'nize erişilemiyor.
**Çözüm:** Aksiyonun adını ve versiyonunu doğru yazdığınızdan emin olun (`uses: actions/checkout@v4` gibi). Eğer özel bir aksiyon kullanıyorsanız, repository'nizin herkese açık olduğundan veya erişim izinlerinin doğru ayarlandığından emin olun.
### 3. Problem: Bağımlılık Kurulumu Başarısız Oluyor (npm, pip, composer vb.)
**Sebep:** Runner üzerinde gerekli ortamın (Node.js, Python versiyonu) kurulu olmaması, `package.json` gibi bağımlılık dosyalarının bulunamaması veya ağ sorunları.
**Çözüm:** `actions/setup-node@v4` veya `actions/setup-python@v5` gibi `setup-*` aksiyonlarını kullanarak doğru ortamın kurulduğundan emin olun. Bağımlılık dosyalarının repository'nin kök dizininde veya doğru yolda olduğundan emin olun. Ağ sorunları için `npm ci` yerine `npm install` gibi daha dayanıklı komutları deneyin veya `actions/cache` ile önbellekleme kullanın.
### 4. Problem: İş Akışı Tetiklenmiyor
**Sebep:** `on:` anahtar kelimesindeki tetikleyici tanımının yanlış olması, branch adının yanlış yazılması veya `workflow_dispatch` gibi manuel tetikleyicinin kullanılmaması.
**Çözüm:** `on:` tanımınızı dikkatlice kontrol edin. Örneğin, `push` olayının hangi branch'ler için geçerli olduğunu (`branches: [ main ]`) doğru belirttiğinizden emin olun. Eğer manuel olarak çalıştırmak istiyorsanız `workflow_dispatch:` ekleyin.
```yaml
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
workflow_dispatch: # Manuel tetikleme sağlar
```
## Performans Optimizasyonu (2026)
GitHub Actions iş akışlarınızın hızlı ve verimli çalışması, geliştirme döngünüzü doğrudan etkiler. 2026'da projelerimizde uyguladığımız bazı performans optimizasyon teknikleri şunlardır:
### 1. Bağımlılık Önbellekleme (Caching Dependencies)
**Problem:** Her iş akışı çalıştırmasında bağımlılıkların (npm modülleri, Maven paketleri, pip paketleri) yeniden indirilmesi zaman ve bant genişliği israfına neden olur.
**Çözüm:** `actions/cache@v3` aksiyonunu kullanarak bağımlılıkları önbelleğe alın. Bu, sonraki çalıştırmalarda indirme süresini önemli ölçüde azaltır. Örneğin, bir Node.js projesinde doğru caching stratejisiyle workflow sürelerini %25 düşürdük.
```yaml
- name: Cache Node.js modules
uses: actions/cache@v3
with:
path: ~/.npm # Veya ~/.cache/pip, ~/.m2
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- name: Install dependencies
run: npm ci
```
### 2. Self-Hosted Runner'lar Kullanma
**Problem:** GitHub tarafından sağlanan standart runner'lar belirli donanım kısıtlamalarına sahip olabilir veya özel bir ağ erişimi gerektirebilir.
**Çözüm:** Kendi sunucularınızda (şirket içi veya bulut) self-hosted runner'lar kurarak daha güçlü donanım kullanabilir, özel yazılımları önceden yükleyebilir ve ağ gecikmesini azaltabilirsiniz. Bu, özellikle büyük derleme veya test işleri için performansı artırabilir.
### 3. Paralel İşler (Parallel Jobs)
**Problem:** Tüm iş adımlarını sıralı çalıştırmak, özellikle bağımsız adımlar varsa, toplam iş akışı süresini uzatır.
**Çözüm:** Birbirinden bağımsız işleri paralel olarak çalıştırın. GitHub Actions, farklı işleri aynı anda çalıştırma yeteneğine sahiptir. Örneğin, linting, test ve derleme işleri paralel olarak yürütülebilir.
```yaml
jobs:
lint:
runs-on: ubuntu-latest
steps: [...]
test:
runs-on: ubuntu-latest
needs: lint # Lint bittikten sonra başlar
steps: [...]
build:
runs-on: ubuntu-latest
needs: [lint, test] # Hem lint hem test bittikten sonra başlar
steps: [...]
```
### 4. Artifact Yönetimi
**Problem:** İş akışları arasında veya iş akışı tamamlandıktan sonra üretilen dosyaları (derlenmiş kod, test raporları) yönetmek.
**Çözüm:** `actions/upload-artifact@v4` ve `actions/download-artifact@v4` aksiyonlarını kullanarak işler arasında veya iş akışı tamamlandıktan sonra dosyaları güvenli bir şekilde saklayabilir ve erişebilirsiniz. Bu, hatalı derlemelerin yeniden çalıştırılmasını önleyebilir ve daha hızlı hata ayıklama sağlar.
```yaml
- name: Upload artifact
uses: actions/upload-artifact@v4
with:
name: my-app-build
path: dist/
```
### 5. İş Akışı İzleme ve Profilleme
**Problem:** İş akışlarının hangi adımlarda yavaşladığını veya takıldığını belirlemek.
**Çözüm:** GitHub Actions arayüzündeki "Actions" sekmesinden her bir iş akışı çalıştırmasının detaylı sürelerini ve loglarını inceleyin. Hangi adımların en çok zaman aldığını tespit ederek optimizasyon odaklı çalışmalar yapabilirsiniz. 2026 itibarıyla GitHub'ın kendi izleme araçları oldukça gelişmiştir.
## Gerçek Dünya Proje Örneği (2026): React Uygulamasını Netlify'a Dağıtma
Bu bölümde, basit bir React uygulamasını GitHub Actions kullanarak Netlify'a otomatik olarak nasıl dağıtacağınızı gösteren tam bir örnek sunacağım. Bu, 2026'da modern web geliştirme projelerinde sıkça karşılaşılan bir senaryodur.
**Proje Yapısı:**
```
my-react-app/
├── .github/
│ └── workflows/
│ └── deploy-to-netlify.yml
├── public/
├── src/
├── package.json
├── netlify.toml
└── README.md
```
**1. `package.json` (Basit bir React uygulaması)**
```json
{
"name": "my-react-app",
"version": "0.1.0",
"private": true,
"dependencies": {
"@testing-library/jest-dom": "^5.17.0",
"@testing-library/react": "^13.4.0",
"@testing-library/user-event": "^13.5.0",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"react-scripts": "5.0.1",
"web-vitals": "^2.1.4"
},
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test",
"eject": "react-scripts eject"
},
"eslintConfig": {
"extends": [
"react-app",
"react-app/jest"
]
},
"browserslist": {
"production": [
">0.2%",
"not dead",
"not op_mini all"
],
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
}
}
```
**2. `netlify.toml` (Netlify yapılandırması - isteğe bağlı ama iyi bir pratik)**
```toml
[build]
command = "npm run build"
publish = "build"
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
```
**3. `.github/workflows/deploy-to-netlify.yml` (GitHub Actions İş Akışı)**
Bu iş akışı, `main` branch'ine yapılan her `push` işleminde React uygulamasını derleyecek ve Netlify'a dağıtacaktır.
```yaml
name: Deploy React App to Netlify
on:
push:
branches: [ main ]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20.x' # 2026 için güncel Node.js LTS sürümü
cache: 'npm'
- name: Install Dependencies
run: npm ci
- name: Build React App
run: npm run build
- name: Deploy to Netlify
uses: nwtgck/actions-netlify@v2.0
with:
publish-dir: './build'
production-branch: 'main'
github-token: ${{ secrets.GITHUB_TOKEN }}
deploy-message: "Deployed from GitHub Actions by Burak Balkı (2026)"
# Netlify API token'ınızı GitHub Secrets'a eklemelisiniz: NETLIFY_AUTH_TOKEN
# Netlify site ID'nizi GitHub Secrets'a eklemelisiniz: NETLIFY_SITE_ID
NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
env:
CI: true # React build process için gerekli olabilir
```
**Nasıl Çalışır:**
1. **Checkout Code:** Repository'nizi runner'a klonlar.
2. **Setup Node.js:** Node.js 20.x ortamını kurar ve `npm` bağımlılıklarını önbelleğe alır.
3. **Install Dependencies:** `npm ci` ile bağımlılıkları kurar.
4. **Build React App:** `npm run build` komutuyla React uygulamasını derler ve `build` klasörüne çıktı verir.
5. **Deploy to Netlify:** `nwtgck/actions-netlify@v2.0` aksiyonunu kullanarak `build` klasöründeki içeriği Netlify'a dağıtır. Bu adım için Netlify API token'ınızı (`NETLIFY_AUTH_TOKEN`) ve site ID'nizi (`NETLIFY_SITE_ID`) GitHub repository `secrets` kısmına eklemeniz gerekmektedir.
Bu örnek, GitHub Actions'ın bir web uygulamasının CI/CD sürecini ne kadar kolay otomatikleştirebileceğini göstermektedir. 2026'da bu tür otomasyonlar, geliştirme ekipleri için standart haline gelmiştir.
## Önemli Noktalar (Key Takeaways)
* **GitHub Actions**, 2026 itibarıyla modern CI/CD süreçleri için vazgeçilmez, olay tabanlı bir otomasyon aracıdır.
* **YAML tabanlı iş akışları**, esnek ve güçlü otomasyon senaryoları oluşturmanızı sağlar.
* **`secrets` kullanımı**, hassas bilgilerin güvenli bir şekilde yönetilmesi için kritik öneme sahiptir.
* **Yeniden kullanılabilir iş akışları**