Size daha iyi hizmet sunabilmek için çerezleri kullanıyoruz.
Web sitemizde gezinme deneyiminizi geliştirmek, size kişiselleştirilmiş içerik ve hedefli reklamlar göstermek, web sitesi trafiğimizi analiz etmek ve ziyaretçilerimizin nereden geldiğini anlamak için çerezleri ve diğer izleme teknolojilerini kullanıyoruz.
⚠️
KVKK ve Çerez Politikası Bilgilendirmesi
6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) ve Aydınlatma Yükümlülüğü kapsamında; web sitemizin temel fonksiyonlarının çalışabilmesi, veri güvenliğinin sağlanması ve performans analizi yapılabilmesi için zorunlu çerezlerin kullanımı gerekmektedir. Çerez kullanımını reddetmeniz halinde, teknik imkansızlıklar ve veri senkronizasyonu kesintileri nedeniyle web sitemizdeki hizmetlerden yararlanmanız mümkün olmamaktadır. Sitemizdeki içeriklere erişebilmek için çerez kullanımını onaylamanız gerekmektedir.
GitHub Actions ile Kesintisiz CI CD Pipeline Mimarisi
Modern yazılım geliştirme dünyasında dağıtım süreçleri (deployment), kodun yazılması kadar kritik bir öneme sahiptir. Kullanıcıların uygulamanıza 7/24 erişebildiği bir ekosistemde, “bakım modu” veya “sunucu durdurma” gibi geleneksel yöntemler artık kabul edilebilir değil. Kesintisiz dağıtım (Zero Downtime Deployment), altyapınızın sürekli ayakta kalmasını sağlarken yeni özellikleri güvenle yayına almanıza olanak tanır.
Şekil 1: GitHub Actions ile Kesintisiz CI CD Pipeline Mimarisi.
Modern Dağıtım Stratejileri ve Temeller
Zero Downtime hedefi için en yaygın ve güvenilir yöntemler Blue-Green Deployment ve Rolling Update stratejileridir.
Blue-Green: Halihazırda çalışan ortamın (Blue) yanına tamamen aynı özelliklere sahip yeni bir ortam (Green) kurarsınız. Testler geçtikten sonra trafik yük dengeleyici (load balancer) üzerinden Green ortama aktarılır.
Rolling Update: Mevcut sunucuları veya konteynerleri sırayla güncellersiniz. Bir sunucu güncellenirken diğerleri trafiği karşılamaya devam eder.
Bu stratejileri otomatize etmek için GitHub Actions, süreçleri kod (Pipeline as Code) üzerinden yönetmemizi sağlar.
GitHub Actions ile Pipeline Tasarımı
Bir CI/CD pipeline’ı dört temel aşamadan oluşur: Build, Test, Push ve Deploy.
1. Build ve Test Aşaması
Kodun depoya (repository) gönderilmesiyle başlayan bu süreç, uygulamanın çalışabilir olduğundan emin olmalıdır.
# .github/workflows/deploy.ymlname: CI/CD Pipelineon:
push:
branches: [ main ]jobs:
build-and-test:
runs-on: ubuntu-lateststeps:
- uses: actions/checkout@v4 - name: Setup Node.jsuses: actions/setup-node@v4with:
node-version: '20' - run: npm ci - run: npm run build - run: npm test
2. Containerization ve Registry Yönetimi
Uygulamayı bir Docker imajı haline getirmek, her ortamda aynı davranışı sergilemesini garanti eder. docker buildx kullanarak çoklu mimari destekli imajlar oluşturmak, günümüz bulut native altyapıları için bir standarttır.
apiVersion: apps/v1kind: Deploymentmetadata:
name: my-appspec:
replicas: 3strategy:
type: RollingUpdaterollingUpdate:
maxSurge: 1# Bir anda eklenebilecek yeni pod sayısımaxUnavailable: 0# Güncelleme sırasında kapalı kalabilecek pod sayısıtemplate:
spec:
containers:
- name: appimage: myrepo/myapp:${{ github.sha }}readinessProbe: # ÖNEMLİ: Pod hazır olmadan trafiği yönlendirmehttpGet:
path: /healthport: 8080
Not:readinessProbe kullanmak, uygulamanızın ayağa kalktığını ancak veritabanı bağlantılarının tamamlandığı veya cache ısınma süreci bittiğinde trafiği kabul edeceğini garanti eder. Bu, kesintisiz deneyimin temel taşıdır.
Veritabanı Geçişleri (Database Migrations)
Uygulamanın yeni sürümü eski veritabanı şemasıyla veya tam tersi durumla karşılaşabilir. Zero Downtime dağıtımın en zor kısmı burasıdır.
Geriye Dönük Uyumluluk: Her zaman veritabanı değişikliğini uygulamadan önce yapın. Örneğin, bir sütunu silmeden önce uygulamanın o sütunu okumayı bıraktığından emin olun.
İki Aşamalı Migration: Önce yeni sütunu ekleyin, ardından veriyi taşıyın, en son eski sütunu temizleyin.
Liquibase veya Flyway Kullanımı: Bu araçlar, veritabanı versiyonlarını kod gibi yönetmenizi sağlar.
# Örnek Liquibase komutuliquibase --changelog-file=db/changelog/main.xml update
İzlenebilirlik ve Geri Alma (Rollback)
Dağıtım her zaman kusursuz gitmeyebilir. Bu durumda hızla eski sürüme dönmek (rollback) gerekir. GitHub Actions üzerinde başarısızlık durumunda otomatik tetiklenen bir on: failure adımı eklemek, operasyonel riskleri minimize eder.
Gözlemleme Araçları (Observability)
Sadece dağıtmak yeterli değildir, dağıtım sonrası uygulamanın “sağlığını” izlemelisiniz:
Prometheus & Grafana: Sistem metriklerini takip etmek için.
ELK Stack (Elasticsearch, Logstash, Kibana): Hata loglarını analiz etmek için.
Sentry: Uygulama içi çalışma zamanı hatalarını anlık yakalamak için.
Özet ve En İyi Pratikler
Kesintisiz dağıtım bir varış noktası değil, bir disiplindir. İşte başarılı bir süreç için dikkat etmeniz gerekenler:
Küçük ve Sık Parçalar: Değişiklikleri mümkün olduğunca küçük tutun. Büyük dağıtımların hata yapma olasılığı her zaman daha yüksektir.
İzolasyon: Geliştirme (dev), test (staging) ve üretim (production) ortamlarını birbirinden izole tutun.
Otomasyon: Süreç içerisinde hiçbir manuel müdahale olmamalıdır. “Elde yapılan” her işlem, hata payını artırır.
Güvenlik: Secret yönetimini (GitHub Secrets veya HashiCorp Vault) kullanarak hiçbir şifreyi repository içinde barındırmayın.
Sıkça Sorulan Sorular (SSS)
S: Neden Blue-Green yerine Rolling Update tercih etmeliyim?
C: Rolling update, kaynak kullanımı açısından daha ekonomiktir. Blue-Green, kaynakları iki katına çıkarmanızı gerektirir ancak geçiş süreci (rollback) daha temizdir.
S: Veritabanı şema değişikliğinde sorun yaşarsam ne olur?
C: Uygulama kodunuzu veritabanı değişikliğinden bağımsız olarak çalışacak şekilde tasarlamalısınız. “Expand and Contract” (Genişlet ve Daralt) desenini uygulamak, veritabanı kaynaklı kesintileri ortadan kaldırır.
S: GitHub Actions maliyetli bir çözüm mü?
C: GitHub Actions, sunduğu otomasyon hızı ve operasyonel kolaylık göz önüne alındığında oldukça maliyet etkindir. Kendi sunucularınızda (Self-hosted runners) çalıştırarak maliyetleri daha da düşürebilirsiniz.
Bu teknik altyapı ile hem geliştirici verimliliğinizi artırabilir hem de son kullanıcınıza kesintisiz bir deneyim sunabilirsiniz. Unutmayın, iyi bir CI/CD pipeline’ı yazılımın kalitesini ve ekibin özgüvenini doğrudan etkiler.
