GitHub Actions Nedir? CI/CD Otomasyonuna Giriş

Kısa yanıt

GitHub Actions nedir sorusunun kısa cevabı şudur: GitHub Actions, bir yazılım projesindeki test çalıştırma, derleme ve dağıtım gibi tekrar eden işleri doğrudan GitHub deposu içinden otomatikleştiren, GitHub’a yerleşik bir CI/CD (sürekli entegrasyon/sürekli dağıtım) platformudur. Ayrı bir sunucu kurmaya veya üçüncü taraf bir otomasyon aracı eklemeye gerek kalmaz.

Otomasyon, depoya .github/workflows/ klasörü altında eklenen bir YAML dosyasıyla tanımlanır. Kod push edildiğinde, bir pull request açıldığında veya belirlenen başka bir olay gerçekleştiğinde bu dosyada tarif edilen adımlar GitHub’ın kendi sunucularında otomatik olarak çalışır ve sonuç doğrudan ilgili commit veya pull request üzerinde görünür.

GitHub Actions nedir ve ne işe yarar?

GitHub’ın kendi Actions tanıtım sayfasına göre, platform “tüm yazılım iş akışlarını, artık dünya standartlarında CI/CD ile otomatikleştirmeyi kolaylaştırır.” Bu tanım, GitHub Actions’ın yalnızca test çalıştırmakla sınırlı olmadığını, GitHub üzerindeki neredeyse her olaya bağlanabilen genel bir otomasyon katmanı olduğunu gösterir: kod derlemek, konteyner imajı oluşturmak, bir web servisini dağıtmak, açık kaynak bir projeye katkıda bulunan birini otomatik karşılamak veya issue/pull request etiketlemek gibi işler aynı altyapı üzerinden yürütülebilir.

Bu otomasyonun önemi, manuel adımların yarattığı insan hatasını ortadan kaldırmaktan gelir. Bir geliştirici kodu yerel makinesinde test edip “çalışıyor” dediğinde, aynı testlerin tam olarak aynı ortamda, her commit için otomatik ve tutarlı biçimde tekrarlanması güvenceyi GitHub’ın sunucularına taşır. Ekip büyüdükçe bu tutarlılık, kod kalitesini korumanın en pratik yollarından biri haline gelir.

Workflow, job ve step: temel kavramlar

GitHub Actions’ın mantığını oturtmak için üç kavramı birbirinden ayırmak gerekir. Workflow, bir YAML dosyasında baştan sona tanımlanan ve belirli bir olayla tetiklenen otomasyon sürecinin bütünüdür; bir depoda birden fazla workflow dosyası bulunabilir, örneğin biri testler için, biri dağıtım için.

Her workflow bir veya daha fazla job’dan oluşur ve her job varsayılan olarak kendi temiz sanal makinesinde çalışır; job’lar birbirine bağımlı olacak şekilde sırayla veya tamamen paralel çalışacak şekilde tanımlanabilir. Bir job da sırasıyla çalışan step’lere (adımlara) bölünür; her step bir terminal komutu çalıştırabilir veya GitHub Marketplace’teki hazır bir “action”ı (örneğin bir Node.js sürümü kurmak veya bir bağımlılığı önbelleğe almak için yazılmış hazır bir bileşeni) kullanabilir.

Bu üç kavram arasındaki ilişki netleşince bir workflow dosyasını okumak da kolaylaşır: dosyanın tepesinde hangi olayın (on:) tetikleyeceği, altında hangi job’ların, her job’un altında da hangi step’lerin sırayla çalışacağı tanımlanır.

GitHub Actions nasıl çalışır?

