CI/CD (Continuous Integration / Continuous Delivery), kod değişikliklerini daha hızlı doğrulamak (CI) ve teslimata daha kontrollü yaklaştırmak (CD) için otomasyondan yararlanan bir yaklaşımdır. GitHub Actions ise bu otomasyonu doğrudan GitHub deponuz içinde, olay-temelli (event-driven) workflow dosyalarıyla kurmanızı sağlar. Başlangıç için en doğru referans noktası, GitHub Actions’ın resmi dokümantasyonudur: https://docs.github.com/en/actions/automating-your-workflow-with-github-actions

Bu yazıda önce GitHub Actions’ın temel yapı taşlarını netleştirip, ardından her push ve pull request’te otomatik test koşan minimal bir CI workflow’u kuracağız. Son olarak, “deploy” adımını eklerken en güvenli ve yönetilebilir sınırları nasıl çizeceğinizi ele alacağız.

GitHub Actions ile CI/CD: Temel kavramlar

• Workflow (iş akışı): Depoda .github/workflows altında duran YAML dosyasıdır. Ne zaman ve hangi adımların çalışacağını tarif eder. Örnek kurulum: https://docs.github.com/actions/tutorials/create-an-example-workflow
• Event (tetikleyici): Workflow’u başlatan olaydır (örn. push, pull_request).
• Job: Workflow içindeki çalışma birimi. Bir workflow birden fazla job içerebilir; job’lar bağımlılıkla zincirlenebilir.
• Step: Job içindeki adımlar. Bir komut çalıştırabilir (run) veya hazır bir action çağırabilir (uses).
• Runner: Job’ın çalıştığı ortam (örn. GitHub-hosted ubuntu-latest).

Adım adım: İlk CI workflow’unuzu kurun

1) Ön koşullar

• GitHub üzerinde bir repo (public/private).
• Yerelde çalışan bir test komutu (örn. npm test veya pytest).

2) Workflow dosyasını oluşturun

Repoda şu dosyayı oluşturun:

• .github/workflows/ci.yml

GitHub’ın “örnek workflow” dokümanı, dosya konumu ve temel anahtarları adım adım anlatır: https://docs.github.com/actions/tutorials/create-an-example-workflow

3) Çalışan (geçerli) minimal YAML örneği

Aşağıdaki örnek, main dalına gelen push ve pull_request olaylarında çalışan, Node.js için minimal bir “test” job’ı içerir. (Kendi projenize göre komutları ve runtime adımını uyarlayın.)

Bu akışın mantığı (workflow’un yapısı, runs-on, steps, uses, tetikleyiciler) GitHub’ın resmi örnek anlatımıyla uyumludur. Ayrıntılar için: https://docs.github.com/actions/tutorials/create-an-example-workflow

4) Çalıştırın ve sonucu kontrol edin

Dosyayı commit edip GitHub’a gönderdiğinizde, repo içindeki Actions sekmesinde ilk çalıştırmayı görmelisiniz.

• Workflow beklediğiniz olayda mı tetikleniyor (push/PR)?
• Test komutu gerçekten testleri çalıştırıyor mu?
• Runner ortamı projenizle uyumlu mu (sürüm/bağımlılıklar)?

Pipeline’ı büyütme: Job’ları ayırma ve kontrollü “deploy” yaklaşımı

Proje büyüdükçe tek job içinde her şeyi yapmak yerine işi parçalara ayırmak yönetimi kolaylaştırır: ör. lint, test, build, deploy. Ayrıca “deploy” adımını genelde şu şekilde sınırlandırmak daha güvenli bir başlangıçtır:

• PR’larda: test (ve gerekiyorsa build) çalışsın.
• Main’e merge sonrası: deploy çalışsın (veya sadece tag/release ile).

GitHub Actions ile CI/CD otomasyonu kurgularken temel yaklaşım ve örnekler için başlangıç sayfası: https://docs.github.com/en/actions/automating-your-workflow-with-github-actions

Kurumsal perspektiften bakıldığında, otomasyonun süreklilik hedefleriyle ilişkisi ve DevSecOps olgunluğu gibi konular için SEI (CMU) çerçevesi yararlı bir okuma sağlar: https://www.sei.cmu.edu/blog/a-framework-for-devsecops-evolution-and-achieving-continuous-integrationcontinuous-delivery-cicd-capabilities/

Güvenlik: GITHUB_TOKEN ve permissions için pratik yaklaşım

Workflow’lar GitHub API ile konuşmak gerektiğinde çoğu zaman GITHUB_TOKEN kullanır. GitHub dokümantasyonu, bu token ile kimlik doğrulama ve permissions ile yetkileri kısıtlama yaklaşımını anlatır: https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token

1) En az yetki (least privilege) ile başlayın

İhtiyacınız yoksa yazma yetkilerini kapalı tutmak iyi bir başlangıçtır. Örneğin yalnızca repo içeriğini okumak yeterliyse:

permissions:
 contents: read

2) Deploy adımında yetki/erişim hataları için kontrol listesi

• Deploy job’ı yalnızca hedef dal/tag’de mi çalışıyor?
• Workflow/job permissions, gereken işlemleri (örn. paket yazma, release oluşturma) engelliyor olabilir mi?
• Hedef platforma ait kimlik doğrulama ve dağıtım adımları, sağlayıcının resmi yönergelerine göre mi kuruldu?

Sık karşılaşılan sorunlar

Workflow tetiklenmiyor

• Dosya yolu doğru mu? .github/workflows altında olmalı.
• on altında branch filtreleri (örn. main) doğru mu?

Runner’da bağımlılık/test hatası alıyorum

• Yerelde çalışan komutlar runner ortamında da aynı şekilde çalışıyor mu?
• Runtime sürümü proje beklentinize uygun mu (örn. Node sürümü)?

Sonuç

GitHub Actions ile CI/CD’e başlamak için en pratik yol: push ve pull_request tetikleyicileriyle çalışan, her değişiklikte otomatik test koşan bir CI workflow’u kurmaktır. Sonrasında deploy adımını, yalnızca belirli dal/tag’lerde çalışacak şekilde kontrollü kurgulamak; hız ve güven dengesini korumaya yardımcı olur. Temel yapı taşları ve örnekler için GitHub’ın resmi dokümantasyonunu referans alarak ilerleyin.