Github Actions Yeniden Kullanılabilir İş Akışlarına Dinamik Parametre Geçişi

Modern yazılım geliştirme süreçlerinde otomasyon, hızı ve güvenilirliği artırmanın anahtarıdır. GitHub Actions, bu otomasyonu doğrudan geliştirme ekosisteminize entegre ederek güçlü bir CI/CD platformu sunar. Ancak, projeler büyüdükçe ve karmaşıklaştıkça, farklı ortamlar, hizmetler veya yapılandırmalar için esneklik ihtiyacı ortaya çıkar. Bu makale, GitHub Actions’ın yeniden kullanılabilir iş akışlarına dinamik parametreler nasıl geçirebileceğinizi, böylece süreçlerinizi daha esnek ve güçlü hale getirebileceğinizi adım adım açıklıyor.

Yazılım geliştirme dünyasında sürekli entegrasyon (CI) ve sürekli dağıtım (CD) pratikleri, ekiplerin daha hızlı ve hatasız bir şekilde ürünlerini pazara sunmalarını sağlayan temel taşlardır. GitHub Actions gibi güçlü otomasyon araçları, bu süreçleri otomatize ederek geliştiricilerin daha verimli olmalarına olanak tanır. Ancak, her projenin kendine özgü gereksinimleri ve karmaşıklıkları vardır. Bir yandan geliştirme (dev) ortamına hızlıca bir prototip dağıtmak isterken, diğer yandan test (staging) ve üretim (production) ortamlarına daha kontrollü ve spesifik konfigürasyonlarla dağıtım yapmak isteyebilirsiniz.

İşte tam da bu noktada statik, tek tip iş akışları yetersiz kalmaya başlar. Her ortam, her mikroservis veya her dağıtım senaryosu için ayrı ayrı iş akışları oluşturmak, hem zaman kaybına yol açar hem de bakım maliyetini artırır. Diyelim ki, farklı mikroservisleri farklı AWS bölgelerine dağıtmanız gerekiyor veya bir uygulamanın belirli bir sürümünü birden fazla test ortamında çalıştırmanız gerekiyor. Her senaryo için ayrı bir YAML dosyası yazmak, kısa sürede bir “YAML ormanı” oluşturmanıza neden olabilir. Bu durum, yalnızca kod tekrarına yol açmakla kalmaz, aynı zamanda hataların yayılma riskini de artırır ve iş akışlarının yönetimini zorlaştırır.

Bu zorlukların üstesinden gelmek için, iş akışlarımızın dışarıdan gelen girdilere göre davranışını değiştirebilmesi gerekir. Yani, iş akışlarımızın dinamik olması, çalışma anında parametreler alabilmesi ve bu parametreler doğrultusunda farklı yollar izleyebilmesi hayati önem taşır. Dinamik parametreler, aynı iş akışı tanımını koruyarak, yalnızca girdi değerlerini değiştirerek farklı işlemler gerçekleştirmemizi sağlar. Örneğin, tek bir “deploy” iş akışı ile hem dev hem de prod ortamlarına dağıtım yapabilir, hatta hangi mikroservisin dağıtılacağını belirtebiliriz. Bu yaklaşım, CI/CD süreçlerimizi sadece otomatize etmekle kalmaz, aynı zamanda onları inanılmaz derecede esnek, ölçeklenebilir ve yönetilebilir kılar. Dinamik parametrelerin gücü, GitHub Actions’ı sadece bir otomasyon aracı olmaktan çıkarıp, karmaşık ve modern yazılım projelerinin belkemiği haline getirir.

Temel Kavramlar: GitHub Actions ve Tekrar Kullanılabilir İş Akışları Nelerdir?

GitHub Actions, GitHub deposunda barındırılan yazılım geliştirme yaşam döngünüzdeki görevleri otomatikleştiren bir platformdur. Kod değişikliklerinde otomatik testler çalıştırmak, paketler oluşturmak, dağıtımlar yapmak veya Slack bildirimleri göndermek gibi çeşitli görevleri otomatikleştirebilirsiniz. Her otomasyon adımı, job adı verilen bir veya daha fazla adımdan (step) oluşan bir workflow (iş akışı) içinde tanımlanır. Bu iş akışları, deponuzun .github/workflows dizininde YAML dosyaları olarak bulunur.

GitHub Actions’ın gücünün önemli bir kısmı, iş akışlarının tekrar kullanılabilirliğidir. Büyük projelerde veya birden fazla mikroservisi yöneten ekiplerde, belirli bir görevi (örneğin, bir Docker imajı oluşturma, belirli bir bulut sağlayıcısına dağıtım yapma) birçok farklı iş akışında tekrar tekrar kullanmanız gerekebilir. Her seferinde aynı kodu yazmak yerine, bu mantığı tek bir yeniden kullanılabilir iş akışı içinde kapsülleyebilirsiniz. Bu, DRY (Don’t Repeat Yourself) prensibini uygulayarak kod tekrarını önler, bakım maliyetini düşürür ve tutarlılığı artırır.

