Bir projeyi teslim etmeye yakınken yaşanan o klasik stres var ya. “Testler geçti mi, build bozuldu mu, biri yanlışlıkla kırdı mı, deploy sırasında bir şey patlar mı?” On yıldır farklı ekiplerde çalışmış biri olarak şunu söyleyebilirim. Bu stresin büyük kısmı teknik değil, süreç problemidir. Süreç otomatik değilse insan yorulur, hata yapar ve her yayın bir kumar gibi hissettirir.
Bu yazıda sana GitHub Actions’ı “YAML yaz, olsun bitsin” seviyesinde anlatmayacağım. Mantığıyla ele alacağız. Kodu otomatik test edip yayınlamanın kolay yolu nasıl kurulur, CI/CD nedir nasıl çalışır, continuous integration ve continuous deployment farkı nedir, GitHub Actions ile otomatik test ve deploy nasıl yapılır hepsini gerçek örnekler üzerinden konuşacağız. Yazının sonunda GitHub Actions ile Otomasyon: CI/CD’ye İlk Adım ifadesinin neden tam isabet olduğunu anlayacaksın.
CI/CD Nedir?
Continuous Integration (CI) Nedir?
CI, ekipteki herkesin yaptığı değişiklikleri sık sık ana koda entegre etmesi ve bu entegrasyonun otomatik kontrollerden geçmesi demektir. Ben CI’ı “erken uyarı sistemi” gibi görüyorum. Ne kadar erken uyarı alırsan, o kadar az hasar oluşur.
Continuous Delivery ve Continuous Deployment Farkı
Continuous Delivery, her değişikliğin canlıya çıkmaya hazır hale gelmesi demektir. Yani otomatik testler ve kontroller biter, paket hazırdır. Yayına çıkarma kararı hala insandadır. Continuous Deployment ise bir adım daha ileri gider. Kontroller geçince sistem otomatik olarak canlıya yayınlar. İkisi arasındaki fark küçük görünür ama kültür olarak büyük fark yaratır.
CI/CD Neden Modern Yazılımın Temelidir?
Çünkü yazılım artık tek seferlik bir teslimat değil. Sürekli değişen, büyüyen ve güncellenen bir canlı organizma gibi. CI/CD bu organizmanın düzenli nefes almasını sağlar. Hız, güven ve tutarlılık getirir.
CI/CD Olmadan Geliştirme Yapılabilir mi?
Elbette yapılır. Ama ekip büyüdükçe ve yayın sayısı arttıkça süreç bir noktada tıkanır. Ben “CI yoksa, sorun yok” diyen ekiplerin bir gün mutlaka büyük bir hata yaşadığını gördüm. Çünkü manuel süreçler er ya da geç çatlar.
Yazılım Geliştirmede Otomasyonun Önemi
Manuel İşlerin Yarattığı Zaman Kaybı
Her pull request’te aynı kontrol listesi. Testleri çalıştır, lint kontrolü yap, build al, sonra bir de paketle. Bu işler tekrar ettikçe insanın enerjisini yer. Otomasyon burada devreye girer ve “tekrarı” senden alır.
İnsan Hatalarını Azaltmak
Hata yapmak insanidir. Ama süreç otomatik olunca “unuttum” bahanesi ortadan kalkar. Ben en çok şunu seviyorum. Otomasyon kimseyi suçlamaz. Sadece sonucu söyler.
Daha Hızlı ve Güvenilir Yayın Süreçleri
Otomasyon ile küçük değişiklikleri daha sık yayınlarsın. Bu da riski düşürür. Büyük tek yayın yerine küçük, kontrollü yayınlar.
Takım Çalışmasında Standartlaşma
Herkesin aynı kontrol kapısından geçmesi, kalitenin ortak bir zemin kazanması demektir. CI/CD kullanarak yazılım projelerinde verimlilik tam olarak burada artar.
GitHub Actions Nedir?
GitHub Actions’ın Temel Tanımı
GitHub Actions, GitHub reposu içinde çalışan bir otomasyon sistemidir. Push, pull request, release gibi olaylara göre iş akışlarını otomatik çalıştırmanı sağlar.
GitHub Actions Ne İşe Yarar?
Testleri otomatik koşar, lint kontrolü yapar, build alır, paketler, deploy eder. Yani “elle yaptığın işleri” bir akışa dönüştürür.
Diğer CI/CD Araçlarından Farkı
En büyük farkı, GitHub ile doğal olarak entegre olmasıdır. Ek bir platforma geçmeden repo içinde süreç kurarsın. Bu özellikle yeni başlayan ekipler için ciddi kolaylık.
Kimler İçin Uygundur?
Tek kişi çalışan geliştiriciden büyük ekiplere kadar herkes için uygundur. Özellikle GitHub üzerinde proje geliştiriyorsan, GitHub Actions ile Otomasyon: CI/CD’ye İlk Adım atmak çok mantıklı bir başlangıç olur.
GitHub Actions Nasıl Çalışır?
Workflow Kavramı
Workflow, GitHub Actions’ın çalıştırdığı senaryodur. “Ne zaman, hangi adımları yapacağız?” sorusunun cevabıdır.
Event (Trigger) Mantığı
Bir workflow’ı tetikleyen olaydır. Push, pull request, schedule, manuel tetikleme. Yani aksiyonun başlangıç düğmesi.
Job ve Step Yapısı
Workflow içinde job’lar vardır. Job içinde de step’ler. Job’lar paralel çalışabilir, step’ler ise sırayla çalışır. Bu yapı, iyi tasarlanırsa hem hızlı hem okunur bir pipeline çıkarır.
Runner Nedir?
Workflow’ın çalıştığı makinedir. GitHub’ın sunduğu runner’lar var, bir de kendi sunucunda çalıştırabileceğin self-hosted runner’lar.
İlk GitHub Actions Workflow’unu Oluşturmak
.github/workflows Dizini
Her şey bu klasörde başlar. Repo içinde .github/workflows klasörü açarsın, workflow dosyalarını buraya koyarsın.
YAML Dosya Yapısı
Workflow’lar YAML ile yazılır. Başta göz korkutabilir ama mantığı oturunca çok sade gelir. Ben YAML için şöyle diyorum. “Kısa ama net konuşmayı seviyor.”
Basit Bir CI Workflow Örneği
İlk hedef, basit olsun. Push ve pull request geldiğinde testleri çalıştır. Bu kadar.
Push ve Pull Request Tetikleyicileri
Örneğin main dalına push olduğunda, ya da bir PR açıldığında workflow çalışır. Böylece “PR açtım ama test ettim mi” sorusu ortadan kalkar.
Basit Test veya Build Adımı
Node.js projesiyse npm ci ve npm test. Python projesiyse pip install ve pytest. Mantık aynı. Bağımlılıkları kur, sonra test et.
CI için Yaygın Kullanım Senaryoları
Kodun Otomatik Test Edilmesi
Bu işin kalbi burası. Her değişiklik testlerden geçsin. Böylece kırılan bir şey varsa hemen görünür olur. Kodu otomatik test edip yayınlamanın kolay yolu dediğimiz şeyin ilk adımı, testleri otomatik koşturmaktır.
Lint ve Format Kontrolleri
ESLint, Prettier, flake8, black. Hangisini kullanıyorsan, pipeline’a ekle. Bu sayede kod standartları kişiye bağlı kalmaz.
Build Sürecinin Otomasyonu
Build alınmadan yayın olmaz. CI içinde build almak, “benim makinede alıyor” problemini bitirir.
Pull Request Kontrolleri
PR açıldığında otomatik kontrol seti çalışır. Sonuçlar net. PR’ın durumu yeşil mi kırmızı mı. Takım içi iletişim de hızlanır.
Frontend Projelerde GitHub Actions
Frontend CI Süreci Nasıl Olmalı?
Frontend’de en kritik şeyler lint, test ve build. Bir de bundle boyutu takibi yapan ekipler var. Bu, performans odaklı projelerde güzel bir adım.
Node.js Tabanlı Projeler
Node sürümünü sabitlemek önemlidir. Aksi halde farklı sürümlerde farklı sonuçlar alınabilir. Pipeline’da node-version belirlemek bu yüzden iyi bir alışkanlık.
Build ve Test Otomasyonu
Özellikle SPA projelerinde build’in başarılı olması çok önemli. Test varsa test, yoksa en azından build ve lint olmalı.
Statik Site ve SPA Senaryoları
Build çıktısını bir yerde yayınlamak istersin. Statik site için otomatik build alıp yayınlamak, GitHub Actions ile otomatik test ve deploy senaryosunun en temiz örneklerinden biridir.
Backend Projelerde GitHub Actions
API Projeleri için CI Akışı
Backend’de testler daha kritik hale gelir. Çünkü küçük bir hata, veri bütünlüğünü bile etkileyebilir. Unit test, integration test ve gerekiyorsa contract test gibi adımlar pipeline’a eklenebilir.
Test ve Coverage Süreçleri
Coverage yüzde takıntısı yapmanı önermem. Ama trendi görmek faydalıdır. Özellikle yeni yazılan modüllerin testlenip testlenmediği netleşir.
Environment Variable Yönetimi
Secrets yönetimi burada devreye girer. API anahtarları, veritabanı bilgileri gibi şeyler repo içine yazılmaz. GitHub Secrets ile yönetilir.
Servis Bağımlılıklarıyla Çalışmak
Bir API projesi genelde veritabanına, cache’e veya başka servisleri kullanır. Actions içinde bu servisleri ayağa kaldırmak mümkün. Bu sayede integration testler daha gerçekçi hale gelir.
GitHub Actions ile Basit CD Senaryoları
Otomatik Deploy Mantığı
CD’nin temel fikri şu. Kontroller geçerse dağıtım otomatik ilerlesin. Bu her zaman canlıya çıkmak demek değil. Staging de olabilir.
Staging ve Production Ayrımı
Benim önerim, yeni başlayan ekiplerin önce staging ile başlaması. Staging’e otomatik deploy, production’a manuel onay. Böylece kontrol sende kalır.
Deploy Öncesi Kontroller
Build başarılı mı, testler geçti mi, güvenlik taraması var mı. CD’ye geçmeden önce bu kapıları netleştirmek gerekir.
CI’dan CD’ye Geçerken Dikkat Edilecekler
İlk hata burada yapılır. “Test yok ama deploy olsun.” Bu yaklaşım risklidir. CI sağlam değilse CD daha da riskli olur.
GitHub Actions Marketplace ve Actions Kullanımı
Reusable Action Nedir?
Başkasının yazdığı veya senin yazdığın tekrar kullanılabilir adımlar. İşin güzel tarafı, çoğu temel ihtiyaç için hazır action bulabilirsin.
Popüler Actions’lar
Node setup, cache yönetimi, docker build, artifact upload gibi birçok standart action var. Bunlar işleri hızlandırır.
Kendi Action’unu Yazmak
Tekrarlanan bir işin varsa, kendi action’unu yazmak mümkündür. Bu, ekip içinde standardı güçlendirir.
Güvenlik ve Kaynak Seçimi
Her action’ı sorgusuz kullanma. Kaynağına, yıldız sayısına, bakım durumuna bak. Çünkü pipeline içine aldığın her şey, süreçlerinin bir parçası olur.
GitHub Actions Kullanırken Sık Yapılan Hatalar
Her Şeyi Tek Workflow’a Koymak
Bir dosyada her şey olunca okunabilirlik düşer. CI ayrı, CD ayrı, scheduled işler ayrı. Ayrıştırmak daha sağlıklı.
Cache Kullanımını İhmal Etmek
Bağımlılıkları her seferinde baştan kurmak pipeline’ı yavaşlatır. Cache kullanımı hız kazandırır.
Uzayan ve Yavaş Pipeline’lar
Pipeline uzadıkça ekip “nasıl olsa uzun sürüyor” diye önemsememeye başlar. Bu da kültürü zedeler.
Log ve Hata Takibini Zorlaştırmak
Adımları net isimlendirmezsen, hata çıktığında nerede patladığını bulmak zor olur. Basit isimler ve düzenli log, çok iş görür.
GitHub Actions ile İyi Bir CI/CD Süreci Nasıl Tasarlanır?
Küçük ve Anlamlı Job’lar
Test job, lint job, build job. Her biri net. Böyle olunca bozulduğunda hızlı teşhis edilir.
Net İsimlendirme ve Okunabilirlik
Job adı “test” ise testtir. “run-things” gibi isimler ileride sorun çıkarır. Okunabilirlik, hız demektir.
Fail Fast Yaklaşımı
Önce hızlı kontroller, sonra ağır işler. Lint başarısızsa build almaya gerek yok. Bu yaklaşım zaman kazandırır.
Sürekli İyileştirme
Pipeline bir kez yazılıp bırakılmaz. Proje büyüdükçe ihtiyaçlar değişir. Pipeline da buna uyum sağlamalı.
GitHub Actions’ın Sınırları
Ne Zaman Yeterlidir?
Küçük ve orta ölçekli projelerde çoğu zaman fazlasıyla yeterlidir. Özellikle GitHub ekosistemi içinde kalmak isteyen ekipler için.
Ne Zaman Daha Gelişmiş Araçlara Geçilmeli?
Çok kompleks orkestrasyon, özel güvenlik gereksinimleri, çoklu ortam yönetimi gibi ihtiyaçlar artarsa farklı araçlar gündeme gelebilir. Ama başlangıç için GitHub Actions gayet güçlü.
GitHub Actions ≠ Tüm DevOps
Bu kısmı netleştirelim. GitHub Actions bir otomasyon aracıdır. DevOps ise kültür, süreç, iletişim ve tekniklerin birleşimidir. Yani Actions tek başına DevOps yapmaz, sadece bir parça sağlar.
CI/CD Öğrenmeye Nereden Başlamalı?
Önce CI Mantığını Anlamak
Benim önerim şu. Önce CI’ı kur. Test, lint, build. Bunlar otursun. Sonra CD adımlarına geç.
Küçük Projelerde Denemek
Kendi küçük repo’larında denemek en hızlı öğrenme yoludur. Büyük projede deneme yapmak riskli olabilir.
Gerçek Proje Akışlarını İncelemek
Açık kaynak projeler burada muhteşem bir okul. CI/CD dosyalarını açıp okumak bile çok şey öğretir. Açık kaynak kültürünün neden önemli olduğunu anlamak için bu içeriğe de göz atabilirsin. Çünkü birçok proje otomasyon alışkanlığını açık kaynakta kazanıyor.
GitHub Actions Bilgisinin Kariyere Etkisi
Modern Geliştirici Yetkinliği
Bugün modern bir geliştiriciden sadece kod yazması beklenmiyor. Kodun nasıl test edildiğini, nasıl paketlendiğini ve nasıl yayınlandığını da bilmesi bekleniyor. GitHub Actions ile Otomasyon: CI/CD’ye İlk Adım burada güçlü bir basamak.
İş İlanlarında CI/CD Beklentisi
Birçok ilanda CI/CD bilgisi artık temel bir madde. “Pipeline kurabiliyor musun?” sorusu sık geliyor.
Junior’dan Mid-Level’a Geçişte Rolü
Junior bir geliştirici genelde “kod yazar”. Mid-level geliştirici ise “süreçleri de düşünür”. Otomasyonu bilen biri, ekip içinde daha hızlı sorumluluk alır.
Sonuç: GitHub Actions ile Otomasyon Bir Başlangıçtır
CI/CD’ye Giriş Kapısı
CI/CD korkutucu görünüyorsa, GitHub Actions en iyi giriş kapılarından biri. Çünkü repo’nun içinde, adım adım ilerleyebiliyorsun.
Daha Güvenli ve Hızlı Geliştirme
Otomasyon, hızdan önce güven sağlar. Güven gelince hız zaten geliyor. CI/CD kullanarak yazılım projelerinde verimlilik böyle artıyor.
Otomasyonu Alışkanlık Haline Getirmek
En iyi otomasyon, ekibin her gün kullandığı otomasyondur. Küçük başla, düzenli geliştir, sonra büyüt. GitHub Actions ile Otomasyon: CI/CD’ye İlk Adım yaklaşımı tam da bunu anlatıyor.
Eğer bu süreçte yol arkadaşına ihtiyacın varsa, pratik odaklı eğitim ve danışmanlık seçenekleri için hizmetler sayfasına göz atabilirsin. Topluluğu daha yakından tanımak istersen hakkımızda bölümü de burada. CI/CD eğitimi ve devops toplulukları yakınımda diyorsan, doğru ortamda pratik yapmak bu yolculuğu çok hızlandırır.
Sık Sorulan Sorular
GitHub Actions ile otomasyon nedir ve ne işe yarar?
GitHub Actions, repo içinde otomatik iş akışları kurmanı sağlar. Testleri çalıştırır, kod kalitesini kontrol eder, build alır ve istersen deploy sürecini otomatikleştirir.
CI/CD nedir ve GitHub Actions bu süreci nasıl kolaylaştırır?
CI/CD, kodun sık sık entegre edilmesi ve güvenli şekilde yayınlanması yaklaşımıdır. GitHub Actions bunu GitHub içinde, ekstra araç kurmadan yapmana yardımcı olur.
GitHub Actions ile ilk CI/CD pipeline nasıl kurulur?
.github/workflows klasörüne bir YAML dosyası ekleyerek başlarsın. Push ve pull request tetikleyicileri tanımlarsın. Ardından bağımlılık kurulumunu, test ve build adımlarını eklersin. İlk aşamada sadece CI kurmak, en sağlıklı başlangıçtır.
Yeni başlayanlar GitHub Actions kullanırken en sık hangi hataları yapar?
Her şeyi tek workflow’a doldurmak, cache kullanmamak, job’ları gereksiz uzatmak ve adımları iyi isimlendirmemek en yaygın hatalardır. Bir de secrets yönetimini ihmal etmek risklidir.
GitHub Actions ve CI/CD eğitimi yakınımda nereden alınabilir?
Uygulamalı öğrenme burada çok önemli. CI/CD eğitimi ve devops toplulukları yakınımda diyorsan, mentorluk ve pratik odaklı çalışmalarla hızlı ilerleyebilirsin. İhtiyacına uygun destek için hizmetler sayfasını inceleyebilir, topluluğu tanımak için hakkımızda bölümüne göz atabilirsin.
Bugün küçük bir adım at. Bir repo seç, sadece test workflow’u kur. O ilk yeşil tik işareti var ya, işte o an otomasyonun gücünü gerçekten hissedeceksin.