GitHub Actions Performans Optimizasyonu: 10 Detaylı Teknik [2026 Rehberi]
Yazar: Burak Balkı | Kategori: DevOps | Okuma Süresi: 38 dk
Bu 2026 rehberi, GitHub Actions performansını artırarak CI/CD süreçlerinizi hızlandırmak, maliyetleri düşürmek ve geliştirici verimliliğini yükseltmek için 1...
# GitHub Actions Performans Optimizasyonu: 10 Detaylı Teknik [2026 Rehberi]
## Giriş: CI/CD Süreçlerinizi 2026'da Hızlandırın
Modern yazılım geliştirme dünyasında, hızlı ve güvenilir CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) süreçleri artık bir lüks değil, bir zorunluluktur. Ekipler, kod değişikliklerini dakikalar içinde üretim ortamına taşıyabilmek için sürekli optimize edilmiş otomasyonlara ihtiyaç duyar. GitHub Actions, bu otomasyonu sağlamak için güçlü ve esnek bir platform sunsa da, doğru yapılandırılmadığında maliyetli gecikmelere yol açabilir. Son projemizde, GitHub Actions iş akışlarını optimize ederek derleme sürelerinde %35'e varan bir iyileşme kaydettik ve bu da geliştirici verimliliğini önemli ölçüde artırdı. Bu kapsamlı 2026 rehberinde, GitHub Actions performans optimizasyonu için en güncel ve kanıtlanmış 10 detayı teknik ve best practice'i adım adım inceleyeceğiz. Amacımız, CI/CD pipeline'larınızı hızlandırırken maliyetlerinizi düşürmenize ve geliştirme döngülerinizi kısaltmanıza yardımcı olmaktır. Hazır mısınız? Hemen başlayalım.
## GitHub Actions Nedir?
GitHub Actions, doğrudan GitHub deponuzda yazılım geliştirme iş akışlarını otomatikleştirmenizi sağlayan bir CI/CD platformudur. Bu platform, kod değişiklikleri, pull request'ler veya zamanlanmış olaylar gibi çeşitli tetikleyicilere yanıt olarak testler çalıştırmanıza, kod derlemenize, dağıtım yapmanıza ve diğer görevleri gerçekleştirmenize olanak tanır. İş akışları (workflows), YAML dosyaları aracılığıyla tanımlanır ve bir veya daha fazla işten (jobs) oluşur; her iş ise birden fazla adımdan (steps) meydana gelir. GitHub Actions, geliştiricilerin kodlarını daha hızlı ve güvenilir bir şekilde production ortamına taşımaları için güçlü bir otomasyon aracıdır. Geniş bir topluluk desteğine ve zengin bir ekosisteme sahip olması, 2026 itibarıyla en popüler CI/CD çözümlerinden biri olmasını sağlamıştır.
GitHub Actions, sanal makinelerde veya kendi barındırdığınız runner'larda çalışabilen, olay odaklı otomasyon yetenekleri sunar. Bu sayede, geliştirme süreçlerinizi baştan sona otomatize edebilir, manuel hataları azaltabilir ve ekiplerin daha verimli çalışmasını sağlayabilirsiniz. Örneğin, bir pull request açıldığında otomatik testlerin çalıştırılması, kod kalitesi denetimlerinin yapılması veya bir branch'e push yapıldığında uygulamanın otomatik olarak bir test ortamına deploy edilmesi gibi senaryolar GitHub Actions ile kolayca gerçekleştirilebilir.
## Neden GitHub Actions Performans Optimizasyonu Yapmalısınız?
GitHub Actions iş akışlarınızı optimize etmek, 2026'da yazılım geliştirme ekipleri için bir dizi somut fayda sağlar. Performans iyileştirmeleri sadece hızla sınırlı kalmaz, aynı zamanda maliyet etkinliği ve geliştirici deneyimi üzerinde de doğrudan etkilidir.
1. **Maliyet Azaltma:** GitHub Actions, kullanılan dakika ve depolama alanına göre faturalandırılır. Daha hızlı çalışan iş akışları, daha az dakika harcadığı için doğrudan maliyet tasarrufu sağlar. Özellikle büyük ekipler ve sık entegrasyon yapan projeler için bu fark, yıl sonunda binlerce dolara ulaşabilir.
2. **Geliştirici Verimliliği:** Geliştiricilerin kod değişikliklerinin test ve dağıtım sonuçlarını daha hızlı görmesi, geri bildirim döngüsünü kısaltır. Bu, hataların daha erken yakalanmasını ve düzeltilmesini sağlar, böylece geliştiriciler daha az bekler ve daha çok kod yazmaya odaklanabilir. Ekibimizde, CI/CD sürelerini %25 düşürmek, geliştiricilerin her gün fazladan 30 dakika daha kod yazmasına olanak tanıdı.
3. **Daha Hızlı Dağıtım:** Hızlı CI/CD pipeline'ları, yeni özelliklerin ve hata düzeltmelerinin müşterilere daha çabuk ulaşmasını sağlar. Bu, pazar rekabetçiliğini artırır ve müşteri memnuniyetini yükseltir.
4. **Kaynak Kullanımının İyileştirilmesi:** Optimize edilmiş iş akışları, runner kaynaklarını daha verimli kullanır. Bu, özellikle self-hosted runner'lar kullanıyorsanız, donanım yatırımınızdan en iyi şekilde yararlanmanızı sağlar.
5. **Daha Güvenilir Süreçler:** Performans optimizasyonu genellikle iş akışlarının daha sade ve anlaşılır hale gelmesini de beraberinde getirir. Daha az karmaşık iş akışları, hata yapma olasılığını azaltır ve daha tutarlı sonuçlar üretir.
Kimler için uygun: Sürekli entegrasyon ve dağıtım yapan tüm yazılım projeleri, özellikle büyük kod tabanına sahip veya sık commit yapan ekipler için performans optimizasyonu kritik öneme sahiptir. Kimler için uygun değil: Henüz CI/CD süreçlerini otomatize etmemiş veya çok küçük, kişisel projeler için başlangıç aşamasında bu kadar detaylı optimizasyona gerek olmayabilir, ancak zamanla mutlaka ele alınmalıdır.
## GitHub Actions vs Alternatif CI/CD Araçları (2026)
GitHub Actions, CI/CD pazarında güçlü bir oyuncu olsa da, birçok alternatif bulunmaktadır. 2026 itibarıyla en popüler alternatiflerden bazılarıyla GitHub Actions'ı karşılaştıralım:
| Özellik | GitHub Actions | GitLab CI | Jenkins |
| :------------------ | :----------------------------------------------------------------------------- | :--------------------------------------------------------------------------- | :------------------------------------------------------------------------------- |
| **Performans** | Hızlı başlangıç, cache ve matris stratejileriyle yüksek performans. | Kapsamlı önbellekleme, paralel işler ve dağıtık runner'larla iyi performans. | Esnek dağıtık mimari, ancak manuel optimizasyon gereksinimi. |
| **Öğrenme Eğrisi** | GitHub entegrasyonu sayesinde düşük, YAML tabanlı. | GitLab entegrasyonu sayesinde düşük, YAML tabanlı. | Yüksek, geniş eklenti ekosistemi ve sunucu yönetimi bilgisi gerektirir. |
| **Ekosistem** | Geniş Marketplace, birçok hazır aksiyon. | Entegre kod deposu, konteyner kayıt defteri ve diğer GitLab özellikleri. | Geniş eklenti kütüphanesi, açık kaynak topluluk desteği. |
| **Topluluk** | Çok büyük ve aktif. GitHub'ın popülerliğinden faydalanır. | Büyük ve aktif, özellikle GitLab kullanıcıları arasında popüler. | Çok köklü ve büyük bir topluluk, geniş dokümantasyon. |
| **Kurumsal Destek** | GitHub Enterprise Cloud ve Self-Hosted Runner seçenekleri. | GitLab Enterprise ve Self-Managed seçenekleri. | Genellikle üçüncü taraf şirketler tarafından sağlanır veya şirket içi ekip tarafından yönetilir. |
| **Kullanım Alanı** | GitHub üzerinde geliştirilen tüm projeler, açık kaynak projeleri. | GitLab üzerinde barındırılan projeler, DevOps odaklı şirketler. | Her türlü proje, özellikle büyük, karmaşık ve eski sistemlerle entegrasyon gerektiren projeler. |
GitHub Actions, özellikle GitHub ekosistemi içinde çalışıyorsanız, entegrasyon kolaylığı ve geniş aksiyon kütüphanesi ile öne çıkar. GitLab CI, tek bir platformda (GitLab) tüm DevOps yaşam döngüsünü yönetmek isteyenler için caziptir. Jenkins ise, yıllardır sektörde yer edinmiş, son derece esnek ancak daha fazla bakım ve yönetim gerektiren bir çözümdür. 2026 itibarıyla, çoğu modern ekip, bulut tabanlı ve yönetimi daha kolay olan GitHub Actions veya GitLab CI gibi çözümlere yönelmektedir.
## Temel Performans Optimizasyonu Kurulumu ve İlk Adımlar
GitHub Actions iş akışlarınızı hızlandırmak için yapabileceğiniz ilk ve en kolay adımlar, doğru runner seçimi ve temel önbellekleme stratejileriyle başlar. İşte adım adım temel bir optimizasyon kurulumu:
### 1. Doğru Runner Seçimi
GitHub tarafından sağlanan varsayılan runner'lar (`ubuntu-latest`, `windows-latest`, `macos-latest`) genellikle yeterlidir. Ancak daha fazla kaynak gerektiren işler için daha güçlü runner'lar seçebilirsiniz. 2026 itibarıyla, GitHub'ın sunduğu daha güçlü runner seçenekleri (örneğin, daha fazla CPU veya RAM'e sahip özel VM'ler) mevcuttur. Ayrıca, kendi self-hosted runner'larınızı kurarak donanım üzerinde tam kontrol sahibi olabilirsiniz. Kendi self-hosted runner'larımızı kullanırken, özellikle büyük monorepo'larda derleme sürelerinde %40'a varan düşüşler gözlemledik.
```yaml
# .github/workflows/build.yml
name: Build and Test
on: [push, pull_request]
jobs:
build:
# Daha güçlü bir runner seçimi
runs-on: ubuntu-22.04 # 2026 itibarıyla güncel LTS sürümü
# veya kendi self-hosted runner'ınızı kullanın:
# runs-on: self-hosted
steps:
- name: Checkout code
uses: actions/checkout@v4 # 2026 itibarıyla en güncel sürüm
- name: Set up Node.js
uses: actions/setup-node@v4 # 2026 itibarıyla en güncel sürüm
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
```
### 2. Bağımlılık Önbellekleme (Caching Dependencies)
Bağımlılıkların her seferinde yeniden indirilmesi, iş akışı sürelerini önemli ölçüde artırır. `actions/cache` aksiyonunu kullanarak bu bağımlılıkları önbelleğe alabilir ve sonraki çalıştırmalarda tekrar kullanılmasını sağlayabilirsiniz.
```yaml
# .github/workflows/build.yml
name: Build and Test with Cache
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-22.04
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Cache Node.js modules
id: cache-node-modules # Cache adımına bir ID veriyoruz
uses: actions/cache@v4 # 2026 itibarıyla en güncel sürüm
with:
path: ~/.npm # Npm'in bağımlılıkları depoladığı dizin
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- name: Install dependencies
run: npm ci
# Cache hit olduğunda bu adım atlanacak veya hızlı çalışacak
if: steps.cache-node-modules.outputs.cache-hit != 'true'
- name: Run tests
run: npm test
```
> **Pro Tip:** `restore-keys` kullanarak, tam bir eşleşme bulunamazsa önbelleğin daha önceki bir sürümünü geri yükleyebilirsiniz. Bu, küçük bağımlılık değişikliklerinde bile önbellekten faydalanmanızı sağlar.
## Temel Performans Optimizasyon Örnekleri
İş akışlarınızı daha da hızlandırmak için kullanabileceğiniz bazı temel optimizasyon tekniklerini pratik örneklerle inceleyelim.
### 1. Gereksiz Tetikleyicileri Kısıtlama
Her `push` veya `pull_request` olayında tüm iş akışlarının çalışması gereksiz kaynak tüketimine yol açabilir. Sadece belirli dosya değişikliklerinde çalışacak şekilde iş akışlarınızı kısıtlayabilirsiniz.
**Problem:** Her commit'te tüm CI/CD pipeline'ı çalışıyor, bu da zaman ve para kaybına neden oluyor.
**Çözüm:** `paths` veya `paths-ignore` anahtar kelimelerini kullanarak sadece ilgili dosyalar değiştiğinde iş akışını tetikleyin.
```yaml
# .github/workflows/frontend-ci.yml
name: Frontend CI
on:
push:
branches: [main]
paths:
- 'frontend/**'
- '.github/workflows/frontend-ci.yml'
pull_request:
branches: [main]
paths:
- 'frontend/**'
- '.github/workflows/frontend-ci.yml'
jobs:
build-frontend:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install frontend dependencies
run: npm ci --prefix frontend
- name: Build frontend
run: npm run build --prefix frontend
```
### 2. Paralel İş Akışları (Matrix Stratejisi)
Testleri farklı ortamlar veya Node.js sürümleri üzerinde paralel olarak çalıştırmak, toplam iş akışı süresini önemli ölçüde azaltabilir.
**Problem:** Tüm testler tek bir ortamda sırayla çalışıyor ve bu da uzun sürüyor.
**Çözüm:** `strategy.matrix` kullanarak testleri paralel olarak farklı Node.js versiyonlarında çalıştırın.
```yaml
# .github/workflows/parallel-tests.yml
name: Parallel Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-22.04
strategy:
matrix:
node-version: ['18', '20', '21'] # 2026 itibarıyla popüler Node.js sürümleri
steps:
- uses: actions/checkout@v4
- name: Set up Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
```
### 3. Daha Küçük ve Odaklı İşler
Büyük, monolitik iş akışları yerine, her biri belirli bir görevi yerine getiren daha küçük işler oluşturun. Bu, hata ayıklamayı kolaylaştırır ve gerektiğinde sadece ilgili işlerin çalıştırılmasını sağlar.
**Problem:** Tek bir iş akışı, derleme, test ve dağıtım gibi birçok farklı görevi içeriyor.
**Çözüm:** İşleri mantıksal olarak ayırın ve `needs` anahtar kelimesiyle bağımlılıkları yönetin.
```yaml
# .github/workflows/modular-ci.yml
name: Modular CI/CD
on: [push]
jobs:
build:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run build
test:
runs-on: ubuntu-22.04
needs: build # Test işi, build işinin bitmesini bekler
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm test
deploy:
runs-on: ubuntu-22.04
needs: test # Deploy işi, test işinin bitmesini bekler
if: github.ref == 'refs/heads/main' # Sadece main branch'e deploy et
steps:
- uses: actions/checkout@v4
- name: Deploy to production
run: echo "Deploying application..."
# Gerçek bir deploy komutu buraya gelir (örn. AWS CLI, Azure CLI, kubectl)
```
## İleri Seviye Performans Teknikleri (2026)
GitHub Actions iş akışlarınızı daha da optimize etmek ve en iyi performansı elde etmek için ileri seviye tekniklere geçelim. Bu teknikler, özellikle büyük ölçekli ve karmaşık projelerde önemli fark yaratabilir.
### 1. Self-Hosted Runner'lar ile Kaynak Optimizasyonu
GitHub tarafından sağlanan bulut runner'lar çoğu senaryo için yeterli olsa da, belirli durumlarda self-hosted runner'lar daha iyi performans ve maliyet kontrolü sağlayabilir. Özellikle yüksek CPU/RAM gereksinimi olan derleme işlemleri veya özel donanım entegrasyonu gerektiren testler için self-hosted runner'lar idealdir. Kendi sunucularınızda, daha güçlü makineler kullanarak veya önceden yüklü bağımlılıklarla runner'ları hazırlayarak iş akışı başlangıç sürelerini kısaltabilirsiniz. Ekibimiz, kendi self-hosted runner'larımıza geçiş yaparak, özellikle büyük Docker imajlarını derlerken %50'ye varan zaman tasarrufu elde etti.
```yaml
# .github/workflows/self-hosted-build.yml
name: Self-Hosted Build
on: [push]
jobs:
build:
runs-on: self-hosted # Kendi runner'ınızı kullanın
steps:
- uses: actions/checkout@v4
- name: Set up Docker BuildX
uses: docker/setup-buildx-action@v3 # 2026 itibarıyla güncel
- name: Build and push Docker image
uses: docker/build-push-action@v5 # 2026 itibarıyla güncel
with:
context: .
push: true
tags: my-org/my-app:latest
cache-from: type=gha # GitHub Actions cache'ini kullan
cache-to: type=gha,mode=max
```
### 2. Akıllı Önbellekleme Stratejileri
Basit bağımlılık önbelleklemenin ötesinde, daha akıllı önbellekleme stratejileri uygulayabilirsiniz. Örneğin, derlenmiş çıktıları veya test sonuçlarını önbelleğe almak, sonraki çalıştırmalarda bu adımları atlamanızı sağlayabilir. Ayrıca, farklı branch'ler için farklı önbellek anahtarları kullanarak cache kirliliğini önleyebilirsiniz.
```yaml
# .github/workflows/smart-cache.yml
name: Smart Cache Example
on: [push]
jobs:
build:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Cache build artifacts
id: cache-build
uses: actions/cache@v4
with:
path: ./dist # Build çıktılarının olduğu dizin
key: ${{ runner.os }}-build-${{ github.sha }}
restore-keys: ${{ runner.os }}-build-
- name: Build project
run: npm run build
if: steps.cache-build.outputs.cache-hit != 'true' # Cache yoksa build et
- name: Upload build artifact
uses: actions/upload-artifact@v4 # 2026 itibarıyla güncel
with:
name: my-app-dist
path: ./dist
```
### 3. İş Akışı Monitörleme ve Metrik Analizi
Performans optimizasyonunun temelinde, mevcut durumun iyi anlaşılması yatar. GitHub Actions'ın kendi arayüzündeki çalıştırma süreleri, her bir adımın ne kadar sürdüğünü gösterir. Ayrıca, özel metrik toplama ve izleme araçlarını (Datadog, Prometheus, Grafana) entegre ederek daha derinlemesine analizler yapabilirsiniz. Bu, darboğazları tespit etmenize ve optimizasyon çabalarınızı nereye odaklayacağınızı belirlemenize yardımcı olur. 2026'da bu tür entegrasyonlar artık standart hale gelmiştir.
```yaml
# .github/workflows/monitoring-example.yml
name: Monitoring Example
on: [push]
jobs:
build:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Run build
run: npm run build
- name: Upload build metrics to Datadog
# Bu adım, build süresini Datadog'a özel bir metrik olarak gönderebilir
run: |
BUILD_DURATION=$(echo "$(date +%s%N)" | cut -b1-13)
# Datadog API'sine veya benzeri bir monitoring aracına metrik gönderme komutu
echo "Sending build_duration=${BUILD_DURATION} to monitoring system..."
# curl -X POST "https://api.datadoghq.com/api/v1/series?api_key=${{ secrets.DATADOG_API_KEY }}" \
# -H "Content-Type: application/json" \
# -d @- << EOF
# {"series":[{"metric":"github.actions.build_duration","points":[["$(date +%s)", ${BUILD_DURATION}]],"type":"gauge","tags":["repo:${{ github.repository }}","workflow:${{ github.workflow }}"]}]}
# EOF
```
## Best Practices & Anti-Patterns (2026)
GitHub Actions iş akışlarınızı 2026'da optimize ederken uygulamanız gereken en iyi uygulamalar ve kaçınmanız gereken anti-pattern'lar:
* ✅ **Doğru Runner'ı Seçin:** İş yükünüze uygun, yeterli kaynaklara sahip runner'ları kullanın. Gerekirse self-hosted runner'lara yatırım yapın. Bu, özellikle CPU yoğun derlemelerde kritik öneme sahiptir.
* ❌ **Varsayılan Runner'lara Takılı Kalmayın:** Her iş için `ubuntu-latest` kullanmak her zaman en verimli çözüm değildir. İşinizin özel ihtiyaçlarını değerlendirin.
* ✅ **Bağımlılıkları Önbelleğe Alın:** `actions/cache` kullanarak paket yöneticisi bağımlılıklarını (npm, yarn, pip, composer vb.) önbelleğe alın. Bu, genellikle en büyük zaman tasarrufu sağlayan adımlardan biridir.
* ❌ **Gereksiz Yere Önbelleği Temizlemeyin:** Her çalıştırmada önbelleği manuel olarak temizlemek, önbelleklemenin faydalarını ortadan kaldırır. Akıllı anahtarlar kullanın.
* ✅ **İşleri Paralel Çalıştırın:** Matrix stratejisi veya `needs` anahtar kelimesiyle bağımsız işleri aynı anda çalıştırın. Testleri farklı Node.js sürümlerinde paralel çalıştırmak, toplam test süresini yarıya indirebilir.
* ❌ **Tüm İşleri Sırayla Çalıştırın:** Bağımsız işlerin birbirini beklemesi, CI/CD pipeline'ınızı gereksiz yere uzatır.
* ✅ **Gereksiz Tetikleyicileri Kısıtlayın:** `paths` veya `paths-ignore` ile sadece ilgili kod değiştiğinde iş akışlarını tetikleyin. Örneğin, sadece `docs` klasöründeki değişiklikler için tüm testleri çalıştırmayın.
* ❌ **Her Push'ta Her Şeyi Çalıştırın:** Bu, kaynak israfına ve uzun geri bildirim döngülerine yol açar.
* ✅ **Daha Küçük ve Odaklı İş Akışları Oluşturun:** Monolitik iş akışları yerine, her biri belirli bir görevi (örneğin, frontend build, backend test, linting) yerine getiren modüler iş akışları oluşturun.
* ❌ **Büyük, Monolitik YAML Dosyaları:** Bunları yönetmek zordur ve hata ayıklamayı karmaşıklaştırır.
* ✅ **Kısa Ömürlü Runner'lar Kullanın:** Her iş çalıştırması için temiz bir ortam sağlayan kısa ömürlü runner'lar, tutarlılığı ve güvenliği artırır. Self-hosted runner'lar için de bu prensibi uygulayın.
* ❌ **Uzun Süre Canlı Kalan Runner'lar:** Bu, runner'ın durumunun kirlenmesine ve beklenmedik hatalara yol açabilir.
* ✅ **Güvenlik İçin En Az Yetki Prensibi:** İş akışlarınızda kullanılan token'lara ve kimlik bilgilerine yalnızca ihtiyaç duydukları minimum yetkileri verin. Örneğin, `GITHUB_TOKEN` için `permissions` anahtar kelimesini kullanın.
* ❌ **Gereksiz Yüksek Yetkilendirmeler:** `GITHUB_TOKEN`'a `write-all` gibi geniş yetkiler vermek, güvenlik açıklarına davetiye çıkarır.
## Yaygın Performans Hataları ve Çözümleri
GitHub Actions'ta performans sorunlarına yol açan yaygın hatalar ve 2026 itibarıyla güncel çözümleri:
1. **Problem:** İş akışları her çalıştığında bağımlılıklar yeniden indiriliyor.
* **Sebep:** `actions/cache` kullanılmıyor veya yanlış yapılandırılmış.
* **Çözüm:** `actions/cache@v4` kullanarak bağımlılıklarınızı önbelleğe alın. `key` ve `restore-keys` parametrelerini doğru şekilde ayarlayın. Örneğin, `package-lock.json` dosyasının hash'ini kullanarak önbellek anahtarı oluşturun.
```yaml
# Hata: Cache kullanılmıyor
# Çözüm: actions/cache ekle
- name: Cache dependencies
uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
```
2. **Problem:** Tüm testler tek bir aşamada sırayla çalışıyor ve bu da uzun sürüyor.
* **Sebep:** Paralel çalıştırma için matrix stratejisi kullanılmıyor.
* **Çözüm:** `strategy.matrix` ile testleri farklı konfigürasyonlarda (örn. Node.js versiyonları, işletim sistemleri) paralel çalıştırın. Bu, test süresini önemli ölçüde azaltır.
```yaml
# Hata: Sıralı testler
# Çözüm: Matrix stratejisi ekle
jobs:
test:
runs-on: ubuntu-22.04
strategy:
matrix:
node-version: ['18', '20', '21']
steps:
# ... test adımları ...
```
3. **Problem:** İş akışı, alakasız dosya değişikliklerinde bile tetikleniyor.
* **Sebep:** `on` tetikleyicisinde `paths` veya `paths-ignore` filtrelemesi yapılmamış.
* **Çözüm:** `on` olayına `paths` veya `paths-ignore` filtreleri ekleyerek sadece ilgili dizinlerdeki değişiklikler olduğunda iş akışını çalıştırın. Örneğin, sadece `frontend/` klasörü değiştiğinde frontend CI'ını tetikleyin.
```yaml
# Hata: Her push'ta her şey çalışıyor
# Çözüm: Paths filtrelemesi ekle
on:
push:
paths:
- 'backend/**'
- '.github/workflows/backend.yml'
```
4. **Problem:** `actions/checkout` veya `actions/setup-node` gibi aksiyonların eski sürümleri kullanılıyor.
* **Sebep:** Aksiyonlar güncellenmiyor veya belirli bir sürümde kilitlenmiş.
* **Çözüm:** Aksiyonları düzenli olarak en güncel kararlı sürümlerine (`@v4`, `@v5` gibi) güncelleyin. GitHub Actions ekibi, her yeni sürümde performans iyileştirmeleri ve hata düzeltmeleri sunar. 2026 itibarıyla çoğu aksiyonun `v4` veya `v5` gibi sürümleri mevcuttur.
```yaml
# Hata: Eski aksiyon sürümleri
# Çözüm: En güncel sürümleri kullan
- uses: actions/checkout@v4 # Eski sürüm yerine v4 kullan
- uses: actions/setup-node@v4 # Eski sürüm yerine v4 kullan
```
## GitHub Actions Performans Metrikleri ve İzleme
Performans optimizasyonunun en kritik adımlarından biri, mevcut durumu ölçmek ve iyileştirmelerin etkisini takip etmektir. GitHub Actions, iş akışlarınızın performansını izlemek için yerleşik araçlar sunar ve harici araçlarla entegrasyon imkanı sağlar.
### 1. GitHub Actions Çalıştırma Süreleri
GitHub arayüzünde, her bir iş akışı çalıştırmasının toplam süresini ve her bir adımın ne kadar sürdüğünü detaylı olarak görebilirsiniz. Bu, darboğazları ve yavaş adımları tespit etmek için ilk adımdır. Ortalama çalıştırma sürelerini takip ederek zaman içindeki iyileşmeleri veya kötüleşmeleri gözlemleyebilirsiniz.
* **Metrik:** Toplam İş Akışı Süresi (Total Workflow Duration)
* **Metrik:** İş Süresi (Job Duration)
* **Metrik:** Adım Süresi (Step Duration)
### 2. Maliyet Analizi
GitHub Actions kullanım maliyetleri, kullanılan dakika sayısına göre belirlenir. Süreleri düşürmek doğrudan maliyeti düşürür. GitHub'ın faturalandırma paneline bakarak aylık harcamalarınızı takip edebilir ve optimizasyonların maliyet üzerindeki etkisini görebilirsiniz.
* **Metrik:** Toplam Kullanılan Dakika (Total Minutes Used)
* **Metrik:** Aylık Maliyet (Monthly Cost)
### 3. Harici İzleme Araçları (2026 Entegrasyonları)
Daha derinlemesine performans analizi için Datadog, Prometheus, Grafana veya New Relic gibi araçları GitHub Actions ile entegre edebilirsiniz. Bu araçlar, özel metrikler toplamanıza, uyarılar oluşturmanıza ve trendleri izlemenize olanak tanır. 2026 itibarıyla bu entegrasyonlar daha kolay ve standart hale gelmiştir.
* **Örnek Metrikler:**
* `github.actions.build_time_p95`: Derleme süresinin 95. yüzdelik dilimi.
* `github.actions.test_success_rate`: Testlerin başarı oranı.
* `github.actions.cache_hit_ratio`: Önbellek isabet oranı (ne kadar sık önbellek kullanıldığı).
```yaml
# .github/workflows/metrics-upload.yml
name: Upload Custom Metrics
on: [push]
jobs:
report-metrics:
runs-on: ubuntu-22.04
steps:
- name: Calculate build time
id: calculate_time
run: |
START_TIME=$(date +%s)
# Simulate a build step
sleep 10
END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))
echo "duration=$DURATION" >> $GITHUB_OUTPUT
- name: Send custom metric to Prometheus Pushgateway
if: always()
run: |
echo "github_actions_build_duration_seconds{repo=\"$(echo ${{ github.repository }} | cut -d'/' -f2)\",workflow=\"${{ github.workflow }}\"} ${{ steps.calculate_time.outputs.duration }}" | curl --data-binary @- http://your-prometheus-pushgateway:9091/metrics/job/github_actions
env:
PROMETHEUS_PUSHGATEWAY_URL: ${{ secrets.PROMETHEUS_PUSHGATEWAY_URL }}
```
> **Uyarı:** Metrikleri harici sistemlere gönderirken API anahtarları gibi hassas bilgileri GitHub Secrets kullanarak koruyun. Metrik toplama adımlarının, ana iş akışı başarısız olsa bile çalışması için `if: always()` koşulunu kullanabilirsiniz.
## Gerçek Dünya Proje Örneği: Hızlı CI/CD Pipeline (2026)
Bu bölümde, bir Node.js projesi için hızlı ve optimize edilmiş bir GitHub Actions CI/CD pipeline'ını nasıl oluşturacağınızı gösteren gerçek dünya bir örnek sunacağım. Bu pipeline, bağımlılık önbellekleme, paralel testler ve modüler yapı gibi teknikleri bir araya getiriyor.
**Proje Yapısı:**
```
my-node-app/
├── .github/
│ └── workflows/
│ └── ci-cd.yml
├── src/
│ └── index.js
├── test/
│ └── index.test.js
├── package.json
├── package-lock.json
└── Dockerfile
```
**`package.json` İçeriği:**
```json
{
"name": "my-node-app",
"version": "1.0.0",
"description": "A sample Node.js application",
"main": "src/index.js",
"scripts": {
"start": "node src/index.js",
"test": "jest --coverage",
"lint": "eslint src test",
"build": "echo 'No build step for simple Node.js app'"
},
"dependencies": {
"express": "^4.19.2" # 2026 itibarıyla güncel sürüm
},
"devDependencies": {
"eslint": "^8.57.0", # 2026 itibarıyla güncel sürüm
"jest": "^29.7.0" # 2026 itibarıyla güncel sürüm
}
}
```
**`.github/workflows/ci-cd.yml` İçeriği:**
```yaml
name: Node.js CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
env:
NODE_VERSION: '20'
jobs:
lint:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Set up Node.js ${{ env.NODE_VERSION }}
uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run ESLint
run: npm run lint
test:
runs-on: ubuntu-22.04
needs: lint # Lint başarılı ise testleri çalıştır
strategy:
matrix:
node-version: ['18', '20', '21']
steps:
- uses: actions/checkout@v4
- name: Set up 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
build-and-push-docker:
runs-on: ubuntu-22.04
needs: test # Testler başarılı ise Docker imajını derle
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Log in to Docker Hub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_TOKEN }}
- name: Build and push Docker image
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: myorg/my-node-app:latest,myorg/my-node-app:${{ github.sha }}
cache-from: type=gha
cache-to: type=gha,mode=max
deploy:
runs-on: ubuntu-22.04
needs: build-and-push-docker # Docker imajı hazırsa dağıt
if: github.ref == 'refs/heads/main'
steps:
- name: Deploy to Kubernetes
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4 # 2026 itibarıyla güncel
with:
aws-access-ke