Yeniden kullanılabilir iş akışları, workflow_call tetikleyicisi kullanılarak tanımlanır. Bu, başka bir iş akışının (çağıran iş akışı) bu iş akışını bir fonksiyon çağrısı gibi çağırabileceği anlamına gelir. Çağıran iş akışı, uses anahtar kelimesini kullanarak yeniden kullanılabilir iş akışını belirtir ve ona inputs (girdiler) ve secrets (sırlar) sağlayabilir. Bu sayede, aynı dağıtım mantığını farklı parametrelerle birçok kez kullanabiliriz.

# .github/workflows/reusable-deploy.yml (Yeniden Kullanılabilir İş Akışı)
name: Tekrar Kullanılabilir Dağıtım

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
        description: 'Dağıtım ortamı (dev, staging, prod)'
      service_name:
        required: true
        type: string
        description: 'Dağıtılacak servis adı'
    secrets:
      AWS_ACCESS_KEY_ID:
        required: true
      AWS_SECRET_ACCESS_KEY:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Git Repository Check-out
        uses: actions/checkout@v4

      - name: AWS Kimlik Bilgilerini Yapılandır
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1 # Örnek bölge

      - name: Servis ve Ortama Dağıt
        run: |
          echo "Servis ${{ inputs.service_name }} ${{ inputs.environment }} ortamına dağıtılıyor..."
          # Gerçek dağıtım komutları buraya gelecek
          # Örneğin: aws s3 sync ./build s3://${{ inputs.service_name }}-${{ inputs.environment }}-bucket/
          echo "Dağıtım tamamlandı!"

Tekrar Kullanılabilir İş Akışlarına Parametre Geçişi Nasıl Çalışır?

Yukarıdaki örnekte görüldüğü gibi, yeniden kullanılabilir bir iş akışı, workflow_call altında inputs ve secrets tanımlarını barındırır. Bu tanımlar, çağıran iş akışının bu iş akışına hangi verileri sağlaması gerektiğini belirtir. İşte bu parametre geçişinin ana mekanizmaları:

• inputs: Bu anahtar, iş akışının dışarıdan alabileceği yapılandırılabilir değerleri tanımlar. Her girdi için bir id (girişin adı), description (açıklaması), required (zorunlu olup olmadığı), type (veri tipi, örneğin string, boolean, number) ve isteğe bağlı olarak bir default değer belirleyebilirsiniz. Girdiler, iş akışı içindeki adımlarda ${{ inputs.your_input_id }} formatıyla erişilebilir.
• secrets: Hassas bilgiler (API anahtarları, veritabanı şifreleri vb.) için kullanılır. inputs gibi tanımlanır ancak değerleri GitHub Secrets'tan alınır ve iş akışı günlüklerinde maskelenir. İş akışı içinde ${{ secrets.YOUR_SECRET_ID }} formatıyla erişilir.

Bir başka iş akışı, bu yeniden kullanılabilir iş akışını çağırdığında, jobs bölümünde uses anahtar kelimesini kullanır. Örneğin:

# .github/workflows/main.yml (Çağıran İş Akışı)
name: Ana Uygulama Dağıtım Akışı

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      target_environment:
        description: 'Dağıtım Hedefi'
        required: true
        type: string
        default: 'dev'
        options:
          - dev
          - staging
          - prod
      deploy_service:
        description: 'Hangi Servis Dağıtılsın?'
        required: true
        type: string
        default: 'frontend'
        options:
          - frontend
          - backend
          - auth

jobs:
  call_deploy_workflow:
    uses: ./.github/workflows/reusable-deploy.yml@main # Veya bir repo/path@ref
    with:
      environment: ${{ github.event.inputs.target_environment }}
      service_name: ${{ github.event.inputs.deploy_service }}
    secrets:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_PROD_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_PROD_SECRET_ACCESS_KEY }}

Bu çağrı mekanizması sayesinde, reusable-deploy.yml iş akışı aynı mantıkla, çağrıldığı her seferde farklı environment ve service_name girdileriyle çalışabilir. Bu, iş akışı otomasyonunuzda esneklik ve modülerlik sağlar. workflow_dispatch tetikleyicisi ise, iş akışını GitHub UI üzerinden manuel olarak tetiklerken bu dinamik girdileri doğrudan sağlamanıza olanak tanır, bu da ad-hoc dağıtımlar veya testler için idealdir.

Dinamik Parametreler Ne Anlama Geliyor ve Nasıl Tanımlanır?

GitHub Actions bağlamında "dinamik parametreler", iş akışının çalışma zamanında değerleri değişebilen ve bu değerlere göre farklı davranışlar sergileyebilen girdiler anlamına gelir. Bu dinamizm, genellikle bir çağrı yapan iş akışından (caller workflow) veya manuel tetikleyici (workflow_dispatch) aracılığıyla sağlanan inputs kullanılarak elde edilir. Bu girdiler, basit string'lerden karmaşık JSON yapılarına kadar her şeyi temsil edebilir ve iş akışı içinde koşullu mantık, döngüler veya değişken tanımları için kullanılabilir.

