CI/CD Nedir? GitHub Actions ile Otomatik Deploy

Meta Description

CI/CD nedir? GitHub Actions ile test, build ve otomatik deploy’u adım adım kurun. Hataları azaltın, yayın hızını artırın.

Giriş (Introduction)

Ürünü yayınlamak çoğu ekipte hâlâ “sunucuya bağlan, komut çalıştır, umarım bozulmaz” ritüeliyle ilerliyor. Bir noktada tek bir yanlış komut, eksik env değişkeni veya unutulan migration; hem kullanıcıyı hem ekibi yakabiliyor.

İşte bu yüzden CI/CD (Continuous Integration / Continuous Delivery-Deployment) artık “kurumsal lüks” değil, küçük ekipler ve girişimler için bile bir hayatta kalma standardı. Bu yazıda CI/CD nedir sorusunu netleştirip, GitHub Actions ile sıfırdan otomatik deploy kurgusunu adım adım kuracağız.

Okuyunca şunları yapabilir olacaksınız: her push’ta testlerin otomatik çalışması, build alınması, sürümün paketlenmesi ve güvenli şekilde sunucuya deploy edilmesi.

Ana İçerik

1) CI/CD Nedir? (Kısa ama Net)

CI (Continuous Integration): Koda her değişiklik geldiğinde (push/PR), otomatik olarak testlerin çalışması ve hataların erken yakalanması.

CD (Continuous Delivery/Deployment):

• Continuous Delivery: Build çıktısı otomatik hazırlanır; prod’a almak tek onay ile olur.
• Continuous Deployment: Testler geçerse prod’a otomatik alınır.

Bunu neden yapmalıyım?

• Yayın süresi kısalır (dakikalar)
• “Bende çalışıyordu” problemleri azalır
• Geri alma (rollback) daha kolay olur
• Yeni geliştirici onboarding’i hızlanır

LSI anahtar kelimeler: otomatik deploy, pipeline, build & test otomasyonu, release yönetimi, GitHub Actions workflow.

2) GitHub Actions Neden Popüler? Alternatiflerle Kıyas

GitHub Actions’ın en büyük avantajı, kodun zaten GitHub’ta olduğu yerde pipeline’ın da yönetilmesi.

3) Hedef Senaryo: Node.js API’yi Sunucuya Otomatik Deploy

Gerçek hayatta sık görülen bir senaryo kuralım:

• Repo: Node.js (örnek: Express/Nest)
• Her main push’unda:
  1. npm ci
  2. test
  3. build
  4. paketle
  5. sunucuya kopyala
  6. servisi yeniden başlat (PM2/systemd)

Not: Docker kullanan ekiplerde “paketle” kısmı yerine image build/push + server pull yapılır. Bu yazıda Docker’sız klasik VPS senaryosu üzerinden gideceğim.

4) Ön Hazırlık: Sunucuyu ve Güvenliği Doğru Ayarla

4.1 Sunucuda bir deploy kullanıcısı

Prod sunucuda root ile deploy yerine ayrı kullanıcı idealdir:

• deploy adlı kullanıcı
• Uygulama dizini: /var/www/myapp

4.2 SSH key ve GitHub Secrets

GitHub Actions’ın sunucuya bağlanması için SSH private key gerekir.

GitHub repo → Settings → Secrets and variables → Actions içine ekleyin:

• SSH_HOST (örn: 1.2.3.4)
• SSH_USER (örn: deploy)
• SSH_KEY (private key içeriği)
• SSH_PORT (opsiyonel, örn 22)

Güvenlik ipucu: Private key şifresiz olabilir ama bu key sadece deploy için sınırlı yetkide olmalı.

5) GitHub Actions Workflow: CI/CD Pipeline Dosyası

Repo içine şu dosyayı ekleyin:

• .github/workflows/deploy.yml

Aşağıdaki örnek; test + build + rsync ile gönderme + restart akışını kurar:

name: CI/CD Deploy

on:
  push:
    branches: ["main"]

