Git ile Otomatik Deployment Kurulumu: 7 Adımda Sorunsuz ve Güvenli Yayına Alma

1. Neden Otomatik Deployment? Sorunları ve Kazanımları

Günümüzde birçok geliştirici, kodlarını manuel olarak sunucuya kopyalamaktan ve konfigürasyon hatalarına uğramaktan şikayetçi. Özellikle kod değişikliği sıklığı yüksek projelerde, her bir deploy işlemi ortalama 15‑30 dakika sürebilir. Bu da %40’a varan verim kaybına yol açar. Otomatik deployment ise bu süreci saniyeler içinde tamamlayarak, hataları %70 oranında azaltır ve zero downtime (kesintisiz hizmet) hedefini mümkün kılar.

Yaygın hatalar arasında “yanlış .env dosyası yüklemek”, “eski bağımlılıkların kalması” ve “sunucuya eksik dosya kopyalamak” bulunur. Bu hatalar sadece hizmet kesintisine değil, aynı zamanda müşteri kaybına ve SEO puanının düşmesine de neden olur. Otomatik deployment sayesinde bu riskler minimuma iner; çünkü her adım önceden tanımlanmış script’ler ve testler aracılığıyla doğrulanır.

2. Gerekli Altyapı: Sunucu Seçimi ve Hazırlığı

Otomatik deployment için öncelikle güvenilir bir sunucu ortamına ihtiyacınız var. VDS sunucu paketleri arasında, CPU performansı ve network latansı kritik rol oynar. Örneğin, AMD Ryzen VDS sunucular, paralel işlem gücü sayesinde CI/CD runner’larını sorunsuz çalıştırır; Intel i9 VDS sunucular ise tek çekirdek performansında öne çıkar. Hangi paket seçileceği, projenizin derleme süresi ve paralel test ihtiyacına göre karar verilmelidir.

Sunucu hazırlığı şu adımları içerir:

• İşletim sistemi olarak Ubuntu 22.04 LTS veya CentOS 8 tercih edin; uzun vadeli destek (LTS) güncellemeleri sayesinde güvenlik açıkları hızlıca kapanır.
• SSH anahtarlarıyla parola tabanlı oturumları devre dışı bırakın; bu, brute‑force saldırı riskini %90 azaltır.
• Git, Docker ve gerekli build araçlarını (Node.js, Maven, Composer vb.) kurun.
• Firewall (UFW veya iptables) ile yalnızca 22, 80, 443 ve CI/CD runner portlarını açın.

3. Git Deposu ve Branch Stratejisi

