GitHub Actions Optimizasyonu: CI/CD Süreçlerini Hızlandırma Rehberi

## GitHub Actions Optimizasyonu: Modern CI/CD Süreçlerinde Verimlilik **GitHub Actions**, modern yazılım geliştirme ekosisteminde Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD) süreçlerini otomatize etmek için kullanılan en güçlü araçlardan biridir. Ancak, optimize edilmemiş iş akışları (workflows), yavaş geri bildirim döngülerine ve yüksek operasyonel maliyetlere neden olabilir. Bu rehberde, kurumsal düzeyde bir **GitHub Actions optimizasyonu** stratejisinin nasıl kurgulanacağını, performans metriklerini ve ileri seviye yapılandırma tekniklerini inceleyeceğiz. ## GitHub Actions Temelleri ve İş Akışı Bileşenleri Optimizasyon sürecine girmeden önce, sistemin temel bileşenlerini anlamak kritiktir. Bir GitHub Actions yapısı; **Workflow** (İş Akışı), **Job** (İş), **Step** (Adım) ve **Action** (Eylem) hiyerarşisinden oluşur. - **Runner:** İş akışının üzerinde çalıştığı sunucudur. - **Event:** İş akışını tetikleyen olaydır (push, pull_request vb.). - **Concurrency:** Aynı anda çalışan iş akışlarının yönetimidir. İyi bir yapılandırma, gereksiz kaynak tüketimini önleyerek geliştirici deneyimini (DX) doğrudan iyileştirir. ## Runner Seçimi: GitHub-Hosted vs. Self-Hosted Performansın ilk adımı, iş yüküne uygun runner tipini seçmektir. GitHub tarafından sağlanan runner'lar (GitHub-hosted) kullanım kolaylığı sunarken, özel ihtiyaçlar için **Self-hosted runner** yapılandırması daha verimli olabilir. | Özellik | GitHub-Hosted | Self-Hosted | |---------|---------------|-------------| | Bakım | GitHub tarafından yapılır | Kullanıcı tarafından yapılır | | Performans | Standart (2-core CPU) | İhtiyaca göre ölçeklenebilir | | Güvenlik | İzole ortam | Kendi ağınızda tam kontrol | | Maliyet | Kullandıkça öde | Altyapı maliyeti | > **Not:** Eğer derleme süreçleriniz yüksek CPU veya RAM gerektiriyorsa, daha güçlü donanımlara sahip self-hosted runner kullanmak işlem süresini %50'ye kadar azaltabilir. ## Caching (Önbelleğe Alma) Stratejileri ile Zaman Kazanma CI/CD süreçlerindeki en büyük zaman kaybı, her seferinde bağımlılıkların (dependencies) sıfırdan indirilmesidir. `actions/cache` kullanımı, **GitHub Actions optimizasyonu** için en kritik adımdır. ### Node.js Bağımlılıklarını Önbelleğe Alma ```yaml - name: Cache Node.js modules uses: actions/cache@v3 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node- ``` Bu yapılandırma, `package-lock.json` dosyası değişmediği sürece paketleri önbellekten getirir. Benzer mantık Python (pip), Java (Maven/Gradle) ve PHP (Composer) için de uygulanmalıdır. ### Python Pip Önbelleği Örneği ```yaml - name: Cache pip uses: actions/cache@v3 with: path: ~/.cache/pip key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }} restore-keys: | ${{ runner.os }}-pip- ``` ## Dependency Management: Paket Yönetimi Optimizasyonu Bağımlılıkların yönetimi sadece önbelleğe alma ile sınırlı değildir. Paket yükleme komutlarını optimize etmek, runner üzerindeki disk I/O işlemlerini azaltır. Örneğin, npm yerine `npm ci` (Clean Install) kullanmak, lock dosyasını temel alarak daha hızlı ve tutarlı bir kurulum sağlar. ```yaml - name: Install dependencies run: npm ci ``` ## Paralel Yürütme ve Matrix Builds Kullanımı İşleri ardışık çalıştırmak yerine paralel çalıştırmak, toplam workflow süresini dramatik şekilde düşürür. **Matrix Strategy**, farklı versiyonlarda test yaparken zaman tasarrufu sağlar. ```yaml jobs: test: strategy: matrix: os: [ubuntu-latest, windows-latest] node-version: [16.x, 18.x, 20.x] runs-on: ${{ matrix.os }} steps: - uses: actions/checkout@v4 - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v3 with: node-version: ${{ matrix.node-version }} - run: npm test ``` Bu örnekte, 6 farklı kombinasyon (2 OS x 3 Node version) aynı anda paralel olarak çalıştırılır. ## Workflow Yapılandırmasında Verimlilik Artırma İş akışlarını optimize etmek için `needs` anahtar kelimesiyle bağımlılıkları doğru kurgulamak gerekir. Birbirinden bağımsız işler her zaman paralel çalışmalıdır. ```yaml jobs: lint: runs-on: ubuntu-latest steps: - run: npm run lint test: runs-on: ubuntu-latest needs: lint # Sadece lint başarılı olursa başlar steps: - run: npm test ``` ### Concurrency (Eşzamanlılık) Kontrolü Aynı dalda (branch) yeni bir commit geldiğinde eski iş akışlarını durdurmak, gereksiz kaynak kullanımını engeller. ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ## Selective Checkout: Sadece Gerekli Veriyi Çekme Varsayılan olarak `actions/checkout` tüm git geçmişini çeker. Büyük repolarda bu işlem yavaş olabilir. `fetch-depth: 1` kullanarak sadece son commit'i çekmek performansı artırır. ```yaml - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 1 ``` ## Docker Layer Caching (Katmanlı Önbellek) Docker imajları oluştururken her katmanın önbelleğe alınması, build sürelerini saniyeler mertebesine indirebilir. `docker/build-push-action` bu işlemi otomatikleştirir. ```yaml - name: Build and push uses: docker/build-push-action@v5 with: context: . push: true tags: user/app:latest cache-from: type=gha cache-to: type=gha,mode=max ``` ## Artifact Yönetimi ve Depolama Optimizasyonu Build çıktılarını (artifacts) saklarken `retention-days` parametresini kullanmak, GitHub depolama maliyetlerini optimize eder. ```yaml - name: Upload production-ready build uses: actions/upload-artifact@v4 with: name: build-files path: dist/ retention-days: 5 # Varsayılan 90 gündür, 5 güne düşürerek alan kazanın ``` ## Koşullu Çalıştırma (Conditional Execution) Sadece belirli dosyalar değiştiğinde belirli adımları çalıştırmak için `if` ifadeleri ve `paths` filtreleri kullanılmalıdır. ```yaml on: push: paths: - 'src/**' # Sadece src klasörü değişince tetiklenir jobs: build: if: github.event_name == 'push' && github.ref == 'refs/heads/main' runs-on: ubuntu-latest steps: - run: echo "Sadece ana dalda çalışır" ``` ## Timeout Ayarları ile Kaynak Koruması Hatalı bir script'in sonsuz döngüye girmesi, dakikalarca (veya saatlerce) runner tüketimine neden olabilir. Her iş için mutlaka bir `timeout-minutes` belirlenmelidir. ```yaml jobs: deploy: runs-on: ubuntu-latest timeout-minutes: 15 steps: - run: ./deploy.sh ``` ## Gelişmiş Performans Metrikleri ve İzleme Optimizasyonun başarısını ölçmek için GitHub'ın sağladığı **Usage Metrics** ve **Workflow Insights** araçları kullanılmalıdır. 1. **Execution Time:** Her bir job'un ne kadar sürdüğü. 2. **Queue Time:** Runner'ın işi almak için beklediği süre. 3. **Cache Hit Rate:** Önbelleğin ne kadar efektif kullanıldığı. ## Sık Yapılan Hatalar ve Çözüm Önerileri - **Hata:** Her adımda `actions/checkout` yapmak. - **Çözüm:** Checkout işlemini sadece gerekli olan ilk job'da yapın ve çıktıları artifact olarak aktarın. - **Hata:** Gizli anahtarları (secrets) loglara yazdırmak. - **Çözüm:** GitHub Secrets kullanın ve maskeleme özelliğinden yararlanın. - **Hata:** Bağımlılıkları önbelleğe almadan her seferinde indirmek. - **Çözüm:** `actions/cache` veya dile özel setup action'larının dahili cache desteğini kullanın. ## Sık Sorulan Sorular (SSS) **1. GitHub Actions ücretsiz mi?** Bireysel ve açık kaynaklı projeler için ücretsizdir. Özel repolarda belirli bir ücretsiz dakika sınırı (aylık 2000 dk) vardır, sonrasında ücretlendirilir. **2. Önbellek (Cache) sınırı nedir?** Her depo için toplam önbellek limiti 10 GB'dır. 7 günden uzun süre erişilmeyen önbellekler silinir. **3. Self-hosted runner güvenli mi?** Kamuya açık (public) repolarda self-hosted runner kullanmak güvenlik riskleri barındırır; sadece güvenilir fork'lardan gelen kodların çalıştırılması önerilir. **4. Concurrency özelliği maliyeti düşürür mü?** Evet, gereksiz yere çalışan paralel iş akışlarını iptal ederek runner dakikalarından tasarruf sağlar. **5. Hangi runner daha hızlı: Ubuntu mu Windows mu?** Genellikle Ubuntu runner'lar daha hızlı başlar ve daha düşük kaynak tüketimine sahiptir. ## Özet ve Sonuç GitHub Actions optimizasyonu, sadece hızı artırmakla kalmaz, aynı zamanda geliştirme maliyetlerini düşürür ve CI/CD süreçlerini daha güvenilir hale getirir. **Caching**, **paralel çalışma**, **stratejik runner seçimi** ve **timeout yapılandırmaları** ile profesyonel bir otomasyon hattı kurabilirsiniz. Bu rehberdeki teknikleri uygulayarak, pipeline sürelerinizi %60'a varan oranlarda iyileştirmeniz mümkündür.