GitHub Actions: 7 Adımda Kapsamlı Başlangıç [2026 Rehberi]

### BÖLÜM 1 - Giriş Paragrafı (Hook + Context) Mobil uygulama geliştirme süreçleri, 2026 itibarıyla her zamankinden daha karmaşık ve rekabetçi bir hal aldı. Manuel test, derleme ve dağıtım süreçleri, geliştirme hızını ciddi şekilde yavaşlatabilir ve hatalara davetiye çıkarabilir. Peki, bu karmaşayı nasıl otomatize edebilir ve ekiplerinizi daha verimli hale getirebilirsiniz? **GitHub Actions**, bu sorunun cevabı olarak 2026'nın en güçlü CI/CD araçlarından biri olarak öne çıkıyor. Bu rehberde, mobil geliştirme projeleriniz için GitHub Actions'ı sıfırdan nasıl kuracağınızı, kullanacağınızı ve optimize edeceğinizi adım adım öğreneceksiniz. ### BÖLÜM 2 - GitHub Actions Nedir? ## GitHub Actions Nedir? **GitHub Actions**, GitHub depolarınızda doğrudan yazılım geliştirme iş akışlarını otomatikleştirmenizi sağlayan bir Sürekli Entegrasyon ve Sürekli Dağıtım (CI/CD) platformudur. 2026'da geliştiricilerin kod değişikliklerini derlemesine, test etmesine ve dağıtmasına olanak tanıyarak manuel süreçleri ortadan kaldırır. GitHub Actions, olay tabanlı iş akışları sayesinde, bir kod push'u, pull request oluşturma veya belirli bir zamanlama gibi tetikleyicilere yanıt verebilir. GitHub Actions, `iş akışları (workflows)`, `işler (jobs)`, `adımlar (steps)` ve `eylemler (actions)` gibi temel bileşenlerden oluşur. Bu bileşenler, YAML formatında tanımlanır ve projenizin `.github/workflows` dizininde saklanır. Bu sayede, versiyon kontrolü altında tutulur ve ekip içinde kolayca paylaşılabilir. Mobil geliştirme özelinde, Android APK veya iOS IPA derleme, birim ve entegrasyon testlerini çalıştırma, statik kod analizi yapma ve hatta Firebase App Distribution veya TestFlight gibi platformlara otomatik dağıtım yapma gibi görevler için ideal bir çözümdür. ### BÖLÜM 3 - Neden GitHub Actions Kullanmalısınız? Mobil geliştirme dünyasında 2026 yılında rekabetin artmasıyla birlikte, hızlı ve hatasız teslimatlar her zamankinden daha kritik hale geldi. GitHub Actions, bu ihtiyacı karşılamak için bir dizi önemli avantaj sunar: * **Otomasyon ve Verimlilik:** Kod değişikliklerinizin otomatik olarak derlenmesi, test edilmesi ve dağıtılması sayesinde geliştiriciler manuel görevlerle zaman kaybetmez. Bu, özellikle 2026'da büyük ve karmaşık mobil projelerde geliştirme döngülerini önemli ölçüde hızlandırır. Ekibimizde son Flutter projemizin CI/CD'sini GitHub Actions'a taşıdığımızda, dağıtım sürelerinde %30'luk bir düşüş gözlemledik. * **GitHub Entegrasyonu:** Projeleriniz zaten GitHub'daysa, Actions ile ek bir araç entegrasyonuna gerek kalmaz. Doğrudan deponuz içinde çalışır, bu da kurulumu ve yönetimi son derece kolaylaştırır. 2026'da geliştiriciler için bu tür entegre çözümler büyük bir tercih sebebi. * **Esneklik ve Geniş Ekosistem:** Hazır binlerce aksiyon (action) sayesinde hemen hemen her türlü görevi otomatize edebilirsiniz. Kendi özel aksiyonlarınızı yazabilir veya topluluk tarafından geliştirilen aksiyonları kullanabilirsiniz. Bu geniş ekosistem, 2026'da mobil geliştirme için her türlü araca ve platforma (Android Studio, Xcode, Flutter, React Native, Firebase, TestFlight vb.) kolayca entegre olmanızı sağlar. * **Maliyet Etkinliği:** GitHub Actions, belirli bir kullanım limitine kadar ücretsizdir ve daha büyük ekipler veya projeler için rekabetçi fiyatlandırma sunar. Bu, özellikle küçük ve orta ölçekli ekipler için 2026 bütçelerinde önemli bir avantaj sağlar. * **Güvenlik:** GitHub'ın güçlü güvenlik altyapısı üzerine inşa edilmiştir. Hassas bilgiler için `secrets` yönetimi gibi özellikler, CI/CD süreçlerinizde güvenliği en üst düzeyde tutmanıza yardımcı olur. 2026 siber güvenlik trendleri göz önüne alındığında, bu özellik hayati önem taşır. GitHub Actions, 2026 itibarıyla mobil uygulama geliştiricileri, DevOps mühendisleri ve sürekli entegrasyon/dağıtım süreçlerini otomatize etmek isteyen her ölçekten ekip için uygundur. Ancak, çok özel ve niş CI/CD gereksinimleri olan, tamamen on-premise çözümlere bağımlı büyük kurumsal yapılar için alternatifler de değerlendirilmelidir. ### BÖLÜM 4 - GitHub Actions vs Alternatifler GitHub Actions, CI/CD dünyasında güçlü bir oyuncu olsa da, piyasada birçok alternatif bulunmaktadır. 2026 yılında mobil geliştirme bağlamında en popüler alternatiflerden bazılarıyla GitHub Actions'ı karşılaştıralım: | Özellik | GitHub Actions (2026) | Jenkins (2026) | GitLab CI/CD (2026) | Bitrise (2026) | | :------------------ | :-------------------------------------------------- | :------------------------------------------------------- | :------------------------------------------------------- | :------------------------------------------------------- | | **Performans** | Hızlı başlatma, paralel işler, self-hosted runner desteği. | Sunucuya bağlı, iyi optimize edilirse hızlı. | GitLab altyapısıyla entegre, hızlı. | Mobil odaklı optimize edilmiş, yüksek performans. | | **Öğrenme Eğrisi** | Düşük-Orta (YAML tabanlı, geniş dokümantasyon). | Yüksek (Java tabanlı, plugin yönetimi). | Düşük-Orta (YAML tabanlı, GitLab ile entegre). | Düşük (Görsel arayüz, hazır adımlar). | | **Ekosistem** | Geniş (Binlerce topluluk aksiyonu, GitHub entegrasyonu). | Çok geniş (Binlerce plugin, olgun topluluk). | Geniş (GitLab ile tam entegre, Docker desteği). | Mobil odaklı (Özel mobil aksiyonlar, entegrasyonlar). | | **Topluluk** | Çok aktif ve hızla büyüyen. | Çok büyük ve olgun. | Aktif ve büyüyen. | Mobil geliştiriciler arasında aktif. | | **Kurumsal Destek** | GitHub Enterprise ile mükemmel. | Geniş danışmanlık ve destek seçenekleri. | GitLab Enterprise ile mükemmel. | Kurumsal planlarda özel destek. | | **Kullanım Alanı** | Geniş (Web, mobil, backend, altyapı). | Geniş (Her türlü yazılım projesi). | Geniş (DevOps yaşam döngüsü, SCM ile entegre). | Mobil odaklı (iOS, Android, React Native, Flutter). | 2026'da GitHub Actions, özellikle GitHub tabanlı projelerde çalışan ekipler için entegrasyon kolaylığı ve geniş ekosistemiyle öne çıkıyor. Jenkins hala çok güçlü ve özelleştirilebilir olsa da, kurulum ve bakım maliyeti daha yüksektir. GitLab CI/CD, GitLab kullanıcıları için doğal bir seçimken, Bitrise mobil odaklılığıyla niş bir çözüm sunar. Seçim, projenin mevcut altyapısına, ekip yetkinliklerine ve bütçeye göre yapılmalıdır. ### BÖLÜM 5 - Kurulum ve İlk Adımlar GitHub Actions'ı mobil projenizde kullanmaya başlamak oldukça basittir. İşte 2026'da bir Android projesi için temel bir iş akışı oluşturma adımları: #### Ön Gereksinimler: * Bir GitHub hesabı ve mobil projenizin bulunduğu bir GitHub deposu. * Temel YAML bilgisi. * Android projenizin `build.gradle` dosyasında derleme ve test komutlarının tanımlı olması. #### Adım Adım Kurulum: 1. **Deponuzda `.github/workflows` Dizini Oluşturun:** Bu dizin, tüm GitHub Actions iş akışı dosyalarınızı içerecektir. Deponuzun kök dizininde bu yapıyı oluşturun: ```bash mkdir -p .github/workflows ``` 2. **Yeni Bir İş Akışı Dosyası Oluşturun:** `android_ci.yml` adında bir dosya oluşturun ve içine aşağıdaki temel yapıyı ekleyin: ```yaml # .github/workflows/android_ci.yml name: Android CI/CD (2026) on: push: branches: - main pull_request: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: GitHub Depoyu Klonla uses: actions/checkout@v4 # 2026 itibarıyla en güncel sürüm - name: Java Kurulumu (JDK 17) uses: actions/setup-java@v4 # 2026 itibarıyla en güncel sürüm with: distribution: 'temurin' java-version: '17' - name: Gradle Cache Ayarları uses: actions/cache@v4 # 2026 itibarıyla en güncel sürüm with: path: ~/.gradle/caches key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }} restore-keys: |- ${{ runner.os }}-gradle- - name: Gradle Wrapper İzinlerini Ayarla run: chmod +x ./gradlew - name: Android Projesini Derle (Debug APK) run: ./gradlew assembleDebug - name: Uygulama Testlerini Çalıştır run: ./gradlew test ``` 3. **Dosyayı Kaydedin ve GitHub'a Yükleyin:** Bu `android_ci.yml` dosyasını deponuza push ettiğinizde, GitHub Actions otomatik olarak tetiklenecek ve iş akışınızı çalıştırmaya başlayacaktır. ```bash git add .github/workflows/android_ci.yml git commit -m "İlk Android CI iş akışı (2026)" git push origin main ``` 4. **GitHub Actions Sekmesini Kontrol Edin:** Deponuzdaki "Actions" sekmesine giderek çalışan iş akışınızı ve sonuçlarını gözlemleyebilirsiniz. Her `push` veya `pull_request` işlemi, bu iş akışını tetikleyecektir. > **Pro Tip (2026):** `actions/checkout@v4` ve `actions/setup-java@v4` gibi aksiyonların `@v4` ile belirtilmesi, 2026 itibarıyla en güncel kararlı sürümleri kullanmanızı sağlar ve gelecekteki breaking change'lerden etkilenme riskinizi azaltır. ### BÖLÜM 6 - Temel Kullanım ve Örnekler GitHub Actions'ın mobil geliştirme için temel kullanım senaryolarına ve pratik örneklerine göz atalım. Bu örnekler, 2026'da sıkça karşılaşılan ihtiyaçları karşılayacak şekilde tasarlanmıştır. #### 1. Android Uygulamasını Derleme ve Test Etme (Release APK) * **Problem:** Her kod değişikliğinde manuel olarak Android Studio'yu açıp `release` APK'sı oluşturmak ve testleri çalıştırmak zaman alıcı ve hataya açık. * **Çözüm:** GitHub Actions ile otomatik derleme ve test. * **Kod:** ```yaml # .github/workflows/android_release.yml name: Android Release Build & Test (2026) on: push: tags: - 'v*.*.*' # Sadece versiyon tag'leri push edildiğinde tetikle jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Java Kurulumu (JDK 17) uses: actions/setup-java@v4 with: distribution: 'temurin' java-version: '17' - name: Gradle Cache Ayarları uses: actions/cache@v4 with: path: ~/.gradle/caches key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }} restore-keys: |- ${{ runner.os }}-gradle- - name: Gradle Wrapper İzinlerini Ayarla run: chmod +x ./gradlew - name: Android Release APK Derle env: ORG_GRADLE_PROJECT_signingKeyId: ${{ secrets.SIGNING_KEY_ID }} ORG_GRADLE_PROJECT_signingKeyPassword: ${{ secrets.SIGNING_KEY_PASSWORD }} ORG_GRADLE_PROJECT_signingStoreFile: ${{ secrets.SIGNING_STORE_FILE }} ORG_GRADLE_PROJECT_signingStorePassword: ${{ secrets.STORE_PASSWORD }} run: ./gradlew assembleRelease - name: Uygulama Testlerini Çalıştır run: ./gradlew test - name: Derlenen APK'yı Yükle (Artifact) uses: actions/upload-artifact@v4 # 2026 itibarıyla en güncel sürüm with: name: app-release path: app/build/outputs/apk/release/app-release.apk ``` #### 2. iOS Uygulamasını Derleme (Xcode) * **Problem:** iOS uygulamalarını derlemek bir macOS ortamı gerektirir ve manuel olarak Xcode'dan yapmak zahmetlidir. * **Çözüm:** `macos-latest` runner kullanarak otomatik iOS derlemesi. * **Kod:** ```yaml # .github/workflows/ios_build.yml name: iOS Build (2026) on: push: branches: - main jobs: build: runs-on: macos-latest # iOS derlemesi için macOS runner gerekli steps: - uses: actions/checkout@v4 - name: Xcode Versiyonunu Seç run: sudo xcode-select -switch /Applications/Xcode_15.3.app/Contents/Developer # 2026 itibarıyla güncel Xcode versiyonu - name: CocoaPods Kurulumu (Gerekliyse) run: |- gem install cocoapods pod install --project-directory=ios - name: iOS Uygulamasını Derle run: |- xcodebuild clean build \ -project YourApp.xcodeproj \ -scheme YourApp \ -destination 'platform=iOS Simulator,name=iPhone 15 Pro' # 2026 itibarıyla güncel simülatör # veya archive komutu ile IPA oluşturabilirsiniz ``` #### 3. Firebase App Distribution ile Otomatik Dağıtım * **Problem:** Geliştirme ekibine veya test kullanıcılarına yeni mobil uygulama versiyonlarını sürekli manuel olarak göndermek. * **Çözüm:** Derleme sonrası Firebase App Distribution'a otomatik yükleme. * **Kod:** ```yaml # .github/workflows/firebase_dist.yml name: Firebase App Distribution (2026) on: workflow_run: workflows: ["Android Release Build & Test (2026)"] # Önceki iş akışı tamamlandığında tetikle types: - completed jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Derlenen APK'yı İndir uses: actions/download-artifact@v4 with: name: app-release path: ./app-release-artifact - name: Firebase App Distribution'a Yükle uses: FirebaseExtended/action-hosting-deploy@v0 # 2026 itibarıyla güncel Firebase Action with: repoToken: '${{ secrets.GITHUB_TOKEN }}' firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_MOBILE_APP }}' projectId: your-firebase-project-id appId: your-firebase-app-id file: ./app-release-artifact/app-release.apk # İndirilen artifact yolu groups: testers # Opsiyonel: belirli test grubu ``` #### 4. Flutter Uygulaması İçin CI/CD * **Problem:** Flutter projelerinde hem Android hem iOS için tek bir CI/CD pipeline kurmak. * **Çözüm:** Flutter aksiyonlarını kullanarak platform bağımsız derleme ve test. * **Kod:** ```yaml # .github/workflows/flutter_ci.yml name: Flutter CI/CD (2026) on: push: branches: - main pull_request: branches: - main jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Flutter SDK Kurulumu uses: subosito/flutter-action@v2 # 2026 itibarıyla güncel Flutter Action with: flutter-version: '3.19.6' # 2026'da kararlı bir sürüm channel: 'stable' - name: Flutter Bağımlılıklarını Yükle run: flutter pub get - name: Flutter Testlerini Çalıştır run: flutter test - name: Flutter Web Derlemesi (Opsiyonel) run: flutter build web - name: Flutter Android Derlemesi run: flutter build apk --release - name: Flutter iOS Derlemesi (macOS runner gerektirir) if: runner.os == 'macOS' run: flutter build ios --release --no-codesign ``` ### BÖLÜM 7 - İleri Seviye Teknikler GitHub Actions'ı mobil CI/CD süreçlerinizde daha verimli ve güçlü hale getirecek 2026'nın ileri seviye teknikleri: #### 1. Matrix Stratejileri ile Paralel Çalıştırma Farklı Android SDK versiyonları, Java versiyonları veya hatta farklı test konfigürasyonları için işleri paralel çalıştırmak, test sürelerini önemli ölçüde kısaltır. 2026'da büyük mobil projelerde bu yaklaşım standart hale gelmiştir. ```yaml # .github/workflows/matrix_build.yml name: Matrix Build Example (2026) on: push jobs: test: runs-on: ubuntu-latest strategy: matrix: java: [11, 17] # Farklı Java versiyonlarında test et sdk: [30, 34] # Farklı Android SDK versiyonlarında test et (2026'da güncel SDK'lar) steps: - uses: actions/checkout@v4 - name: Java Kurulumu (JDK ${{ matrix.java }}) uses: actions/setup-java@v4 with: distribution: 'temurin' java-version: ${{ matrix.java }} - name: Android SDK Kurulumu (SDK ${{ matrix.sdk }}) run: |- sdkmanager "platforms;android-${{ matrix.sdk }}" yes | sdkmanager --licenses - name: Gradle Wrapper İzinlerini Ayarla run: chmod +x ./gradlew - name: Testleri Çalıştır run: ./gradlew test ``` #### 2. Yeniden Kullanılabilir İş Akışları (Reusable Workflows) 2026'da büyük kurumsal projelerde, ortak CI/CD adımlarını (örn. bağımlılıkları önbelleğe alma, güvenlik taraması) birden fazla depoda veya iş akışında yeniden kullanmak, DRY (Don't Repeat Yourself) prensibini uygulamak için kritik öneme sahiptir. Bu, bakım maliyetlerini düşürür ve tutarlılığı artırır. **`common_build.yml` (Yeniden kullanılabilir iş akışı):** ```yaml # .github/workflows/common_build.yml name: Ortak Mobil Derleme Adımları (2026) on: workflow_call: # Bu iş akışının diğer iş akışları tarafından çağrılabileceğini belirtir inputs: java_version: required: true type: string gradle_command: required: true type: string jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Java Kurulumu uses: actions/setup-java@v4 with: distribution: 'temurin' java-version: ${{ inputs.java_version }} - name: Gradle Cache uses: actions/cache@v4 with: path: ~/.gradle/caches key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }} restore-keys: |- ${{ runner.os }}-gradle- - name: Gradle Wrapper İzinleri run: chmod +x ./gradlew - name: Gradle Komutunu Çalıştır run: ${{ inputs.gradle_command }} ``` **Ana iş akışı (`main_app_ci.yml`):** ```yaml # .github/workflows/main_app_ci.yml name: Ana Uygulama CI (2026) on: push jobs: call-common-build: uses: ./.github/workflows/common_build.yml # Yerel yeniden kullanılabilir iş akışını çağır with: java_version: '17' gradle_command: './gradlew assembleDebug test' ``` #### 3. Ortamlar ve Secret Yönetimi Üretim ortamı dağıtımları gibi hassas işlemler için ortamları (environments) kullanmak ve `secrets` ile API anahtarları, sertifikalar gibi bilgileri güvenli bir şekilde yönetmek 2026'da vazgeçilmezdir. GitHub Actions, bu konuda güçlü yerleşik özellikler sunar. ```yaml # .github/workflows/production_deploy.yml name: Production Deploy (2026) on: push: branches: - release jobs: deploy-to-prod: runs-on: ubuntu-latest environment: name: production # Ortam koruma kuralları burada tanımlanır steps: - uses: actions/checkout@v4 - name: Java Kurulumu uses: actions/setup-java@v4 with: distribution: 'temurin' java-version: '17' - name: Release APK Derle env: KEYSTORE_FILE: ${{ secrets.PROD_KEYSTORE_FILE }} KEYSTORE_PASSWORD: ${{ secrets.PROD_KEYSTORE_PASSWORD }} # Diğer üretim sırları... run: | echo "$KEYSTORE_FILE" | base64 --decode > app/prod.keystore ./gradlew assembleRelease - name: Prod Ortamına Dağıt # Özel dağıtım adımları (örn. Play Store API veya özel sunucuya SSH) run: echo "Uygulama üretim ortamına dağıtıldı!" ``` ### BÖLÜM 8 - Best Practices & Anti-Patterns GitHub Actions iş akışlarınızı 2026'da verimli, güvenli ve sürdürülebilir hale getirmek için izlemeniz gereken en iyi uygulamalar ve kaçınmanız gereken anti-pattern'lar: #### ✅ Best Practices: 1. **Küçük ve Odaklı İş Akışları:** Tek bir iş akışı dosyasında çok fazla şey yapmaya çalışmayın. Her iş akışı belirli bir amaca hizmet etmeli (örn. test, derleme, dağıtım). Bu, hata ayıklamayı ve bakımı kolaylaştırır. 2. **`uses` ile Aksiyon Versiyonlarını Sabitleyin:** `actions/checkout@v4` gibi belirli bir versiyonu kullanın. `@main` veya `@latest` kullanmak, gelecekteki breaking change'lerin iş akışınızı bozmasına neden olabilir. 2026'da bu, CI/CD güvenilirliği için kritik bir noktadır. 3. **Önbellekleme (Caching) Kullanın:** `actions/cache@v4` ile bağımlılıkları (örn. `node_modules`, `~/.gradle/caches`) önbelleğe alarak iş akışı sürelerini önemli ölçüde kısaltın. Özellikle mobil projelerde bağımlılık yükleme süreleri uzun olabilir. 4. **`secrets` ile Hassas Bilgileri Yönetin:** API anahtarları, sertifikalar, parola gibi hassas bilgileri asla doğrudan YAML dosyasına yazmayın. GitHub Secrets kullanarak bunları güvenli bir şekilde saklayın ve iş akışlarınızda `secrets.MY_SECRET` olarak erişin. 2026 siber güvenlik standartları gereği bu zorunludur. 5. **Minimum İzin Prensibi:** İş akışlarınız ve kullandığınız aksiyonlar için yalnızca ihtiyaç duydukları minimum izinleri verin. Örneğin, sadece `pull_request` olayında okunabilir `GITHUB_TOKEN` kullanın. 6. **İş Akışı Durumunu İzleyin:** `workflow_run` olayını kullanarak bir iş akışının tamamlanmasını bekleyebilir ve ardından başka bir iş akışını tetikleyebilirsiniz. Bu, karmaşık bağımlılıkları yönetmek için 2026'da sıkça kullanılır. 7. **`if` Koşulları ile Kontrol Akışı:** İşleri veya adımları belirli koşullara göre çalıştırmak için `if` ifadelerini kullanın (örn. `if: github.ref == 'refs/heads/main'`). 8. **Self-Hosted Runner'lar (Gerektiğinde):** Eğer özel donanım gereksinimleriniz (örn. belirli bir GPU, özel lisanslı yazılım) varsa veya GitHub'ın sunduğu runner'lar performans veya maliyet açısından yetersiz kalıyorsa, kendi self-hosted runner'larınızı kullanın. 2026'da bu, özel mobil test cihazları veya emülatörler için tercih edilebilir. #### ❌ Anti-Patterns: 1. **Duyarlı Bilgileri Doğrudan YAML'a Yazmak:** En büyük güvenlik ihlallerinden biridir. Asla yapmayın. 2. **`run: | bash -c "..."` ile Çok Uzun Tek Satırlık Komutlar:** Okunabilirliği ve hata ayıklamayı zorlaştırır. Komutları mantıksal olarak ayırın ve her adımda tek bir görevi hedefleyin. 3. **Aşırı Karmaşık `on:` Tetikleyicileri:** İş akışlarınızın ne zaman çalışacağını anlamayı zorlaştırır. Mümkün olduğunca basit ve anlaşılır tutun. 4. **Testleri Atlamak:** CI/CD'nin temel amacı hızlı geri bildirim sağlamaktır. Testleri çalıştırmamak, hatalı kodun üretim ortamına ulaşma riskini artırır. 2026'da test otomasyonu mobil geliştirmenin ayrılmaz bir parçasıdır. 5. **Aksiyonsuz `run` Komutları:** Topluluk tarafından oluşturulmuş aksiyonlar genellikle iyi test edilmiştir ve en iyi uygulamaları içerir. Kendi `run` komutlarınızı yazmadan önce mevcut bir aksiyon olup olmadığını kontrol edin. ### BÖLÜM 9 - Yaygın Hatalar ve Çözümleri GitHub Actions'ı kullanırken 2026'da karşılaşabileceğiniz bazı yaygın sorunlar ve bunların çözümleri: * **Problem:** İş akışı `permissions` hatası veriyor, örneğin artifact yükleyemiyor veya pull request'e yorum yapamıyor. * **Sebep:** İş akışının `GITHUB_TOKEN`'ının yeterli izni yok. * **Çözüm:** İş akışı dosyanızın en üstüne `permissions` bloğu ekleyerek ilgili izinleri verin. Örneğin, `contents: write` veya `pull-requests: write`. ```yaml name: CI/CD on: push permissions: contents: write # Bu iş akışının depoya yazma izni olsun pull-requests: write # Bu iş akışının PR'lara yorum yapma izni olsun jobs: # ... ``` * **Problem:** `actions/checkout@v4` veya `actions/setup-java@v4` gibi aksiyonlar bulunamıyor veya çalışmıyor. * **Sebep:** Yanlış versiyon numarası veya aksiyon adı. * **Çözüm:** GitHub Marketplace'ten aksiyonun doğru adını ve 2026 itibarıyla en güncel kararlı versiyonunu kontrol edin. Örneğin, `v4` yerine `v3` kullanıyor olabilirsiniz. * **Problem:** Gradle veya Maven bağımlılıkları her çalıştırmada yeniden indiriliyor, bu da iş akışını yavaşlatıyor. * **Sebep:** Önbellekleme (caching) doğru yapılandırılmamış veya hiç kullanılmıyor. * **Çözüm:** `actions/cache@v4` aksiyonunu kullanarak `~/.gradle/caches` veya `~/.m2` gibi bağımlılık dizinlerini önbelleğe alın. `key` ve `restore-keys` parametrelerini doğru ayarladığınızdan emin olun. ```yaml - name: Gradle Cache uses: actions/cache@v4 with: path: ~/.gradle/caches key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }} restore-keys: |- ${{ runner.os }}-gradle- ``` * **Problem:** İş akışı yerel olarak çalışıyor ancak GitHub Actions'ta hata veriyor (örn. `command not found`). * **Sebep:** Runner ortamı ile yerel ortam arasındaki farklılıklar (yüklü yazılımlar, PATH değişkeni, izinler). * **Çözüm:** Runner'ın ortamını dikkatlice inceleyin (GitHub Actions loglarında `Set up job` adımı). Eksik bağımlılıkları veya araçları `run` komutlarıyla kurun. Özellikle mobil geliştirme için `sudo apt-get install` veya `brew install` komutları gerekebilir. `chmod +x` ile betiklere yürütme izni verdiğinizden emin olun. ### BÖLÜM 10 - Performans Optimizasyonu GitHub Actions iş akışlarınızın 2026'da mobil projelerinizde daha hızlı ve daha maliyet etkin çalışmasını sağlamak için uygulayabileceğiniz optimizasyon teknikleri: 1. **Akıllı Önbellekleme Kullanımı:** En büyük performans kazançlarından biri önbelleklemedir. Gradle, Maven, npm, Yarn, CocoaPods gibi bağımlılık yöneticilerinin önbelleklerini doğru bir şekilde yapılandırarak, her derlemede bağımlılıkların yeniden indirilmesini engelleyin. `key` değerini dikkatli seçerek cache hit oranını artırın. ```yaml # Önbellek isabet oranını artırmak için daha spesifik anahtar key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }} ``` 2. **Paralel İşler ve Matrix Stratejileri:** Bağımsız adımları veya test süitlerini paralel olarak çalıştırmak, toplam iş akışı süresini dramatik şekilde azaltabilir. Matrix stratejileri, farklı ortamlar veya konfigürasyonlar üzerinde aynı anda test yapmanızı sağlar. * **Önce:** 10 dakika süren seri testler. * **Sonra:** Matrix ile 4 paralel işe bölünen 3 dakikalık testler. 3. **Self-Hosted Runner'lar:** Özellikle macOS tabanlı iOS derlemeleri veya çok büyük Android projeleri için GitHub'ın sağladığı sanal makineler (hosted runners) bazen yetersiz kalabilir. Kendi sunucularınızda veya bulut VM'lerinizde self-hosted runner kurarak daha güçlü donanım (daha fazla CPU, RAM) kullanabilir ve derleme sürelerini kısaltabilirsiniz. 2026'da bazı şirketler, hassas verilerin GitHub'ın genel runner'larında işlenmesini istemediği için de self-hosted runner'ları tercih etmektedir. 4. **Gereksiz Adımları Atlayın:** `if` koşulları kullanarak sadece ilgili durumlarda belirli adımları çalıştırın. Örneğin, `main` branch'ine yapılan push'larda tam dağıtım yaparken, diğer branch'lerde sadece testleri çalıştırın. ```yaml - name: Dağıtım Adımı (Sadece Main Branch) if: github.ref == 'refs/heads/main' run: ./deploy_to_production.sh ``` 5. **Derleme Süreçlerini Optimize Edin:** Mobil projelerinizde derleme süreçlerinin kendisini optimize edin. Örneğin, Android'de `buildSrc` kullanarak Gradle konfigürasyonunu hızlandırabilir, ProGuard/R8 kurallarını iyileştirebilirsiniz. Xcode'da ise `ARCHS` ayarlarını doğru yaparak gereksiz mimarileri derlemeyi önleyebilirsiniz. 6. **Sadece Gerekli Bağımlılıkları Kurun:** İş akışınızda sadece o adım için gerekli olan bağımlılıkları veya araçları kurun. Örneğin, sadece Android derlemesi yapıyorsanız, iOS ile ilgili araçları kurmaya gerek yoktur. ### BÖLÜM 11 - Gerçek Dünya Proje Örneği (Mini Project) Bu bölümde, 2026'da basit bir Android uygulamasını derleyen, test eden ve GitHub Releases'a bir taslak sürüm olarak yükleyen tam bir GitHub Actions iş akışı örneği sunacağız. #### Proje Yapısı: ``` my-android-app/ ├── .github/ │ └── workflows/ │ └── android_release_workflow.yml ├── app/ │ ├── build.gradle │ └── src/ │ └── main/ │ ├── java/ │ └── AndroidManifest.xml ├── build.gradle ├── gradlew └── settings.gradle ``` #### `android_release_workflow.yml`: ```yaml # .github/workflows/android_release_workflow.yml name: Android CI/CD ve GitHub Release (2026) on: push: tags: - 'v*.*.*' # Sadece 'v1.0.0' gibi tag push'larında çalışır jobs: build-and-release: runs-on: ubuntu-latest steps: - name: GitHub Depoyu Klonla uses: actions/checkout@v4 - name: Java Kurulumu (JDK 17) uses: actions/setup-java@v4 with: distribution: 'temurin' java-version: '17' - name: Gradle Cache Ayarları uses: actions/cache@v4 with: path: ~/.gradle/caches key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }} restore-keys: |- ${{ runner.os }}-gradle- - name: Gradle Wrapper İzinlerini Ayarla run: chmod +x ./gradlew - name: Android Release APK Derle env: # Bu sırlar GitHub deponuzun Settings -> Secrets bölümünde tanımlanmalıdır. # Örneğin, bir keystore dosyası base64 encoded olarak saklanabilir. SIGNING_KEY_BASE64: ${{ secrets.ANDROID_SIGNING_KEY_BASE64 }} KEY_STORE_PASSWORD: ${{ secrets.ANDROID_KEY_STORE_PASSWORD }} KEY_ALIAS: ${{ secrets.ANDROID_KEY_ALIAS }} KEY_PASSWORD: ${{ secrets.ANDROID_KEY_PASSWORD }} run: | # Keystore dosyasını sır olarak saklanan base64 string'den oluştur echo "$SIGNING_KEY_BASE64" | base64 --decode > app/release.keystore # Gradle'a keystore bilgilerini geçirmek için environment değişkenlerini kullan ./gradlew assembleRelease \ -Pandroid.injected.signing.store.file=app/release.keystore \ -Pandroid.injected.signing.store.password=$KEY_STORE_PASSWORD \ -Pandroid.injected.signing.key.alias=$KEY_ALIAS \ -Pandroid.injected.signing.key.password=$KEY_PASSWORD - name: Uygulama Testlerini Çalıştır run: ./gradlew test - name: Derlenen APK'yı GitHub Release'a Yükle uses: softprops/action-gh-release@v1 # 2026 itibarıyla güncel rel