CI/CD with GitHub Actions & DevOps Pipelines · Ders

Depolar Arası İş Akışları

Bağımlılıkları yönetmek ve karmaşık dağıtımları düzenlemek için farklı depolardaki iş akışlarını birbirine bağlamayı öğrenin.

Depolar Arası İş Akışları, CoddyKit'te ücretsiz bir CI/CD with GitHub Actions & DevOps Pipelines dersidir. Bu, 4 dersinin 2. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, CI/CD with GitHub Actions & DevOps Pipelines öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. CI/CD with GitHub Actions & DevOps Pipelines kursu toplamda 4 dersten oluşur.

Depolar Arası İş Akışlarına Giriş

Modern yazılım geliştirmede uygulamalar genellikle farklı depolara dağılmış birden çok bileşenden oluşur. Mikro hizmetleri, paylaşılan kitaplıkları veya ayrı dağıtım yapılandırmalarını düşünün.

Bu farklı depolar arasındaki iş akışlarını düzenlemek, daha fazla modülerlik ve sorumlulukların ayrılmasını sağlar. Bu derste bunun GitHub Actions ile nasıl gerçekleştirileceği ele alınmaktadır.

Depolar Arası Düzenleme Neden Gerekli?

Geleneksel olarak GitHub Actions iş akışlarının kapsamı tek bir depoyla sınırlıdır. Ancak şunlara ihtiyacınız olursa ne olur:

Bir depoda yapıt oluşturup başka bir depoda dağıtımı tetiklemek?
Birden çok hizmet deposundaki güncellemeleri tetikleyecek paylaşılan bir yapılandırma deposu?
Merkezi bir depoda yönetilen güvenlik ilkelerini diğer tüm depolarda uygulamak?

Depolar arası iş akışları bu karmaşık senaryolar için çözüm sunar.

Depoları Bağlama: `repository_dispatch`

GitHub Actions, repository_dispatch adlı özel bir olay türü sunar. Bu, GitHub depolarınız için özel bir web kancası gibi çalışır.

Bir iş akışı ('gönderen') GitHub'a bir API isteği gönderir.
Başka bir depodaki diğer iş akışı ('alıcı') bu özel olayı dinler.

Bu, iş akışlarının farklı depolar arasında program aracılığıyla tetiklenmesini sağlar.

Alıcı İş Akışını Ayarlama

Bir repository_dispatch olayını almak için hedef depodaki bir iş akışının bu olayı dinleyecek şekilde yapılandırılması gerekir. Bu işlem on: anahtar sözcüğü kullanılarak yapılır.

repo-B içindeki bir iş akışı şöyle görünebilir:

name: Receive Dispatch Event

on:
  repository_dispatch:
    types: [my-custom-event]

jobs:
  process-event:
    runs-on: ubuntu-latest
    steps:
      - name: Log event payload
        run: |
          echo "Event type: ${{ github.event.action }}"
          echo "Payload: ${{ toJSON(github.event.client_payload) }}"

Alıcı Yapılandırmasını Anlama

Önceki örnekte:

on: repository_dispatch:, GitHub'a bu olayı dinlemesini söyler.
types: [my-custom-event], bu iş akışının yalnızca gönderilen olay my-custom-event türündeyse çalışacağını belirtir. Birden çok tür tanımlayabilirsiniz.
github.event.action, olay türünü (örneğin, my-custom-event) içerir.
github.event.client_payload, gönderimle birlikte yollanan özel verileri barındırır.

Olayı Tetikleme: Başka Bir Depodan Gönderme

Bir repository_dispatch olayını tetiklemek için GitHub API'sine bir HTTP POST isteği göndermeniz gerekir. Bu işlem, başka bir GitHub Actions iş akışının veya betiğin içinden curl ya da GitHub CLI (gh cli) kullanılarak yapılabilir.

Temel gereksinimler:

Hedef deponun sahibi ve adı.
Alıcı iş akışının dinlediği bir olay type değeri.
Özel veriler için bir client_payload.
repo kapsamına sahip bir GitHub Kişisel Erişim Belirteci (PAT).

Örnek: `gh cli` ile Olay Gönderme

Burada, repo-A içinden repo-B'ye olay gönderen bir iş akışı görüyorsunuz. Belirteç için nasıl bir gizli bilgi kullandığımıza ve bir client_payload aktardığımıza dikkat ediniz.