Dinamik parametrelerin gücü, özellikle mikroservis mimarilerinde veya birden fazla ortamın (geliştirme, test, üretim) olduğu projelerde ortaya çıkar. Tek bir iş akışı şablonu oluşturarak, bu şablonu farklı parametre setleriyle tekrar tekrar kullanabilirsiniz. Örneğin, "Dağıtım Yap" adında bir iş akışınız olabilir. Bu iş akışına bir environment (ortam: dev, staging, prod) ve bir service_name (servis adı: kullanıcılar, ürünler, ödeme) parametreleri geçirebilirsiniz. İş akışı, bu parametreleri alarak ilgili servisi belirtilen ortama dağıtır. Bu yaklaşım, sadece kodu DRY (Don't Repeat Yourself) tutmakla kalmaz, aynı zamanda CI/CD süreçlerinizi inanılmaz derecede esnek ve bakımı kolay hale getirir.

Dinamik parametreleri tanımlamak ve kullanmak için yeniden kullanılabilir iş akışınızdaki on: workflow_call: inputs: bölümünü ve çağıran iş akışınızdaki with: bölümünü etkin bir şekilde kullanmanız gerekir. İşte bir örnek:

# .github/workflows/dynamic-build-and-deploy.yml (Yeniden Kullanılabilir İş Akışı)
name: Dinamik Derleme ve Dağıtım

on:
  workflow_call:
    inputs:
      target_env:
        required: true
        type: string
        description: 'Dağıtımın yapılacağı hedef ortam (dev, prod)'
      build_arg_tag:
        required: false
        type: string
        description: 'Docker imajı için kullanılacak etiket (varsayılan: latest)'
        default: 'latest'
      run_tests:
        required: false
        type: boolean
        description: 'Testlerin çalıştırılıp çalıştırılmayacağı'
        default: true
    secrets:
      CLOUD_API_TOKEN:
        required: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Kodu Çek
        uses: actions/checkout@v4
      
      - name: Docker İmajı Oluştur
        run: |
          docker build -t my-app:${{ inputs.build_arg_tag }} .
          echo "Docker imajı oluşturuldu: my-app:${{ inputs.build_arg_tag }}"

  test:
    runs-on: ubuntu-latest
    needs: build
    if: ${{ inputs.run_tests == true }} # Dinamik koşullu çalıştırma
    steps:
      - name: Kodu Çek
        uses: actions/checkout@v4
      
      - name: Testleri Çalıştır
        run: |
          echo "Testler çalıştırılıyor..."
          # npm test veya pytest gibi test komutları
          echo "Testler tamamlandı."

  deploy:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - name: Kimlik Doğrulama
        run: |
          echo "Cloud kimlik doğrulaması ${{ secrets.CLOUD_API_TOKEN }} ile yapılıyor..."
          # AWS/Azure/GCP CLI login komutları
      
      - name: ${{ inputs.target_env }} Ortamına Dağıtım
        run: |
          echo "my-app:${{ inputs.build_arg_tag }} imajı ${{ inputs.target_env }} ortamına dağıtılıyor."
          # Gerçek dağıtım komutları (örn: Kubernetes deploy, Serverless deploy)
          echo "Dağıtım başarılı!"

Bu iş akışı, target_env, build_arg_tag ve run_tests gibi parametreler alarak dinamik bir davranış sergiler. Örneğin, run_tests girdisi true olduğunda test işi çalışır, false olduğunda atlanır. Bu, farklı senaryolar için esneklik sağlar.

Gerçek Dünya Senaryosu: Mikroservis Dağıtımı İçin Dinamik Parametre Kullanımı

Büyük ölçekli uygulamalar genellikle birden fazla mikroservisten oluşur. Her mikroservisin kendi dağıtım akışı olabilir, ancak bu akışların çoğu benzer adımları (Docker imajı oluşturma, test etme, buluta dağıtma) içerir. Her mikroservis için ayrı bir iş akışı yerine, tek bir genel "Mikroservis Dağıtımı" iş akışı oluşturup, gerekli parametreleri dinamik olarak geçirebiliriz. Bu, sadece DRY prensibini uygulamakla kalmaz, aynı zamanda yeni bir mikroservis eklendiğinde veya dağıtım süreçleri güncellendiğinde yönetim yükünü büyük ölçüde azaltır.

Vaka Analizi: Çoklu Mikroservis Dağıtımı

Bir e-ticaret platformunuz olduğunu varsayalım. Bu platformda ürünler, kullanıcılar ve siparişler adında üç ana mikroservis bulunuyor. Her servisin kendi deposu ve dağıtım stratejisi var, ancak hepsinin AWS ECS'ye dağıtılması gerekiyor. Ayrıca, geliştirme ve üretim ortamları arasında da farklılıklar var (farklı ECS kümeleri, farklı görev tanımları vb.).

İşte bu senaryo için dinamik parametreleri kullanarak nasıl tek bir yeniden kullanılabilir dağıtım iş akışı oluşturabileceğimize dair bir örnek:

# .github/workflows/reusable-microservice-deploy.yml (Yeniden Kullanılabilir İş Akışı)
name: Mikroservis Dağıtım Şablonu

on:
  workflow_call:
    inputs:
      service_name:
        required: true
        type: string
        description: 'Dağıtılacak mikroservisin adı'
      environment:
        required: true
        type: string
        description: 'Hedef dağıtım ortamı (dev, prod)'
      docker_image_tag:
        required: true
        type: string
        description: 'Dağıtılacak Docker imajının etiketi'
      ecs_cluster_name:
        required: true
        type: string
        description: 'Hedef AWS ECS kümesinin adı'
      ecs_service_name:
        required: true
        type: string
        description: 'Hedef AWS ECS servisinin adı'
      ecs_task_definition_path:
        required: true
        type: string
        description: 'ECS görev tanımı dosyasının yolu'
    secrets:
      AWS_ACCESS_KEY_ID:
        required: true
      AWS_SECRET_ACCESS_KEY:
        required: true
      AWS_REGION:
        required: true

jobs:
  deploy_to_ecs:
    runs-on: ubuntu-latest
    steps:
      - name: Git Repository Çek
        uses: actions/checkout@v4

      - name: AWS Kimlik Bilgilerini Yapılandır
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: ECR Login
        run: |
          aws ecr get-login-password --region ${{ secrets.AWS_REGION }} | docker login --username AWS --password-stdin YOUR_AWS_ACCOUNT_ID.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com

      - name: Görev Tanımını Güncelle ve Dağıt
        id: deploy
        run: |
          # Görev tanımı JSON dosyasını okuyup imaj etiketini güncelleme
          TASK_DEFINITION=$(cat ${{ inputs.ecs_task_definition_path }} | jq \
            --arg SERVICE_NAME "${{ inputs.service_name }}" \
            --arg DOCKER_IMAGE_TAG "${{ inputs.docker_image_tag }}" \
            '.containerDefinitions[0].image = ("YOUR_AWS_ACCOUNT_ID.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com/" + $SERVICE_NAME + ":" + $DOCKER_IMAGE_TAG)')

          # Yeni görev tanımını kaydetme
          echo $TASK_DEFINITION > updated-task-definition.json

          # Yeni görev tanımını AWS'e kaydetme
          aws ecs register-task-definition --cli-input-json file://updated-task-definition.json

          # ECS servisini güncelleme
          aws ecs update-service \
            --cluster ${{ inputs.ecs_cluster_name }} \
            --service ${{ inputs.ecs_service_name }} \
            --task-definition $(aws ecs describe-task-definition --task-definition ${{ inputs.ecs_service_name }} --query "taskDefinition.taskDefinitionArn" --output text)

          echo "${{ inputs.service_name }} servisi, ${{ inputs.environment }} ortamına, ${docker_image_tag} imaj etiketiyle başarıyla dağıtıldı."

Şimdi, bu yeniden kullanılabilir iş akışını kullanarak her mikroservis için nasıl bir dağıtım akışı oluşturacağımızı görelim:

# .github/workflows/deploy-products-dev.yml (Ürünler Servisi Geliştirme Ortamı Dağıtımı)
name: Ürünler Servisi Geliştirme Ortamı Dağıtımı

on:
  push:
    branches:
      - dev
  workflow_dispatch:

jobs:
  call_microservice_deploy:
    uses: ./.github/workflows/reusable-microservice-deploy.yml@main
    with:
      service_name: 'products'
      environment: 'dev'
      docker_image_tag: '${{ github.sha }}' # Commit SHA'sını etiket olarak kullan
      ecs_cluster_name: 'dev-ecommerce-cluster'
      ecs_service_name: 'products-dev-service'
      ecs_task_definition_path: './ecs/products-task-definition.json'
    secrets:
      AWS_ACCESS_KEY_ID: ${{ secrets.DEV_AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.DEV_AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: 'us-east-1' # Geliştirme ortamı için bölge

# .github/workflows/deploy-products-prod.yml (Ürünler Servisi Üretim Ortamı Dağıtımı)
name: Ürünler Servisi Üretim Ortamı Dağıtımı

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  call_microservice_deploy:
    uses: ./.github/workflows/reusable-microservice-deploy.yml@main
    with:
      service_name: 'products'
      environment: 'prod'
      docker_image_tag: 'latest' # Üretim için genellikle latest veya sürüm etiketi
      ecs_cluster_name: 'prod-ecommerce-cluster'
      ecs_service_name: 'products-prod-service'
      ecs_task_definition_path: './ecs/products-task-definition.json'
    secrets:
      AWS_ACCESS_KEY_ID: ${{ secrets.PROD_AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.PROD_AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: 'us-east-1' # Üretim ortamı için bölge

Bu örnekte, aynı reusable-microservice-deploy.yml iş akışı, farklı parametreler (environment, ecs_cluster_name, docker_image_tag vb.) ve farklı AWS sırları ile çağrılarak hem geliştirme hem de üretim ortamları için ürünler servisini dağıtabiliyor. Benzer şekilde, users ve orders servisleri için de bu şablonu kullanarak sadece birkaç YAML dosyası ile tüm dağıtım süreçlerini yönetebilirsiniz. Bu, dağıtım mantığını merkezileştirirken, her servisin ve ortamın kendine özgü gereksinimlerini karşılayacak esnekliği sağlar. Böylece, hem kod tekrarını azaltır hem de CI/CD süreçlerinizin tutarlılığını ve güvenilirliğini artırırsınız.

İleri Düzey Teknikler: Dinamik Listeler ve Karmaşık Veri Yapıları Nasıl Yönetilir?

Basit string veya boolean değerleri geçirmek kolaydır, ancak bazen iş akışlarınızın dinamik olarak oluşturulmuş listeler veya daha karmaşık veri yapılarıyla çalışması gerekebilir. Örneğin, bir test iş akışının, test edilecek modüllerin dinamik bir listesini alması veya bir dağıtım iş akışının, dağıtılacak birden fazla mikroservis için yapılandırma detaylarını alması gerekebilir. GitHub Actions, bu tür senaryolar için güçlü yetenekler sunar.

JSON Dizilerini Giriş Olarak Geçirme ve İşleme

GitHub Actions'taki inputs, sadece string değerleri değil, aynı zamanda string olarak temsil edilen JSON verilerini de kabul edebilir. Bu, dinamik listeler veya anahtar-değer çiftleri gibi karmaşık veri yapılarını tek bir girdi olarak geçirmenizi sağlar. İş akışı içinde, fromJSON ifadesini kullanarak bu JSON string'ini ayrıştırabilir ve üzerinde döngü yapabilir veya belirli özelliklerine erişebilirsiniz.

# .github/workflows/reusable-multi-deploy.yml (Yeniden Kullanılabilir İş Akışı)
name: Çoklu Servis Dinamik Dağıtım

on:
  workflow_call:
    inputs:
      services_to_deploy:
        required: true
        type: string
        description: 'Dağıtılacak servislerin JSON dizisi'
      base_environment:
        required: true
        type: string
        description: 'Temel dağıtım ortamı'

jobs:
  dynamic_deploy:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        service: ${{ fromJSON(inputs.services_to_deploy) }} # JSON dizisini ayrıştır
    steps:
      - name: Servis ${{ matrix.service.name }} Dağıtılıyor
        run: |
          echo "Servis adı: ${{ matrix.service.name }}"
          echo "Versiyon: ${{ matrix.service.version }}"
          echo "Ortam: ${{ inputs.base_environment }}"
          echo "Özel URL: ${{ matrix.service.url_suffix }}"
          # Dağıtım mantığı burada devam edecek
          # Örneğin: docker deploy ${{ matrix.service.name }}:${{ matrix.service.version }} --env ${{ inputs.base_environment }}
          echo "Servis ${{ matrix.service.name }} dağıtım adımı tamamlandı."

Bu iş akışını çağıran başka bir iş akışı şu şekilde görünebilir:

# .github/workflows/caller-multi-deploy.yml (Çağıran İş Akışı)
name: Çağıran Çoklu Dağıtım

on:
  workflow_dispatch:

jobs:
  call_dynamic_deploy:
    uses: ./.github/workflows/reusable-multi-deploy.yml@main
    with:
      base_environment: 'staging'
      services_to_deploy: | # YAML'da çok satırlı string girişi
        [
          {"name": "frontend", "version": "1.2.0", "url_suffix": "web"},
          {"name": "backend-api", "version": "2.1.5", "url_suffix": "api"},
          {"name": "auth-service", "version": "1.0.0", "url_suffix": "auth"}
        ]

Burada, services_to_deploy girdisine bir JSON dizisi olarak karmaşık veriler geçirilir. Yeniden kullanılabilir iş akışı içindeki strategy.matrix, fromJSON fonksiyonunu kullanarak bu diziyi ayrıştırır ve her bir servis objesi için ayrı bir iş (job) örneği oluşturur. Bu, birçok servisi tek bir çağrı ile paralel olarak dağıtmak için inanılmaz derecede güçlü bir yöntemdir.

Koşullu İş Yürütme ve Çıktılar (Outputs)

Dinamik parametreler sadece girdi olarak kullanılmakla kalmaz, aynı zamanda işlerin veya adımların koşullu olarak yürütülmesini sağlamak için de kullanılabilir. Örneğin, bir parametrenin değerine göre belirli bir test paketini çalıştırmak veya belirli bir ortama özgü bir adımı atlamak isteyebilirsiniz. if: ifadesi, bu koşullu mantığı uygulamanın ana yoludur.

# İçinde koşullu adım olan reusable-deploy.yml örneği
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Üretim Ortamına Özgü Ek Adımlar
        if: ${{ inputs.environment == 'prod' }}
        run: |
          echo "Üretim ortamı için özel onay adımı veya güvenlik taraması..."
          # production specific tasks

Ayrıca, yeniden kullanılabilir bir iş akışı, çalışmasının sonucunu çağıran iş akışına outputs aracılığıyla bildirebilir. Bu, bir iş akışının diğerini bilgilendirmesini veya sonraki adımların ilk iş akışının sonucuna göre dinamik olarak kararlar almasını sağlar.

# reusable-deploy.yml içinde outputs tanımlama
on:
  workflow_call:
    # ... inputs ...
    outputs:
      deployment_status:
        description: 'Dağıtımın durumu (success/failure)'
        value: ${{ jobs.deploy.outputs.status }} # deploy işinin çıktısını kullanır
# ...
jobs:
  deploy:
    # ...
    outputs:
      status: ${{ steps.final_status.outcome }} # Adımın çıktısını iş çıktısı yapar
    steps:
      # ...
      - name: Dağıtım Durumunu Kaydet
        id: final_status
        run: echo "status=success" >> "$GITHUB_OUTPUT" # Çıktı değeri belirleme

# Caller workflow'da outputs kullanma
jobs:
call_deploy:
uses: ./.github/workflows/reusable-deploy.yml@main
# ... inputs ...
notify_result:
needs: call_deploy
runs-on: ubuntu-latest
if: ${{ needs.call_deploy.outputs.deployment_status == 'failure' }}
steps:
- name: Dağıtım Hatası Bildirimi
run: |
echo "Dağıtım başarısız oldu! Lütfen kontrol edin."
# Slack veya Email bildirimi

Mobil Uyumlu Raporlama İçin GitHub Actions Çıktılarından Nasıl Faydalanılır?

GitHub Actions iş akışları doğrudan mobil uygulamalar oluşturmaz veya mobil uyumlu web arayüzleri sunmaz. Ancak, bir iş akışının ürettiği çıktılar (örneğin, test sonuçları, dağıtım durumu, performans metrikleri) genellikle çeşitli şekillerde görselleştirilebilir veya raporlanabilir. Bu raporları görüntüleyen bir web arayüzü veya panosu varsa, bu arayüzün mobil uyumlu olması önemlidir. GitHub Actions'ın kendisi HTML üretmezken, elde edilen verileri kullanarak modern, duyarlı web teknolojileriyle mobil uyumlu raporlama panoları oluşturabilirsiniz.

İş akışlarınızdan elde edilen verileri toplamak için şunları yapabilirsiniz:

1. İş Akışı Çıktıları (Outputs): İş akışlarınızın sonunda önemli metrikleri veya durumları outputs olarak tanımlayarak, bunları çağrı yapan iş akışına veya harici bir sisteme (örneğin, API çağrısı ile) iletebilirsiniz.
2. Artifacts: Test raporları (JUnit XML, HTML raporları), kod analizi sonuçları veya log dosyaları gibi daha büyük çıktıları actions/upload-artifact kullanarak depolayabilirsiniz. Bu dosyalar daha sonra indirilebilir ve harici bir raporlama aracıyla işlenebilir.
3. Webhooklar ve API'ler: GitHub Actions içinden özel bir betik çalıştırarak, iş akışı sonuçlarını bir üçüncü taraf hizmetine (Datadog, Grafana, özel bir raporlama servisi) gönderebilirsiniz. Bu servisler, verileri işleyip mobil uyumlu bir şekilde sunabilir.

Bu raporlama panoları veya arayüzleri tasarlanırken, CSS media query'ler gibi standart web geliştirme teknikleri kullanılarak mobil uyumluluk sağlanabilir. İşte çok basit bir HTML ve CSS örneği, GitHub Actions sonuçlarının bir kart düzeninde gösterildiği varsayılarak, nasıl mobil uyumlu hale getirilebileceğini gösterir:

  

    
Frontend Servisi Dağıtımı
    
Durum: Başarılı
    
Ortam: Üretim
    
Versiyon: 1.2.0
    Detayları Gör
  
  

    
Backend API Testleri
    
Durum: Başarısız
    
Ortam: Geliştirme
    
Test Sayısı: 120 (10 hata)
    Detayları Gör
  

/* Genel düzen için stil */
.github-actions-report-container {
display: flex;
flex-wrap: wrap;
gap: 20px;
justify-content: center;
padding: 20px;
}

.github-actions-report-card {
background-color: #f8f9fa;
border: 1px solid #e2e6ea;
border-radius: 8px;
padding: 20px;
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.05);
width: 300px;
flex-shrink: 0;
}

.status-success {
color: green;
font-weight: bold;
}
.status-failure {
color: red;
font-weight: bold;
}

.view-details-btn {
display: inline-block;
margin-top: 15px;
padding: 8px 15px;
background-color: #007bff;
color: white;
text-decoration: none;
border-radius: 5px;
}

/* Mobil cihazlar için stil (768px genişliğin altı) */
@media screen and (max-width: 768px) {
.github-actions-report-container {
flex-direction: column; /* Dikey sıralama */
align-items: center; /* Ortaya hizalama */
padding: 10px;
}
.github-actions-report-card {
width: 90%; /* Daha dar ekranlarda daha geniş */
max-width: 400px; /* Çok büyük mobil cihazlarda çok geniş olmasını engelle */
margin-bottom: 15px; /* Kartlar arasında boşluk */
}
.view-details-btn {
width: 100%; /* Mobil cihazlarda buton tam genişlik */
text-align: center;
}
}

Bu CSS media query örneği, ekran genişliği 768 pikselin altına düştüğünde rapor kartlarının dikey olarak sıralanmasını ve daha fazla yer kaplamasını sağlar. Bu, GitHub Actions'ın ürettiği verilerin son kullanıcıya nasıl mobil dostu bir şekilde sunulabileceğine dair bir kavramsal bir örnektir, doğrudan GitHub Actions YAML'ı içinde değil, ancak onun ürettiği verileri tüketen bir UI katmanında uygulanır.

En İyi Uygulamalar ve Güvenlik İpuçları: Dinamik Parametre Yönetiminde Nelere Dikkat Edilmeli?

Dinamik parametreler, GitHub Actions iş akışlarını inanılmaz derecede esnek hale getirirken, aynı zamanda belirli güvenlik ve yönetim zorluklarını da beraberinde getirebilir. Bu potansiyel riskleri en aza indirmek ve iş akışlarınızın güvenilirliğini artırmak için bazı en iyi uygulamaları takip etmek hayati önem taşır.

1. Girdi Doğrulama ve Sanitizasyon (Input Validation and Sanitization):
   • Giriş Tipi (type): Mümkün olduğunca spesifik veri tipleri (string, boolean, number) kullanın. GitHub Actions, bu tipleri zorlayarak hatalı girdileri yakalamanıza yardımcı olur.
   • options Kullanımı: Eğer bir parametrenin alabileceği değerler sınırlıysa, workflow_dispatch tetikleyicisiyle birlikte options özelliğini kullanarak kullanıcının önceden tanımlı seçenekler arasından seçim yapmasını sağlayın. Bu, hatalı veya kötü niyetli girdilerin geçişini engeller.
   • YAML İçinde Kontroller: Karmaşık senaryolarda, iş akışı içinde if koşulları veya basit düzenli ifade (regex) kontrolleri kullanarak girdilerin beklenen format veya değere sahip olup olmadığını doğrulayın. Örneğin, bir branch adının belirli bir desene uyup uymadığını kontrol edebilirsiniz.
   • Komut Enjeksiyonu Riski: Dinamik girdileri doğrudan bir kabuk komutuna geçirmeden önce dikkatli olun. Kötü niyetli bir kullanıcı, komut enjeksiyonuyla sisteminize zarar verebilir. Daima girdileri tırnak içine alın (örneğin, run: my-command "${{ inputs.dynamic_value }}") ve mümkünse komut argümanı olarak geçirin, doğrudan kabuk komutunun içine enjekte etmeyin.
2. Sırlar için En Az Ayrıcalık Prensibi (Least Privilege Principle for Secrets):
   • Hassas bilgileri (API anahtarları, şifreler) asla inputs olarak geçirmeyin. Bunun yerine daima secrets kullanın.
   • secrets tanımlarken, yalnızca belirli bir iş akışının veya işin ihtiyaç duyduğu sırları sağlayın. Tüm sırlar dosyasını bir iş akışına açıkça ifşa etmeyin.
   • Ortam bazlı sırları ayırın (örneğin, DEV_AWS_KEY, PROD_AWS_KEY) ve iş akışının yalnızca çalıştığı ortama ait sırlara eriştiğinden emin olun.
3. Yeniden Kullanılabilir İş Akışlarını Sürümleme (Versioning Reusable Workflows):
   • Yeniden kullanılabilir iş akışlarınızı her zaman bir sürüm etiketi (tag) veya belirli bir commit SHA'sı ile çağırın (örneğin, .github/workflows/my-workflow.yml@v1 veya my-org/my-repo/.github/workflows/my-workflow.yml@a1b2c3d). Bu, iş akışınızın beklenmedik değişikliklerden etkilenmesini önler ve tutarlılığı sağlar.
   • @main gibi branch isimleri kullanmaktan kaçının, çünkü bu, ana branch'teki her değişiklikle iş akışının davranışının da değişebileceği anlamına gelir.
4. Açık ve Kapsamlı Dokümantasyon:
   • Yeniden kullanılabilir iş akışlarınızdaki her input için net ve açıklayıcı bir description sağlayın. Bu, iş akışınızı kullanacak diğer geliştiricilerin hangi parametrelerin ne işe yaradığını anlamasına yardımcı olur.
   • İş akışının beklenen davranışını, girdi aralığını ve herhangi bir özel gereksinimi açıklayan harici bir README veya wiki belgesi bulundurun.
5. required ve default Değerleri Etkin Kullanma:
   • Bir girdinin mutlaka sağlanması gerekiyorsa required: true olarak işaretleyin. Bu, eksik girdilerin derleme zamanında hatalara yol açmasını sağlar.
   • Mümkün olduğunca default değerler sağlayın. Bu, iş akışını çağıranların yalnızca varsayılan değerden farklı parametreleri belirtmesini gerektirerek iş akışının kullanımını basitleştirir.
6. Kapsamlı Test ve Geri Alma Yeteneği:
   • Dinamik parametrelere sahip iş akışlarını, mümkün olan tüm parametre kombinasyonlarıyla test edin. Özellikle farklı ortamlar veya koşullar için belirlenmiş yolların doğru çalıştığından emin olun.
   • Bir problem durumunda hızlıca geri alabilmek için iş akışlarınızı modüler tutun ve değişiklikleri küçük adımlarla uygulayın.

Bu en iyi uygulamaları takip ederek, GitHub Actions iş akışlarınızın hem esnek hem de güvenli kalmasını sağlayabilir, dinamik parametrelerin tüm avantajlarından tam olarak yararlanabilirsiniz.

Sonuç: GitHub Actions ile CI/CD Süreçlerinizi Nasıl Otomatikleştirebilirsiniz?

GitHub Actions'ın yeniden kullanılabilir iş akışlarına dinamik parametreler geçirme yeteneği, modern CI/CD süreçlerini yönetme biçimimizde devrim niteliğinde bir esneklik ve güç sunar. Bu makalede ele aldığımız teknikler sayesinde, artık her senaryo, her ortam veya her mikroservis için ayrı ayrı iş akışları yazmak zorunda değilsiniz. Bunun yerine, tek, genel, parametre odaklı iş akışları oluşturarak kod tekrarını en aza indirebilir, bakım maliyetlerini düşürebilir ve geliştirme süreçlerinizin tutarlılığını artırabilirsiniz.

Dinamik parametreler, basit string girdilerinden JSON dizilerine kadar karmaşık veri yapılarını yönetme kabiliyetiyle, ekiplerin daha modüler, ölçeklenebilir ve yönetilebilir otomasyon çözümleri oluşturmasını sağlar. Bu, özellikle büyük ve hızla büyüyen projelerde, farklı dağıtım ortamları, test stratejileri veya mikroservisleri yönetirken kritik öneme sahiptir. Ayrıca, bu yetenek, geliştiricilere iş akışlarını daha hassas bir şekilde kontrol etme imkanı sunarken, manuel müdahaleyi azaltarak hata potansiyelini düşürür.

GitHub Actions'ı bu ileri düzey tekniklerle birleştirmek, CI/CD süreçlerinizi sadece otomatikleştirmekle kalmaz, aynı zamanda onları "akıllı" hale getirir. İş akışlarınız artık statik bir dizi komut olmaktan çıkıp, projenizin ihtiyaçlarına dinamik olarak adapte olabilen canlı, nefes alan varlıklara dönüşür. Bu, ekiplerin daha hızlı yineleme yapmasına, daha güvenli dağıtımlar gerçekleştirmesine ve nihayetinde daha iyi yazılımlar sunmasına olanak tanır. Unutmayın ki, bu gücü kullanırken girdi doğrulama, sır yönetimi ve sürümleme gibi en iyi uygulamalara uymak, otomasyon altyapınızın sağlam ve güvenli kalmasını sağlayacaktır.

Sıkça Sorulan Sorular (SSS)

1. Dinamik parametreler ile GitHub Actions sırları (secrets) arasındaki fark nedir?

Dinamik parametreler (inputs), iş akışının çalışma zamanında davranışını değiştirmek için kullanılan, genellikle hassas olmayan yapılandırma değerleridir (örneğin, ortam adı, servis adı, Docker etiketi). Bunlar genellikle çağrı yapan iş akışı tarafından açıkça sağlanır ve günlüklerde görünebilir. Sırlar (secrets) ise, API anahtarları, şifreler, erişim tokenları gibi hassas bilgilerdir. GitHub tarafından otomatik olarak maskelenirler ve günlüklerde görünmezler. Hassas bilgiler asla dinamik parametre olarak geçirilmemeli, daima GitHub Secrets olarak yönetilmelidir.

2. Yeniden kullanılabilir bir iş akışına birden fazla dinamik parametre geçirebilir miyim?

Evet, kesinlikle. Yeniden kullanılabilir iş akışınızdaki workflow_call: inputs: bölümünde istediğiniz sayıda input tanımlayabilirsiniz. Çağıran iş akışı, bu girdilerin her birini with: anahtar kelimesi altında uygun değerlerle sağlayabilir. Bu, iş akışlarınızı son derece esnek hale getirmenizi sağlar.

3. Dinamik parametrelerin varsayılan değerleri olabilir mi?

Evet, bir input tanımlarken default anahtarını kullanarak bir varsayılan değer belirleyebilirsiniz. Eğer çağıran iş akışı bu girdiyi sağlamazsa, yeniden kullanılabilir iş akışı tanımlanan varsayılan değeri kullanır. Bu, iş akışlarının kullanımını basitleştirir ve bazı parametrelerin isteğe bağlı olmasını sağlar.

4. Dinamik parametreleri kullanarak koşullu adımlar veya işler çalıştırabilir miyim?

Evet, bu dinamik parametrelerin en güçlü kullanım alanlarından biridir. İş akışı adımlarınızda veya işlerinizde if: koşulunu kullanarak dinamik parametrelerin değerlerine göre belirli eylemlerin tetiklenip tetiklenmeyeceğini kontrol edebilirsiniz. Örneğin, if: ${{ inputs.environment == 'prod' }} ile sadece üretim ortamında çalışacak adımlar tanımlayabilirsiniz.

5. Dinamik bir listedeki her öğe için bir işi nasıl çalıştırırım?

JSON formatında bir liste veya dizi alan dinamik bir parametre geçirebilir ve bunu fromJSON ifadesiyle ayrıştırabilirsiniz. Ardından, yeniden kullanılabilir iş akışınızdaki jobs bölümünde strategy.matrix kullanarak bu ayrıştırılmış listenin her öğesi için paralel veya sıralı olarak ayrı işler çalıştırabilirsiniz. Bu, özellikle çoklu mikroservis dağıtımı veya test senaryoları için çok etkilidir.