Günlük kullanımda süreç genellikle aynı sırayı izler. Önce depoya .github/workflows/ klasörü eklenir ve içine ci.yml gibi bir YAML dosyası yazılır. Bu dosyanın on: bölümünde workflow’un hangi olayda tetikleneceği belirtilir, örneğin main dalına her push’ta veya her pull request açıldığında. Ardından jobs: bölümünde hangi sanal makine ortamında (genellikle ubuntu-latest) hangi adımların çalışacağı sırayla listelenir; bir Node.js projesinde bu adımlar tipik olarak kodu çekmek, bağımlılıkları kurmak, lint çalıştırmak ve testleri çalıştırmak şeklinde sıralanır.

Dosya commit edilip depoya push edildiği anda GitHub, tanımlı olayı algılar ve workflow’u otomatik tetikler; depo içindeki “Actions” sekmesinden çalışmanın gerçek zamanlı loglarını, hangi adımın ne kadar sürdüğünü ve hangi adımda hata çıktığını görmek mümkündür. Bir adım başarısız olduğunda workflow durur ve ilgili pull request üzerinde kırmızı bir uyarı görünür; bu da sorunlu kodun ana dala birleşmeden önce fark edilmesini sağlar.

CI ile CD arasındaki fark

GitHub Actions bağlamında CI ve CD terimleri sık karıştırılır, ama farklı aşamaları ifade eder. CI (Continuous Integration/sürekli entegrasyon), her kod değişikliğinin otomatik testlerden geçirilip ana koda güvenle entegre edilmesini kapsar; amaç, bozuk bir kodun fark edilmeden ana dala girmesini önlemektir. CD (Continuous Delivery veya Continuous Deployment/sürekli teslimat ya da dağıtım) ise bu testlerden geçen kodun otomatik olarak bir test ortamına veya doğrudan canlı ortama dağıtılmasını ifade eder.

GitHub Actions bu ikisini aynı workflow dosyası içinde art arda tanımlamaya izin verir: önce test ve derleme adımları (CI), ardından bunlar başarılı olursa devreye giren bir dağıtım adımı (CD). Bu, birbirinden ayrı araçlar yönetmek yerine tek bir dosyada uçtan uca bir teslimat hattı kurmayı mümkün kılar.

Secrets: gizli bilgileri güvenle kullanmak

Bir dağıtım adımı genellikle bir API anahtarı, bir sunucu erişim bilgisi veya bir bulut sağlayıcı kimlik bilgisi gerektirir. Bu değerler hiçbir zaman doğrudan YAML dosyasına yazılmamalıdır; dosya depo geçmişinde kalıcı olarak görünür hale gelir ve bu bir güvenlik açığıdır. Bunun yerine GitHub deposunun Settings > Secrets and variables bölümünden şifrelenmiş “secret” olarak tanımlanır ve workflow içinde ${{ secrets.ANAHTAR_ADI }} söz dizimiyle çağrılır.

Bu yaklaşım, sızan bir API anahtarının nasıl kötüye kullanılabileceğini ve bir deponun bu riske karşı nasıl korunması gerektiğini ele aldığımız GitHub’da API anahtarı sızıntısı rehberimizde ele aldığımız sorunun doğrudan önleyici bir karşılığıdır: secrets mekanizması kullanıldığında anahtar hiçbir zaman log çıktısında veya commit geçmişinde açık biçimde görünmez.

CI/CD hattında npm/bağımlılık hatalarına dikkat

GitHub Actions ile kurulan bir CI hattının en sık tıkandığı nokta, workflow’un kendisi değil, bağımlılık kurulum adımıdır. Yerel makinede sorunsuz çalışan bir npm install komutu, CI ortamında kilit dosyası (lock file) uyumsuzluğu veya ağ zaman aşımı yüzünden başarısız olabilir ve bu da workflow’u durdurur. Bu tür hataları CI bağlamında ayrı bir sorun sınıfı olarak ele aldığımız npm install hatası rehberimizde anlatılan npm ci kullanımı ve kilit dosyası tutarlılığı önerileri, GitHub Actions workflow’larında da doğrudan geçerlidir.

Hangi ekipler GitHub Actions’tan gerçekten fayda görür?