name: Trigger Deploy Workflow

on:
  push:
    branches: [main]

jobs:
  dispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install GitHub CLI
        run: sudo apt-get update && sudo apt-get install gh -y

      - name: Dispatch event to repo-B
        env:
          GH_TOKEN: ${{ secrets.CROSS_REPO_PAT }}
        run: |
          gh api \
            --method POST \
            -H "Accept: application/vnd.github.v3+json" \
            /repos/YOUR_ORG/repo-B/dispatches \
            -f event_type='my-custom-event' \
            -f client_payload='{"ref":"${{ github.ref }}", "sha":"${{ github.sha }}"}'

Depolar Arası Erişimi Güvenli Hale Getirme

Bir iş akışına sağlanan varsayılan GITHUB_TOKEN, iş akışının çalıştığı depoyla sınırlıdır. *Başka* bir depoda olayları tetiklemek için daha geniş izinlere sahip bir belirteç gerekir.

Kişisel Erişim Belirteci (PAT) ve repo kapsamını kullanınız.
Bu PAT'yi tetikleyen depoda bir depo gizli bilgisi (ör. CROSS_REPO_PAT) olarak saklayınız.
PAT'leri hiçbir zaman doğrudan iş akışı dosyalarınıza sabit olarak yazmayınız.

`client_payload` ile Özel Veri Aktarma

client_payload, bir olay gönderirken ekleyebileceğiniz bir JSON nesnesidir. Tetikleyen iş akışından alıcı iş akışına bağlam veya veri aktarmak için bu özellik kritik önem taşır.

Aktarabileceğiniz veri örnekleri:

Derlemeyi tetikleyen işlemenin SHA değeri veya dal adı.
Bir ortam hedefi (ör. "staging", "production").
Dağıtılacak bir yapıtın sürüm numarası.

Unutmayınız: client_payload iş akışı günlüklerinde görünür; bu nedenle hassas bilgilerden kaçınınız.

Depolar Arası İş Akışları Hakkında Hızlı Kontrol

Farklı GitHub depoları arasında iş akışlarını nasıl düzenleyeceğinizi öğrendiniz. Şimdi temel bileşenleri anlayıp anlamadığınızı test edelim.

Özet: Depolar Arası Düzenleme

repository_dispatch kullanarak depolar arası iş akışlarını başarıyla uygulamayı öğrendiniz!

Neden: Birden fazla depodaki bağımlılıkları yönetmek ve karmaşık dağıtımları düzenlemek için.
Nasıl: Bir 'gönderici' iş akışı GitHub'a API çağrısı yaparak başka bir depodaki 'alıcı' iş akışını tetikler.
Temel nokta: repository_dispatch olay türü ve alıcı iş akışındaki eşleşen types değerleri.
Veri: İş akışları arasında hassas olmayan bilgileri aktarmak için client_payload kullanınız.
Güvenlik: Depolar arası erişim için her zaman gizli bilgi olarak saklanan, repo kapsamına sahip bir PAT kullanınız.

Bu güçlü özellik, son derece esnek ve birbirinden ayrıştırılmış CI/CD işlem hatlarının oluşturulmasını sağlar.

Sıkça Sorulan Sorular

“Depolar Arası İş Akışları” dersi ücretsiz mi?

Evet — “Depolar Arası İş Akışları” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve CI/CD with GitHub Actions & DevOps Pipelines kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. CI/CD with GitHub Actions & DevOps Pipelines kursu toplamda 4 dersten oluşur.

“Depolar Arası İş Akışları” dersinde ne öğreneceğim?

Bağımlılıkları yönetmek ve karmaşık dağıtımları düzenlemek için farklı depolardaki iş akışlarını birbirine bağlamayı öğrenin. CI/CD with GitHub Actions & DevOps Pipelines ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

CI/CD with GitHub Actions & DevOps Pipelines öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te CI/CD with GitHub Actions & DevOps Pipelines, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 2. dersidir.

“Depolar Arası İş Akışları” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu CI/CD with GitHub Actions & DevOps Pipelines dersinde kod yazıp çalıştırabilir miyim?

Evet. Her CI/CD with GitHub Actions & DevOps Pipelines dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← CI/CD with GitHub Actions & DevOps Pipelines Sayfasına Dön