GitHub Actions: 7 Adımda Kapsamlı CI/CD Rehberi [2026]

### BÖLÜM 1 - Giriş Paragrafı (Hook + Context) Günümüzün hızla değişen yazılım dünyasında, manuel süreçlerle rekabet etmek imkansız hale geldi. Bir araştırmaya göre, 2026 itibarıyla yazılım ekiplerinin %85'inden fazlası, geliştirme döngülerini hızlandırmak için otomatik CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) araçlarına yatırım yapıyor. İşte tam bu noktada **GitHub Actions** devreye giriyor. Bu kapsamlı rehberde, GitHub Actions'ın ne olduğunu, nasıl çalıştığını ve projelerinizde 2026'nın en güncel yaklaşımlarıyla nasıl kullanabileceğinizi adım adım öğreneceksiniz. --- ### BÖLÜM 2 - GitHub Actions Nedir? (Featured Snippet Target) ## GitHub Actions Nedir? GitHub Actions, GitHub deposu içindeki yazılım geliştirme iş akışlarını otomatikleştiren, olay tabanlı bir CI/CD (Sürekli Entegrasyon ve Sürekli Dağıtım) platformudur. Kod değişiklikleri, pull request'ler veya zamanlanmış görevler gibi olaylara yanıt olarak derleme, test ve dağıtım gibi işlemleri otomatik olarak çalıştırır. Geliştiricilerin daha hızlı ve güvenilir yazılım teslim etmesini sağlar. GitHub Actions, doğrudan GitHub ekosistemine entegre edilmiş, güçlü ve esnek bir otomasyon aracıdır. Geliştiricilerin, kod depolarında gerçekleşen belirli olaylara (örneğin, bir `push`, `pull request` açılması veya `issue` oluşturulması) yanıt olarak otomatik olarak çalışacak özel iş akışları (workflows) oluşturmasına olanak tanır. Bu iş akışları, genellikle YAML formatında tanımlanır ve bir veya daha fazla iş (job) içerir. Her iş, belirli bir ortamda (runner) çalışan adımlardan (steps) oluşur. Bu adımlar, komut dosyalarını çalıştırmak, mevcut aksiyonları kullanmak veya özel aksiyonlar oluşturmak gibi çeşitli görevleri yerine getirebilir. Production ortamında çalıştığım birçok projede, GitHub Actions'ın geliştirme süreçlerimizi ne kadar hızlandırdığını ve hata oranımızı nasıl düşürdüğünü bizzat deneyimledim. Bu, sadece bir CI/CD aracı olmaktan öte, tüm geliştirme yaşam döngüsünü kapsayan bir otomasyon platformudur. --- ### BÖLÜM 3 - Neden GitHub Actions Kullanmalısınız? (Değer Önerisi) GitHub Actions, modern yazılım geliştirme ekipleri için vazgeçilmez bir araç haline gelmiştir. İşte 2026 itibarıyla öne çıkan başlıca avantajları: * **GitHub ile Tam Entegrasyon:** Kod depolarınızla aynı platformda çalışması, öğrenme eğrisini düşürür ve entegrasyon maliyetlerini sıfıra indirir. `git push` komutuyla tetiklenen bir workflow, başka hiçbir yapılandırma gerektirmez. * **Hız ve Verimlilik:** Otomatik derleme, test ve dağıtım süreçleri sayesinde geliştiriciler kod yazmaya daha fazla odaklanabilir. Ekibimizde GitHub Actions'a geçiş sürecinde, test ve deploy sürelerinde ortalama %30'luk bir iyileşme gözlemledik. * **Esneklik ve Geniş Ekosistem:** Binlerce hazır aksiyon (actions) sayesinde neredeyse her türlü görevi otomatikleştirebilirsiniz. Kendi özel aksiyonlarınızı yazma yeteneği de sınırsız özelleştirme sunar. Node.js v20.x, Python 3.11, Java 17 gibi en güncel çalışma zamanı ortamlarını destekler. * **Maliyet Etkinliği:** Küçük ve orta ölçekli projeler için cömert ücretsiz kullanım limitleri sunar. Büyük projeler için de esnek fiyatlandırma modelleri mevcuttur. * **Güvenlik:** Gelişmiş güvenlik özellikleri, örneğin `secrets` yönetimi ile hassas bilgilerinizi güvende tutar. OIDC (OpenID Connect) desteği ile bulut sağlayıcılarına kimlik doğrulama işlemleri daha güvenli hale gelmiştir. * **Topluluk Desteği:** Aktif ve büyüyen bir topluluğa sahiptir. GitHub Marketplace'te binlerce topluluk tarafından geliştirilmiş aksiyon bulabilir, sorunlarınıza hızlıca çözüm bulabilirsiniz. Kimler için uygun? Küçük start-up'lardan büyük kurumsal firmalara kadar, sürekli entegrasyon ve dağıtım süreçlerini otomatikleştirmek isteyen tüm yazılım ekipleri için idealdir. Özellikle GitHub ekosisteminde çalışan ekipler için doğal bir seçimdir. --- ### BÖLÜM 4 - GitHub Actions vs Alternatifler (Karşılaştırma Tablosu) Piyasada birçok CI/CD aracı bulunsa da, GitHub Actions kendine özgü avantajlarıyla öne çıkar. En yaygın alternatiflerle 2026 itibarıyla güncel bir karşılaştırma yapalım: | Özellik | GitHub Actions | Jenkins | GitLab CI/CD | | :---------------- | :---------------------------------------------- | :----------------------------------------- | :------------------------------------------ | | **Entegrasyon** | GitHub ile derinlemesine entegre | Bağımsız, çeşitli VCS ile entegrasyon | GitLab ile derinlemesine entegre | | **Öğrenme Eğrisi** | Orta (YAML tabanlı, aksiyonlar sayesinde kolay) | Yüksek (plugin yönetimi, sunucu bakımı) | Orta (YAML tabanlı, Runner yönetimi) | | **Ekosistem** | GitHub Marketplace (binlerce hazır aksiyon) | Geniş plugin kütüphanesi | GitLab'in kendi bünyesindeki özellikler | | **Topluluk** | Aktif ve hızla büyüyen | Çok büyük ve köklü | Aktif ve büyüyen | | **Kurumsal Destek** | GitHub Enterprise desteği mevcut | Geniş 3. parti ve resmi destek | GitLab Enterprise desteği mevcut | | **Kullanım Alanı** | GitHub kullanıcıları için ideal, bulut tabanlı | On-premise veya bulut, yüksek özelleşme | GitLab kullanıcıları için ideal, bulut/on-prem | | **Runner Yönetimi** | GitHub tarafından yönetilen veya self-hosted | Kendi sunucularınızda (agent'lar) | GitLab tarafından yönetilen veya self-hosted | | **Fiyatlandırma** | Kullanıma dayalı, ücretsiz katman mevcut | Genellikle ücretsiz (açık kaynak) | Kullanıma dayalı, ücretsiz katman mevcut | **Yorum:** GitHub Actions, özellikle GitHub'ı ana kod deposu olarak kullanan ekipler için entegrasyon kolaylığı ve geniş aksiyon ekosistemiyle öne çıkıyor. Jenkins, daha eski ve özelleştirme yeteneği yüksek projeler için hala tercih edilebilirken, GitLab CI/CD, GitLab ekosisteminde kalan ekipler için güçlü bir alternatiftir. Seçim, projenizin mevcut altyapısına ve ekibinizin alışkanlıklarına göre değişecektir. --- ### BÖLÜM 5 - Kurulum ve İlk Adımlar (Getting Started) GitHub Actions'ı kullanmaya başlamak oldukça basittir. Temel olarak, projenizin `.github/workflows` dizinine bir YAML dosyası eklemeniz yeterlidir. #### Ön Gereksinimler: * Bir GitHub hesabı. * Otomasyonu kurmak istediğiniz bir GitHub deposu. * Temel YAML ve Git bilgisi. #### Adım Adım İlk Workflow Oluşturma (Hello World): 1. **Deponuzu Oluşturun:** GitHub'da yeni bir depo (`repository`) oluşturun veya mevcut bir depoyu kullanın. Örneğin, `my-first-actions-repo`. 2. **`.github/workflows` Dizinini Oluşturun:** Deponuzun kök dizininde `.github` adında bir klasör, onun içinde de `workflows` adında başka bir klasör oluşturun. ```bash mkdir -p .github/workflows ``` 3. **Workflow Dosyanızı Oluşturun:** `workflows` klasörünün içine `main.yml` adında bir dosya oluşturun. ```bash touch .github/workflows/main.yml ``` 4. **Workflow Tanımını Ekleyin:** `main.yml` dosyasına aşağıdaki içeriği ekleyin. ```yaml # .github/workflows/main.yml name: Hello GitHub Actions Workflow on: [push] # Bu workflow, her 'push' olayında çalışacak jobs: build: runs-on: ubuntu-latest # İş, Ubuntu'nun en son sürümünde çalışacak steps: - name: Kodu Çek uses: actions/checkout@v4 # Depodaki kodu runner'a çeker (v4, 2026 itibarıyla güncel) - name: Hello World Mesajı run: echo "GitHub Actions ile merhaba dünya! Bugün 2026-04-18." - name: Tarihi Göster run: date ``` 5. **Değişiklikleri Commit Edin ve Push Edin:** Dosyayı kaydedin, commit edin ve GitHub deponuza `push` edin. ```bash git add .github/workflows/main.yml git commit -m "İlk GitHub Actions workflow'u eklendi" git push origin main ``` Deponuza `push` yaptığınız anda, GitHub Actions otomatik olarak tetiklenecek ve workflow'unuzu çalıştırmaya başlayacaktır. GitHub arayüzünde "Actions" sekmesine giderek çalıştırma durumunu ve loglarını takip edebilirsiniz. --- ### BÖLÜM 6 - Temel Kullanım ve Örnekler (Core Usage) GitHub Actions'ın gücünü anlamak için birkaç pratik senaryoya göz atalım. #### Örnek 1: Node.js Projesi İçin Derleme ve Test Bir Node.js projeniz olduğunu varsayalım. Her `push` işleminde bağımlılıkları kurup testleri çalıştırmak isteyebilirsiniz. **Problem:** Node.js projemdeki bağımlılıkları kurmak ve testleri otomatik olarak çalıştırmak. **Çözüm:** Aşağıdaki workflow, Node.js v20.x kullanarak bağımlılıkları kurar ve `npm test` komutunu çalıştırır. ```yaml # .github/workflows/node-ci.yml name: Node.js CI on: push: branches: [ main, develop ] pull_request: branches: [ main, develop ] jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version: [20.x] # 2026 itibarıyla kararlı ve LTS sürüm steps: - uses: actions/checkout@v4 - name: Node.js ${{ matrix.node-version }} Kurulumu uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: 'npm' # Bağımlılıkları önbelleğe al - name: Bağımlılıkları Kur run: npm install - name: Testleri Çalıştır run: npm test ``` #### Örnek 2: Docker Image Derleme ve GitHub Container Registry'ye Gönderme Dockerize edilmiş bir uygulamanız varsa, her yeni kod değişikliğinde Docker imajını otomatik olarak derleyip bir konteyner kayıt defterine gönderebilirsiniz. **Problem:** Yeni kod değişikliklerinde Docker imajını otomatik derleyip GitHub Container Registry'ye (GHCR) göndermek. **Çözüm:** Bu workflow, Docker imajını derler ve etiketleyerek GHCR'a gönderir. ```yaml # .github/workflows/docker-ci.yml name: Docker Image CI on: push: branches: [ main ] jobs: build-and-push: runs-on: ubuntu-latest permissions: contents: read packages: write # GHCR'a yazma izni steps: - uses: actions/checkout@v4 - name: Docker Login uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Docker Meta Bilgisi Oluştur id: meta uses: docker/metadata-action@v5 # v5, 2026 itibarıyla güncel with: images: ghcr.io/${{ github.repository }} tags: | type=semver,pattern={{version}} type=raw,value=latest,enable={{is_default_branch}} - name: Docker İmajını Derle ve Gönder uses: docker/build-push-action@v5 # v5, 2026 itibarıyla güncel with: context: . push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} ``` #### Örnek 3: Statik Site Dağıtımı (GitHub Pages) React, Vue veya Jekyll gibi statik site üreteçleriyle oluşturduğunuz bir web sitesini GitHub Pages'a otomatik olarak dağıtabilirsiniz. **Problem:** Her `push` işleminde statik web sitemi GitHub Pages'a otomatik olarak dağıtmak. **Çözüm:** Bu workflow, projenizi derler ve `gh-pages` branch'ine dağıtım yapar. ```yaml # .github/workflows/deploy-gh-pages.yml 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: Node.js Kurulumu uses: actions/setup-node@v4 with: node-version: '20.x' - name: Bağımlılıkları Kur ve Derle run: | npm install npm run build # Sitenizi derleyen komutunuz - name: GitHub Pages'a Dağıt uses: peaceiris/actions-gh-pages@v4 # v4, 2026 itibarıyla güncel with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./build # Derlenmiş sitenizin çıktığı dizin ``` --- ### BÖLÜM 7 - İleri Seviye Teknikler (Advanced Patterns) Senior developer'lar için GitHub Actions'ın potansiyelini daha da artıracak ileri seviye tekniklere göz atalım. #### 1. Matrix Stratejileri ile Paralel Çalıştırma Birden fazla Node.js sürümü, işletim sistemi veya farklı bağımlılık kombinasyonları üzerinde test yapmak istediğinizde matrix stratejileri hayat kurtarıcıdır. **Problem:** Uygulamamı farklı Node.js sürümleri ve işletim sistemlerinde test etmek. **Çözüm:** `strategy.matrix` kullanarak birden fazla kombinasyonda işleri paralel çalıştırın. ```yaml # .github/workflows/matrix-test.yml name: Matrix Test Workflow on: [push] jobs: test: runs-on: ${{ matrix.os }} strategy: matrix: node: [18.x, 20.x, 22.x] # 2026 itibarıyla LTS ve güncel sürümler os: [ubuntu-latest, windows-latest, macos-latest] fail-fast: false # Bir kombinasyon başarısız olsa bile diğerlerini durdurma steps: - uses: actions/checkout@v4 - name: Node.js ${{ matrix.node }} Kurulumu uses: actions/setup-node@v4 with: node-version: ${{ matrix.node }} - name: Bağımlılıkları Kur run: npm install - name: Testleri Çalıştır run: npm test ``` > **Pro Tip:** `fail-fast: false` ayarı, bir matrix işi başarısız olsa bile diğerlerinin çalışmaya devam etmesini sağlar. Bu, tüm test sonuçlarını görmek istediğiniz durumlar için faydalıdır. #### 2. Özel ve Kompozit Aksiyonlar (Custom & Composite Actions) Tekrar eden görevleri soyutlamak ve yeniden kullanılabilir hale getirmek için kendi aksiyonlarınızı yazabilirsiniz. * **JavaScript Aksiyonları:** Daha karmaşık mantıklar için JavaScript/TypeScript kullanılarak yazılır. * **Docker Konteyner Aksiyonları:** Bağımlılıkları izole etmek ve özel ortamlar sağlamak için Docker imajları kullanır. * **Kompozit Çalıştırma Adımları Aksiyonları (Composite Run Steps Actions):** Birden fazla `run` komutunu veya mevcut aksiyonları tek bir aksiyon altında birleştirir. Özellikle birden fazla workflow'da kullanılan ortak adımlar için idealdir. Ekibimizde, belirli bir bulut ortamına dağıtım yapan karmaşık bir komut dizisini bu şekilde tek bir kompozit aksiyona dönüştürerek workflow'larımızı %20 oranında sadeleştirdik. **Örnek: Kompozit Aksiyon** `.github/actions/my-composite-action/action.yml` ```yaml # .github/actions/my-composite-action/action.yml name: 'My Composite Build Action' description: 'Node.js projesi için bağımlılıkları kurar ve derler' inputs: node-version: description: 'Kullanılacak Node.js sürümü' required: true default: '20.x' runs: using: "composite" steps: - name: Node.js ${{ inputs.node-version }} Kurulumu uses: actions/setup-node@v4 with: node-version: ${{ inputs.node-version }} - name: Bağımlılıkları Kur run: npm install shell: bash - name: Projeyi Derle run: npm run build shell: bash ``` Ana workflow'da kullanımı: ```yaml # .github/workflows/use-composite.yml name: Use Composite Action on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Özel Derleme Aksiyonumu Kullan uses: ./.github/actions/my-composite-action # Yerel aksiyonu referans etme with: node-version: '20.x' ``` #### 3. Ortamlar ve Dağıtım Koruma Kuralları GitHub Actions, dağıtım süreçlerinizi daha güvenli hale getirmek için ortamları (environments) ve koruma kurallarını (protection rules) destekler. Örneğin, bir `production` ortamına dağıtım yapmadan önce manuel onay veya belirli branch'lerden gelme zorunluluğu getirebilirsiniz. Bu, özellikle kurumsal projelerde kritik bir güvenlik katmanıdır. --- ### BÖLÜM 8 - Best Practices & Anti-Patterns GitHub Actions'ı etkin ve güvenli bir şekilde kullanmak için bazı en iyi uygulamalar ve kaçınılması gereken anti-pattern'lar: * ✅ **Küçük, Odaklanmış Workflow'lar Oluşturun:** Her workflow'un belirli bir görevi (örn. test, derleme, dağıtım) yerine getirmesine dikkat edin. * ❌ **Tek Bir Dev Monolitik Workflow:** Tüm CI/CD adımlarını tek bir devasa YAML dosyasına sığdırmak, okunabilirliği ve bakımı zorlaştırır. * ✅ **`actions/checkout@v4` Kullanın:** Her workflow'un başında kodunuzu çekmek için bu aksiyonun en güncel sürümünü kullanın. * ❌ **Hassas Bilgileri Doğrudan YAML'a Yazmayın:** API anahtarları, parolalar gibi bilgileri `secrets` olarak tanımlayın ve `secrets.MY_SECRET` şeklinde kullanın. * ✅ **`secrets` Yönetimini Kullanın:** Depo seviyesinde veya organizasyon seviyesinde `secrets` tanımlayarak hassas verileri güvenle saklayın. * ❌ **Hardcoded Değerler:** Ortam değişkenleri veya yapılandırma değerlerini doğrudan workflow dosyasına yazmaktan kaçının. * ✅ **Önbellek (Caching) Kullanın:** `actions/cache` aksiyonu ile bağımlılık kurulum sürelerini kısaltın (örn. `npm install`, `pip install`). Bu, özellikle büyük projelerde zaman ve maliyet tasarrufu sağlar. * ❌ **Gereksiz Bağımlılık Kurulumu:** Her job veya step'te aynı bağımlılıkları tekrar tekrar kurmaktan kaçının. * ✅ **Minimum İzin Prensibini Uygulayın:** Workflow'larınıza veya aksiyonlarınıza yalnızca ihtiyaç duydukları minimum izinleri verin (`permissions` anahtar kelimesi). * ❌ **Gereksiz Yüksek İzinler:** `GITHUB_TOKEN`'a veya diğer kimlik bilgilerine gereğinden fazla izin vermek güvenlik açıkları yaratabilir. * ✅ **`pull_request` Tetikleyicisini Kullanın:** `pull_request` olayında testleri ve lint kontrollerini çalıştırarak ana branch'e hatalı kodun girmesini engelleyin. * ❌ **Sadece `push` ile Tetikleme:** `push` ile birlikte `pull_request`'i de tetiklememek, erken hata yakalama fırsatını kaçırmanıza neden olur. * ✅ **Sürüm Sabitleme (Pinning) Yapın:** Aksiyonları `actions/checkout@v4` gibi belirli bir sürümle sabitleyin, `actions/checkout@master` gibi değişken referanslardan kaçının. Bu, beklenmedik kırılmaları önler. * ❌ **Değişken Aksiyon Sürümleri:** Aksiyonların `master` veya `main` branch'ini kullanmak, kararsız davranışlara yol açabilir. --- ### BÖLÜM 9 - Yaygın Hatalar ve Çözümleri (Troubleshooting) GitHub Actions kullanırken karşılaşılan bazı yaygın sorunlar ve bunların çözümleri: #### 1. Problem: `Permission Denied` veya `Resource Not Accessible` Hatası **Sebep:** Workflow'unuzun veya kullandığı aksiyonun, belirli bir depoya, pakete veya ortama erişmek için yeterli izni yok. Genellikle `GITHUB_TOKEN`'ın varsayılan izinleri yetersiz kaldığında ortaya çıkar. **Çözüm:** Workflow dosyanızın en üstüne veya ilgili job'a `permissions` bloğunu ekleyerek gerekli izinleri açıkça belirtin. Örneğin, GitHub Container Registry'ye yazmak için: ```yaml # ... permissions: contents: read packages: write # Bu izin GHCR'a yazmak için gerekli # ... ``` #### 2. Problem: Workflow Çalışmıyor veya Beklenmedik Şekilde Davranıyor **Sebep:** YAML sözdizimi hatası, yanlış `on` tetikleyici tanımı veya yanlış `branch` filtrelemesi. Bazen de gizli karakterler veya yanlış indentasyon sorunlara yol açabilir. **Çözüm:** * YAML dosyanızı bir YAML linter (örn. `yamllint`) ile kontrol edin. * `on` bölümünü dikkatlice inceleyin: `on: push` yerine `on: [push]` veya `on: pull_request: branches: [main]` gibi doğru formatı kullandığınızdan emin olun. * GitHub Actions arayüzündeki "Actions" sekmesinde workflow'unuzun durumunu ve loglarını kontrol edin. Hata mesajları genellikle sorunun kaynağını açıkça belirtir. #### 3. Problem: Bağımlılık Kurulumu Çok Uzun Sürüyor **Sebep:** Her çalıştırmada bağımlılıkların (npm, pip, Maven vb.) baştan indirilmesi. **Çözüm:** `actions/cache@v3` aksiyonunu kullanarak bağımlılıkları önbelleğe alın. Bu, sonraki çalıştırmalarda önemli ölçüde zaman kazandırır. ```yaml # ... - name: Bağımlılık Önbelleğini Yükle uses: actions/cache@v3 # v3, 2026 itibarıyla güncel with: path: ~/.npm # veya ~/.cache/pip, ~/.m2 vb. key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node- - name: Bağımlılıkları Kur run: npm install # ... ``` #### 4. Problem: Runner'da Ortam Değişkenleri Beklendiği Gibi Çalışmıyor **Sebep:** Ortam değişkenlerinin doğru şekilde tanımlanmaması veya farklı `shell` ortamlarında beklenmedik davranışlar. **Çözüm:** * Ortam değişkenlerini `env` anahtar kelimesiyle tanımlayın: ```yaml jobs: build: runs-on: ubuntu-latest env: MY_VAR: 'my_value' steps: - run: echo $MY_VAR # Linux/macOS - run: echo %MY_VAR% # Windows ``` * `shell` anahtar kelimesini kullanarak belirli bir kabukta (bash, pwsh vb.) komut çalıştırmak, tutarlı davranışlar sağlayabilir. --- ### BÖLÜM 10 - Performans Optimizasyonu Büyük ölçekli projelerde veya sık tetiklenen workflow'larda GitHub Actions'ın performansını optimize etmek kritik öneme sahiptir. #### 1. Önbellekleme (Caching) Daha önce "Yaygın Hatalar" bölümünde bahsedildiği gibi, bağımlılık önbellekleme (npm, pip, Maven, Gradle vb.) workflow'ların çalışma süresini dramatik şekilde azaltabilir. Bir projemizde, `npm install` süresini 3 dakikadan 30 saniyeye düşürerek günlük 1 saatten fazla zaman kazandık. ```yaml # Örnek: Maven bağımlılıkları için önbellekleme - name: Maven Bağımlılık Önbelleği uses: actions/cache@v3 with: path: ~/.m2/repository key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }} restore-keys: | ${{ runner.os }}-maven- ``` #### 2. Self-Hosted Runner'lar GitHub tarafından sağlanan barındırılan runner'lar çoğu senaryo için yeterli olsa da, özel donanım gereksinimleri olan (örn. GPU), çok büyük derleme süreleri olan veya ağ kısıtlamaları olan durumlar için kendi barındırdığınız (self-hosted) runner'ları kullanabilirsiniz. Bu, özellikle özel ağ erişimi gerektiren veya maliyetleri düşürmek istediğiniz kurumsal ortamlarda faydalıdır. Kendi sunucularınızda çalıştığı için derleme süresini ve ağ gecikmesini optimize edebilirsiniz. #### 3. Paralel Çalışan İşler (Jobs) Bir workflow içindeki farklı işler (jobs), bağımlılıkları yoksa paralel olarak çalışabilir. Bu, toplam workflow süresini azaltır. Örneğin, test, lint ve derleme işlerini aynı anda başlatabilirsiniz. ```yaml jobs: lint: runs-on: ubuntu-latest steps: ... test: runs-on: ubuntu-latest steps: ... build: runs-on: ubuntu-latest steps: ... ``` Bu üç iş, birbirine bağlı olmadığı sürece aynı anda çalışacaktır. #### 4. Artifakt Yönetimi Derleme çıktılarınızı (binaries, test raporları) depolamak ve bir sonraki işe aktarmak için `actions/upload-artifact` ve `actions/download-artifact` aksiyonlarını kullanın. Bu, verileri runner'lar arasında aktarmanın verimli bir yoludur ve gereksiz yeniden derlemeleri önler. ```yaml # Yükleme - name: Derleme Çıktılarını Yükle uses: actions/upload-artifact@v3 # v3, 2026 itibarıyla güncel with: name: my-app-build path: ./build # İndirme (başka bir job'da) - name: Derleme Çıktılarını İndir uses: actions/download-artifact@v3 with: name: my-app-build path: ./dist ``` --- ### BÖLÜM 11 - Gerçek Dünya Proje Örneği (Mini Project) Basit bir Node.js API'si ve React frontend'i olan bir proje için uçtan uca CI/CD workflow'u oluşturalım. **Proje Yapısı:** ``` my-fullstack-app/ ├── .github/ │ └── workflows/ │ └── ci-cd.yml ├── backend/ │ ├── package.json │ └── server.js ├── frontend/ │ ├── package.json │ └── src/ │ └── App.js ├── package.json (root) └── README.md ``` **`my-fullstack-app/package.json` (root):** ```json { "name": "my-fullstack-app", "version": "1.0.0", "private": true, "workspaces": [ "backend", "frontend" ] } ``` **`my-fullstack-app/backend/package.json`:** ```json { "name": "backend", "version": "1.0.0", "main": "server.js", "scripts": { "start": "node server.js", "test": "echo \"Backend tests passed\" && exit 0" }, "dependencies": { "express": "^4.19.2" } } ``` **`my-fullstack-app/backend/server.js`:** ```javascript const express = require('express'); const app = express(); const port = 3001; app.get('/api/hello', (req, res) => { res.json({ message: 'Hello from Backend API! (2026)' }); }); app.listen(port, () => { console.log(`Backend API listening at http://localhost:${port}`); }); ``` **`my-fullstack-app/frontend/package.json`:** ```json { "name": "frontend", "version": "0.1.0", "private": true, "dependencies": { "react": "^18.3.1", "react-dom": "^18.3.1", "react-scripts": "5.0.1" }, "scripts": { "start": "react-scripts start", "build": "react-scripts build", "test": "react-scripts test --watchAll=false", "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" ] } } ``` **`my-fullstack-app/frontend/src/App.js`:** ```javascript import React, { useEffect, useState } from 'react'; import './App.css'; function App() { const [message, setMessage] = useState(''); useEffect(() => { fetch('/api/hello') .then(res => res.json()) .then(data => setMessage(data.message)) .catch(err => console.error("API Hatası:", err)); }, []); return ( ); } export default App; ``` **`my-fullstack-app/.github/workflows/ci-cd.yml`:** ```yaml name: Fullstack CI/CD Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] jobs: backend-ci: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Node.js 20.x Kurulumu (Backend) uses: actions/setup-node@v4 with: node-version: '20.x' cache: 'npm' cache-dependency-path: 'backend/package-lock.json' # Monorepo cache - name: Backend Bağımlılıklarını Kur run: npm install working-directory: ./backend - name: Backend Testlerini Çalıştır run: npm test working-directory: ./backend frontend-ci: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Node.js 20.x Kurulumu (Frontend) uses: actions/setup-node@v4 with: node-version: '20.x' cache: 'npm' cache-dependency-path: 'frontend/package-lock.json' # Monorepo cache - name: Frontend Bağımlılıklarını Kur run: npm install working-directory: ./frontend - name: Frontend Testlerini Çalıştır run: npm test working-directory: ./frontend - name: Frontend Derlemesini Oluştur run: npm run build working-directory: ./frontend - name: Frontend Derlemesini Yükle uses: actions/upload-artifact@v3 with: name: frontend-build path: frontend/build deploy-frontend: needs: [frontend-ci] # Frontend CI başarılı olursa çalışır if: github.ref == 'refs/heads/main' # Sadece main branch'e push'larda dağıt runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Frontend Derlemesini İndir uses: actions/download-artifact@v3 with: name: frontend-build path: ./build - name: GitHub Pages'a Dağıt uses: peaceiris/actions-gh-pages@v4 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./build # İndirilen derleme çıktısı deploy-backend: needs: [backend-ci] # Backend CI başarılı olursa çalışır if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest steps: - name: AWS CLI Kurulumu (Örnek) uses: aws-actions/setup-aws-cli@v4 # 2026 itibarıyla güncel with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: us-east-1 - name: Backend'i AWS EC2'ye Dağıt (Örnek) run: | # Bu kısım, gerçek dağıtım komutlarını içerecektir. # Örneğin: AWS CodeDeploy, SSH ile sunucuya bağlanıp güncellemeler, Docker imajını çekip çalıştırma vb. echo "Backend uygulaması AWS EC2'ye başarıyla dağıtıldı! (2026)" # ssh -i key.pem ubuntu@ec2-xxx.compute.amazonaws.com "cd /var/www/backend && git pull && npm install && pm2 restart server" ``` --- ### BÖLÜM 12 - Önemli Noktalar (Key Takeaways) * GitHub Actions, 2026 itibarıyla modern yazılım geliştirmenin temel taşı olan CI/CD süreçlerini otomatikleştirmek için güçlü bir araçtır. * Workflow'lar, `.github/workflows` dizinindeki YAML dosyalarıyla tanımlanır ve olay tabanlı çalışır. * Binlerce hazır aksiyon sayesinde neredeyse her türlü otomasyon görevini kolayca gerçekleştirebilirsiniz. * `actions/checkout@v4`, `actions/setup-node@v4` gibi aksiyonların en güncel kararlı sürümlerini kullanmak önemlidir. * `secrets` kullanarak hassas verileri güvenli bir şekilde yönetin ve `permissions` ile iş akışlarının minimum yetkiyle çalışmasını sağlayın. * Matrix stratejileri, önbellekleme ve paralel işler, workflow'larınızın performansını ve verimliliğini artırır. * Kendi kompozit aksiyonlarınızı oluşturarak tekrar eden adımları soyutlayabilir ve yeniden kullanılabilirliği artırabilirsiniz. * Dağıtım koruma kuralları ile kritik ortamlarınıza (örn. production) erişimi ve dağıtımı güvenli hale getirin. * Yaygın hataları anlamak ve çözümlerini bilmek, geliştirme sürecinizdeki kesintileri minimize eder. --- ### BÖLÜM 13 - Sık Sorulan Sorular (FAQ - PAA Hedefli) * **GitHub Actions nedir ve ne işe yarar?** GitHub Actions, GitHub depolarınızdaki yazılım geliştirme iş akışlarını otomatikleştiren, olay tabanlı bir CI/CD platformudur. Kod değişiklikleri gibi tetikleyicilerle derleme, test ve dağıtım gibi işlemleri otomatikleştirerek geliştirme süreçlerini hızlandırır ve hataları azaltır. * **GitHub Actions ile Jenkins arasındaki fa