jobs:
  build-test-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

      - name: Prepare SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -p ${{ secrets.SSH_PORT || 22 }} ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      - name: Upload files (rsync)
        run: |
          rsync -avz --delete \
            --exclude ".git" \
            --exclude "node_modules" \
            -e "ssh -p ${{ secrets.SSH_PORT || 22 }}" \
            ./ ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:/var/www/myapp

      - name: Install & restart on server
        run: |
          ssh -p ${{ secrets.SSH_PORT || 22 }} ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            set -e
            cd /var/www/myapp
            npm ci --omit=dev

# örnek: migration gerekiyorsa

# npm run migrate

# PM2 kullanıyorsanız:
            pm2 restart myapp || pm2 start dist/main.js --name myapp
            pm2 save
          EOF

5.1 Bu workflow neyi çözüyor?

• CI tarafı: Her push’ta test koşuyor → hatayı prod’a gitmeden yakalıyorsunuz.
• CD tarafı: Kod otomatik aktarılıyor + servis otomatik restart.

5.2 Yaygın hata: known_hosts ve ilk SSH bağlantısı

ssh-keyscan satırı, Actions runner’ın sunucuya ilk bağlantıda “Are you sure you want to continue connecting?” sorusuna takılmasını engeller.

6) Versiyonlama, Rollback ve “Korkmadan Yayın” Pratikleri

CI/CD kurunca yayın hızlanır; ama esas kazanım kontrol.

6.1 Tag/Release stratejisi

• Her anlamlı sürümde Git tag atın: v1.4.0
• İsterseniz workflow’u on: push: tags: ile sadece tag’lerde deploy edecek hale getirin.

6.2 Basit rollback fikri

Sunucuda her deploy öncesi bir önceki sürümü klasör olarak saklayabilirsiniz:

• /var/www/myapp_current
• /var/www/myapp_releases/2026-01-16_1200
• symlink ile switch

Bu yaklaşım, “bir önceki sürüme dön” ihtiyacını dakikalara indirir.

6.3 Ortam değişkenleri (env) yönetimi

Env değerlerini repoya koymayın. Sunucuda /.env ayrı dursun veya secret manager kullanın.

Kural: CI/CD kodu taşır, sırları taşımaz.

7) Gerçek Hayattan Örnek: “Cuma Akşamı Deploy” Kabusunu Bitirmek

Bir SaaS ekibinde klasik senaryo: Cuma 18:30’da manuel deploy, biri migration’ı unutur, servis açılır ama bazı endpoint’ler 500 döner. Panik, rollback, hafta sonu nöbet.

CI/CD ile:

• PR aşamasında testler kırmızıysa merge olmaz
• main’e giren kod otomatik build edilir
• Deploy adımı standarttır, “kim hangi komutu çalıştırdı” belirsizliği yoktur
• Gerekirse tag’li sürüme dönersiniz

Sonuç: yayın süreci kişiye bağlı olmaktan çıkar, sisteme bağlı olur.

Sık Sorulan Sorular (FAQ)

1) CI/CD nedir, gerçekten küçük projeye değer mi?

Evet. Küçük projelerde manuel hatalar daha maliyetlidir çünkü çoğu zaman ayrı bir DevOps kişi yoktur. CI/CD “tek kişilik ekip” için bile sigortadır.

2) GitHub Actions ücretsiz mi?

Public repolarda geniş ölçüde ücretsizdir. Private repolarda planınıza göre dakika kotası vardır. Çoğu küçük-orta proje için yeterli olur.

3) Prod’a otomatik deploy riskli değil mi?

Risk, otomasyon değil; kontrolsüz yayındır. Test, onay (manual approval), tag ile deploy gibi mekanizmalarla güvenli hale getirilebilir.

4) Docker kullanıyorsam bu akış değişir mi?

Evet. Dosya rsync yerine image build/push, sunucuda pull + container restart akışı kullanılır. Mantık aynı: test → build → deploy.

Sonuç

Bu yazıda CI/CD nedir sorusunu netleştirip, GitHub Actions ile otomatik deploy kurgusunu uçtan uca kurdunuz: test, build, sunucuya aktarım ve servis restart.

Şimdi aksiyon zamanı: Workflow’u kendi projenize uyarlayın (dizin, PM2 adı, build komutu). Takıldığınız noktayı yorum olarak yazın; kullandığınız stack’i (Node/Nest/React vs.) belirtin, birlikte netleştirelim. Ayrıca ekipte birine paylaşın—CI/CD en hızlı “takım standardı” olunca değer üretir.