Otomatik deployment’ın temelini, iyi tanımlanmış bir Git workflow oluşturur. En yaygın kullanılan stratejilerden biri Git Flow’dur; burada master (veya main) üretim, develop geliştirme, feature/* yeni özellik, release/* sürüm hazırlığı ve hotfix/* acil düzeltmeler için kullanılır.

Branch stratejisinin avantajları:

• Her ortam (test, staging, production) ayrı bir branch ile eşlenir; bu sayede yanlış kodun prod’a geçmesi riski ortadan kalkar.
• Pull request (PR) süreçleri sayesinde kod incelemesi otomatik olarak CI aşamasına dahil edilir.
• Tagleme (örn. v1.2.3) ile sürüm takibi netleşir ve rollback işlemleri basitleşir.

4. CI/CD Pipeline Oluşturma: GitHub Actions Örneği

CI (Continuous Integration) ve CD (Continuous Deployment) adımlarını birleştiren bir pipeline, kodun her push’unda çalışır. GitHub Actions, ücretsiz ve GitHub reposu ile tam entegrasyon sunduğu için tercih edilir. Aşağıda basit bir .github/workflows/deploy.yml dosyası örneği verilmiştir:

name: Deploy to Production
on:
  push:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Build assets
        run: npm run build
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v0.1.7
        with:
          host: ${{ secrets.SERVER_IP }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/myapp
            git pull origin main
            npm ci --production
            npm run migrate
            pm2 restart all

Bu script, testleri başarıyla geçtikten sonra sunucuya SSH ile bağlanır, kodu günceller, bağımlılıkları kurar ve pm2 ile Node.js uygulamasını yeniden başlatır. Benzer şekilde, docker-compose kullanan projeler için docker pull ve docker compose up -d komutları eklenebilir.

5. Güvenlik ve İzleme: Deployment Sonrası Kontroller

Otomatik deployment’ın en kritik aşaması, yeni sürümün güvenli ve stabil çalıştığının doğrulanmasıdır. Bunun için şu önlemler alınmalıdır:

• Rollback mekanizması: Deploy sonrası git revert veya Docker image tag’ı ile eski sürüme geçiş 5 dakikadan az sürede yapılabilmelidir.
• WAF (Web Application Firewall) entegrasyonu: WAF güvenlik duvarı sayesinde yeni kodda oluşabilecek SQL injection veya XSS gibi saldırılar anında engellenir.
• Health check endpoint: /healthz gibi basit bir endpoint, load balancer veya Kubernetes liveness probe ile izlenir.
• Log toplama: ELK stack ya da Grafana + Loki ile deploy sonrası loglar merkezi bir yerde toplanır, anormallikler anında alarm verir.

Aşağıdaki tablo, klasik manuel deploy ile otomatik pipeline arasındaki temel farkları özetler:

6. Gerçek Dünya Senaryosu: E‑ticaret Sitesi İçin Deployment

Bir e-ticaret hosting ortamında, yüksek trafik ve ödeme entegrasyonları kritik olduğu için deployment süreci daha titiz yapılmalıdır. Örneğin, bir Laravel tabanlı mağaza için aşağıdaki adımlar izlenir:

1. GitHub Actions’da phpunit testlerini çalıştırın; %90’ın üzerindeki test geçişi zorunlu kılın.
2. Docker image oluşturup registrye push edin.
3. Staging ortamına docker compose up -d ile dağıtın, sanity tests (ör. ürün listeleme, sepet ekleme) otomatik olarak çalıştırın.
4. Staging testleri başarılıysa, aynı image’i prod ortamına kubectl rollout restart deployment/myshop komutuyla dağıtın.
5. Ödeme gateway (Stripe, PayTR) loglarını izleyin; hata oranı %0.1’in altında olmalı.

Bu senaryoda, alan adı (domain) kaydı ve kurumsal e-posta yapılandırması da aynı CI pipeline içinde certbot ile otomatik SSL yenileme adımı eklenerek yönetilir.

7. Sıkça Sorulan Sorular

Git ile otomatik deployment yaparken en çok hangi hatayı alırım?

En sık karşılaşılan hata, permission denied (publickey) hatasıdır. Bunun nedeni, CI runner’ın SSH anahtarının sunucuda yetkilendirilmemiş olmasıdır. Çözüm olarak, runner’da kullanılan özel anahtarı ~/.ssh/authorized_keys dosyasına ekleyin ve chmod 600 izinlerini kontrol edin.

CI/CD pipeline’da Docker kullanmalı mıyım?

Evet. Docker, ortam tutarlılığını sağlar ve “çalıştığım makinede çalışıyor” sorununu ortadan kaldırır. Özellikle fiziksel sunucu (dedicated server) üzerinde birden fazla uygulama çalıştırıyorsanız, container‑izasyon hem kaynak yönetimini hem de izolasyonu iyileştirir.

Rollback nasıl hızlı yapılır?

Rollback için iki yöntem önerilir: (1) Git tag’ı ile önceki sürüme git checkout ve git pull işlemi; (2) Docker’da önceki image’i docker pull ve docker compose up -d ile yeniden çalıştırma. CI pipeline’da bu adımları bir rollback.yml dosyası olarak tanımlamak, tek komutla geri dönüşü mümkün kılar.

CI/CD pipeline’ı güvenli tutmak için neler yapmalıyım?

Gizli anahtarları (API token, SSH key) GitHub Secrets gibi şifreli depolama alanlarında tutun. Ayrıca, pipeline içinde npm audit veya bandit gibi güvenlik tarayıcıları çalıştırarak bağımlılıkların güvenliğini kontrol edin. Son olarak, SLA hizmeti kapsamında sunucu izleme ve anlık uyarı mekanizmaları kurun.

Sonuç ve Bir Sonraki Adım

Git ile otomatik deployment, sadece zaman kazanmakla kalmaz, aynı zamanda hataları azaltarak uygulamanızın güvenilirliğini %90’a kadar artırır. Yukarıdaki 7 adımı takip ederek, VDS sunucunuzu (örneğin Ryzen VDS) hazırlayıp, GitHub Actions veya başka bir CI/CD aracıyla entegrasyon kurabilirsiniz. İlk adım olarak, mevcut projenizin branch stratejisini gözden geçirin ve bir deploy.yml dosyası oluşturun. Daha sonra, web hosting paketleri içinde size en uygun ortamı seçerek pipeline’ı test ortamına dağıtın. Başarılı bir test sonrası prod ortamına geçiş, sorunsuz bir yayın deneyimi sunacaktır.