GitHub Actions her projede zorunlu değildir, ama kodunu zaten GitHub’da tutan bir ekip için öğrenme eğrisi düşüktür çünkü ayrı bir CI aracı kurmaya veya entegre etmeye gerek kalmaz. Şu durumlardan biri geçerliyse workflow kurmak doğrudan karşılığını verir: birden fazla geliştirici aynı depoya katkıda bulunuyorsa ve her pull request’in testten geçtiğinden emin olmak gerekiyorsa, dağıtım süreci hâlâ manuel ve hataya açık adımlardan oluşuyorsa, veya her sürümde aynı kontrol listesini (lint, test, derleme) elle tekrar etmek zaman kaybı yaratıyorsa. Bu senaryoların her biri, GitHub Actions’ın asıl çözdüğü “tekrar eden manuel işi güvenilir otomasyona taşıma” problemine karşılık gelir.

Sık yapılan hatalar

GitHub Actions’a yeni başlayan ekiplerde birkaç hata sık tekrarlanır. En yaygını, gizli bilgileri secrets mekanizması yerine doğrudan workflow dosyasına veya log çıktısına yazmaktır; bu bilgiler commit geçmişinde kalıcı olarak görünür hale gelir. İkinci sık hata, her workflow çalışmasında bağımlılıkları sıfırdan indirmektir; bu hem süreyi hem de kullanılan dakika kotasını gereksiz yere tüketir, oysa actions/cache gibi hazır bir action ile bağımlılık önbellekleme eklemek derleme süresini önemli ölçüde kısaltır. Bir diğer hata, test adımlarını atlayıp doğrudan dağıtım adımına geçmektir; bu, hatalı bir kodun test edilmeden canlıya çıkmasına zemin hazırlar. Son olarak, bir workflow’u çok fazla job ve step’le aşırı karmaşık hale getirmek de yaygın bir hatadır; sorun çıktığında hangi adımın sorumlu olduğunu bulmak zorlaşır, bu yüzden her job’un tek bir sorumluluğu olacak şekilde sade tutulması tercih edilir.

Kontrol listesi

Bir projeye ilk GitHub Actions workflow’unu eklemeden önce şu adımları sırayla değerlendirmek işe yarar:

• Otomatikleştirilecek ilk işi net biçimde belirleyin (test çalıştırma genellikle en güvenli başlangıç noktasıdır).
• Gizli bilgileri workflow dosyasına değil, deponun Secrets bölümüne taşıyın.
• Bağımlılık kurulum adımında npm ci gibi kilitli bir kurulum komutu ve mümkünse önbellekleme kullanın.
• Dağıtım adımını, test adımları başarıyla tamamlandıktan sonra çalışacak şekilde zincirleyin, önce değil.

Sonraki adım

GitHub Actions nedir sorusunun özünde, tekrar eden manuel yazılım işlerini güvenilir ve izlenebilir bir otomasyona dönüştürme ihtiyacı yatıyor. Tek geliştiricili küçük bir proje için zorunlu değil, ama birden fazla kişinin katkıda bulunduğu veya dağıtım sürecini standartlaştırmak isteyen ekipler için kısa sürede karşılığını veren bir yatırım. Otomasyonu ekip kültürü ve altyapı tarafıyla birlikte değerlendirmek isterseniz DevOps nedir rehberimize de bakabilirsiniz.

Ekibinizin CI/CD hattını, dağıtım stratejisini ve altyapısını sıfırdan tasarlamak için özel yazılım geliştirme hizmetimize göz atabilir ya da doğrudan bizimle iletişime geçebilirsiniz. Grup şirketimiz Web Tasarım Ofisi, web projelerinde sunucu altyapısı, dağıtım otomasyonu ve sürekli bakım operasyonlarında destek sağlamaya devam ediyor.

İlgili rehberler

• DevOps nedir
• npm install hatası nasıl çözülür
• GitHub’da API anahtarı sızıntısı ne yapmalı