Teknoloji

Blue-Green Deployment ile WooCommerce ve Laravel Uygulamalarını Sıfır Kesintiyle Güncellemek

Blue-Green Deployment ile Sıfır Kesinti Gerçekten Mümkün mü?

Yoğun satış dönemlerinde bir WooCommerce mağazası ya da onlarca müşteriye hizmet veren bir Laravel SaaS uygulaması yönetiyorsanız, “güncelleme yapacağım ama siteyi kapatmak istemiyorum” cümlesini muhtemelen defalarca düşündünüz. Eklenti, tema veya framework güncellemeleri, veritabanı migrasyonları, yeni özelliklerin devreye alınması derken, birkaç dakikalık kesintinin bile sepet terk oranlarını ve müşteri memnuniyetini nasıl etkilediğini sahada çok net görüyoruz. İşte tam bu noktada Blue-Green deployment yaklaşımı, WooCommerce ve Laravel projeleri için pratik bir kurtarıcı haline geliyor.

Bu yazıda, DCHost altyapısında yıllardır kullandığımız ve müşterilerimize sık sık önerdiğimiz Blue-Green modelini, hem WooCommerce (WordPress) hem de Laravel uygulamaları için adım adım ele alacağız. Uygulama kodu, veritabanı, cache, DNS ve load balancer tarafında nelere dikkat etmeniz gerektiğini somut örneklerle anlatacağız. Ayrıca Blue-Green yaklaşımının, geliştirme–staging–canlı süreçlerinizle, CI/CD hattınızla ve felaket senaryolarıyla nasıl uyumlu çalıştığını da netleştireceğiz.

Blue-Green Deployment Nedir, Mantığı Neye Dayanır?

Blue-Green deployment, canlı sisteminizi temsil eden iki ayrı fakat aynı yapılandırmaya sahip ortam kullanarak, yeni sürümleri sıfıra yakın kesintiyle devreye almanızı sağlayan bir yöntemdir. Basit haliyle:

  • Blue ortam: Şu an trafiği karşılayan, aktif çalışan sürüm.
  • Green ortam: Yeni kodu, ayarları ve veritabanı şemasını test ettiğiniz, henüz trafiği almayan sürüm.

Yeni versiyonu Green ortamda hazırlayıp test edersiniz. Her şey yolunda ise trafiği Blue’dan Green’e bir anda veya kontrollü biçimde aktarırsınız. Sorun çıkarsa da yönlendirmeyi tekrar Blue’ya alarak hızlı rollback yapabilirsiniz. Böylece:

  • Güncelleme sırasında ziyaretçilere bakım sayfası göstermek zorunda kalmazsınız.
  • Yeni kodu gerçek trafiği almadan önce üretim benzeri bir ortamda test edebilirsiniz.
  • Geri dönüş (rollback) süreniz saniyelere düşer.

Blue-Green modelini daha geniş bir akış içinde görmek isterseniz, tavsiye edilen geliştirme–staging–canlı mimarilerini anlattığımız WordPress ve Laravel’de sıfır kesinti dağıtım rehberimize da göz atabilirsiniz.

WooCommerce ve Laravel’de Klasik Güncelleme Sorunları

Blue-Green’e geçmeden önce, WooCommerce ve Laravel projelerinde sık gördüğümüz tipik güncelleme problemlerini netleştirmek faydalı:

WooCommerce tarafında yaşananlar

  • Eklenti ve tema güncellemeleri sırasında siteye bakım modu konması, ödeme adımında sepetlerin bozulması.
  • WooCommerce veritabanı yapısına (tablo, sütun, index) müdahale eden güncellemelerde beklenmedik hata sayfaları.
  • Staging’de test edilip canlıya “elle” aktarılan değişikliklerin eksik veya farklı versiyonlarda kalması.
  • Önbellek (page cache, Redis/Memcached) ile yeni kodun uyumsuzluğundan kaynaklı karışık HTML veya oturum sorunları.

Laravel tarafında yaşananlar

  • php artisan migrate çalışırken tablolara kilit gelmesi ve API’nin anlık 500 hatalar vermesi.
  • Queue çalışanlarının (queue:work, Horizon) eski kodla, web isteklerinin yeni kodla çalışması ve sürüm karmaşası.
  • Env dosyası değişikliklerinin kontrolsüz yapılması, config cache’in güncellenmemesi.
  • Deployment sırasında vendor klasörünün yarım kalması ve fatal error’lar.

Bu tablo Blue-Green deployment’i lüks değil, özellikle yoğun trafikli WooCommerce ve Laravel projeleri için iş sürekliliğinin zorunlu bir parçası haline getiriyor.

Blue-Green Mimarinin Temel Bileşenleri

Başarılı bir Blue-Green kurgusu için altyapıda bazı net bileşenlerin olması gerekiyor:

1. İki ayrı uygulama ortamı

  • Aynı sunucu üzerinde iki farklı dizin (ör. /var/www/site-blue, /var/www/site-green)
  • Ya da iki ayrı VPS/dedicated sunucu (ör. app-blue.domaniniz.com ve app-green.domaniniz.com)
  • Her iki ortamda da aynı PHP versiyonu, aynı sistem bağımlılıkları, aynı Nginx/Apache ayarlarının bulunması

2. Trafik yönlendirme katmanı

Blue’dan Green’e geçişi yönetmek için:

  • Nginx veya Apache sanal host’larında tek bir symlink kullanabilirsiniz (örn. /var/www/current → blue/green).
  • Bir reverse proxy / load balancer (örneğin farklı backend’e yönlenen upstream’ler) tercih edebilirsiniz.
  • İleri seviye senaryolarda DNS tabanlı geçiş yaparken TTL stratejilerini kullanarak geçiş sürelerini kontrol edebilirsiniz.

3. Ortak ya da uyumlu veritabanı katmanı

Genellikle Blue ve Green ortamlar aynı veritabanını paylaşır. Ancak bu, veritabanı şemasını güncellerken dikkatli olmanız gerektiği anlamına gelir. Alternatif olarak, ileri seviye senaryolarda her ortam için farklı veritabanı ve replikasyon, online schema değişikliği kurguları da mümkündür. Bunu özellikle WooCommerce ve Laravel için detaylı anlattığımız MySQL’de sıfır kesinti şema değişiklikleri ve Blue-Green rehberinde bulabilirsiniz.

WooCommerce İçin Blue-Green Deployment Adımları

Şimdi WooCommerce tarafında somut bir senaryo üzerinden gidelim. Varsayalım ki DCHost üzerinde bir VPS’iniz var ve burada çalışan canlı WooCommerce mağazanızı sıfır kesintiyle güncellemek istiyorsunuz.

1. Dizayn: Blue ve Green dizinlerini ayırmak

  • Şu an çalışan site: /var/www/woocom-blue
  • Yeni sürüm için hazırlanacak kopya: /var/www/woocom-green
  • Web sunucusunun DocumentRoot’u: /var/www/current (bu bir symlink)

Başlangıçta currentwoocom-blue olacak. Geçiş anında symlink’i woocom-green dizinine çevireceğiz.

2. Blue’dan Green’e dosya kopyalama

Önce mevcut siteyi kopyalayın:

  • Dosyaları rsync ile aktarın: rsync -a /var/www/woocom-blue/ /var/www/woocom-green/
  • wp-config.php içindeki veritabanı ayarlarının birebir aynı olduğundan emin olun.
  • wp-content/uploads klasörünü iki ortam arasında ortak dizin veya symlink ile kullanabilirsiniz.

Özellikle büyük medya arşivlerinde, medya dosyalarını object storage’a taşıyarak deploy süreçlerini hızlandırmak için medya offload stratejisi rehberimize de göz atabilirsiniz.

3. Green ortamda güncellemeleri uygulamak

Green ortamda:

  • Gerekli tema ve eklenti güncellemelerini WP-CLI ile veya admin panel üzerinden uygulayın.
  • WooCommerce veritabanı güncellemeleri (yeni sürüm uyarısı) varsa yalnızca Green üzerinde çalıştırın.
  • Önbellek eklentilerinizin (LiteSpeed Cache, Nginx mikro önbellek, vs.) ayarlarını yeni sürüme göre gözden geçirin.

Bu aşamada site henüz gerçek trafiği almıyor, /etc/hosts üzerinden sadece kendi bilgisayarınızdan Green ortamı test edebilirsiniz.

4. Sağlık kontrolleri ve regresyon testi

Geçiş öncesinde mutlaka şu adımları manuel veya otomasyonla test edin:

  • Ana sayfa, kategori, ürün detay sayfalarının açılış hızı ve hatasız çalışması.
  • Sepete ekleme, sepet görüntüleme, kupon kullanımı.
  • Ödeme adımı: En az bir gerçek test ödeme (sandbox gateway) ile tam akış.
  • Giriş/çıkış, üyelik oluşturma, şifre sıfırlama.

Log ve performans analizi konusunda daha derin bir bakış istiyorsanız, e-ticaret siteleri için log analizi rehberindeki dönüşüm kaybı ve 4xx/5xx incelemelerini sürecinize dahil edebilirsiniz.

5. Trafiği Blue’dan Green’e almak (symlink değişimi)

Artık geçiş zamanı. Nginx/Apache konfigürasyonunuz /var/www/current dizinine bakarken aşağıdaki gibi hareket edebilirsiniz:

  1. Kısa bir süre için bakım sayfası göstermek istiyorsanız HTTP seviyesinde 503’e yönlendiren basit bir sayfa koyabilirsiniz (Blue-Green’de çoğu zaman buna gerek kalmıyor).
  2. Symlink’i güncelleyin: ln -sfn /var/www/woocom-green /var/www/current
  3. PHP-FPM havuzunu yeniden başlatın veya yumuşak yeniden yükleyin.
  4. Önbelleği (page cache, object cache, CDN cache) temizleyin.

Bu işlem genellikle saniyeler içinde biter ve kullanıcıların büyük kısmı kesinti bile fark etmez.

6. Rollback stratejisi

Geçiş sonrası metriklerde (sipariş sayısı, hata logları, response time) beklenmeyen bir düşüş görürseniz:

  • Symlink’i tekrar woocom-blue dizinine alın.
  • Önbelleği temizleyin.
  • Green ortamında sorunu tespit edip yeni bir Green sürüm oluşturarak süreci tekrarlayın.

Bu rollback süreci, klasik “yedekten geri dönme” senaryosuna göre çok daha hızlı ve kontrollüdür.

Laravel Uygulamaları İçin Blue-Green Deployment Adımları

Laravel tarafında Blue-Green kurmak çoğu zaman daha esnek, çünkü framework doğal olarak versiyonlamaya ve otomatik deployment akışlarına çok uygun.

1. Klasik “releases” + “current” yapısını benimsemek

Laravel projelerinde önerdiğimiz yapı genellikle şöyledir:

  • /var/www/app/releases/202501010101 (Blue)
  • /var/www/app/releases/202501021200 (Green)
  • /var/www/app/current → aktif sürüme işaret eden symlink

Bu mantığı detaylı anlattığımız VPS’e sıfır kesinti CI/CD rehberinde hem rsync hem de sembolik sürüm yönetimi örnekleriyle bulabilirsiniz.

2. Yeni sürümü Green ortama deploy etmek

Yeni commit geldiğinde CI sistemi (örn. GitHub Actions) şu adımları çalıştırabilir:

  1. Yeni bir release klasörü oluştur.
  2. Kodu buraya git clone veya rsync ile aktar.
  3. composer install --no-dev --optimize-autoloader çalıştır.
  4. php artisan config:cache, route:cache, view:cache komutlarını uygula.
  5. Env dosyasını (.env) ortak bir konumdan symlink ile bağla.

Laravel’i DCHost VPS üzerinde yayınlama tarafındaki en iyi pratikleri ve Nginx + PHP-FPM yapılandırmasını adım adım görmek isterseniz, Laravel uygulamalarını VPS’te yayınlama rehberimizi mutlaka inceleyin.

3. Veritabanı migrasyonlarını kesintisiz planlamak

Laravel tarafında asıl kritik nokta migrations. Genel tavsiyemiz:

  • Önce şemayı ileri uyumlu hale getiren migrasyonları çalıştırın (yeni kolon ekleme, nullable alanlar, vs.).
  • Yeni kod, hem eski hem yeni şema ile çalışabilecek şekilde tasarlansın (feature flag, null toleransı).
  • Gerekirse gh-ost veya benzeri araçlarla büyük tabloları online olarak taşıyın. Detaylar için tekrar MySQL Blue-Green şema değişikliği rehberine bakabilirsiniz.

Böylece hem Blue (eski sürüm) hem Green (yeni sürüm) bir süre aynı veritabanı yapısı üzerinde problemsiz çalışabilir.

4. Queue, Horizon ve scheduler senkronizasyonu

Laravel projelerinde sık yapılan hata, sadece web isteklerini yeni sürüme alıp queue işçilerini eski sürümde bırakmak. Blue-Green’de şu stratejiyi uygulayın:

  • Önce queue işçilerini durdurun (Supervisor/systemd/PM2 üzerinden).
  • Symlink’i yeni release’e alın.
  • Queue işçilerini, Horizon’ı ve scheduler’ı yeni sürüm dizini üzerinden tekrar başlatın.

Böylece hem web istekleri hem arka plan işler aynı kod tabanı ile çalışır, sürüm karmaşası yaşamazsınız.

CI/CD ile Blue-Green Deployment’ı Otomatikleştirmek

Manuel Blue-Green senaryoları küçük ekipler için yeterli olabilir; ancak gerçek verim, CI/CD sürecine entegre edildiğinde ortaya çıkıyor. Örneğin GitHub Actions kullanarak DCHost VPS’e otomatik deploy yapan bir pipeline düşünelim.

Örnek pipeline akışı

  1. Git repo’ya main branch’ine push.
  2. GitHub Actions workflow’u tetiklenir.
  3. Testler, static analysis, lint kontrolleri çalışır.
  4. Uygun ise yeni bir release klasörü oluşturulur, kod aktarılır, composer/npm süreçleri tamamlanır.
  5. Sağlık kontrolü (health check URL, basit smoke test’ler) çalıştırılır.
  6. Başarılıysa symlink Blue’dan Green’e alınır.
  7. Gerekirse eski release otomatik olarak arşivlenir veya silinir.

Bu tarz bir akışı kurmak için GitHub Actions ile VPS’e deploy sürecini detaylı anlattığımız otomatik deploy ve zero-downtime rehberini temel olarak kullanabilirsiniz.

DNS, Load Balancer ve TTL Stratejileri

Blue-Green’de trafiği değiştirmek için her zaman symlink kullanmak zorunda değilsiniz. Özellikle iki farklı VPS veya dedicated sunucu kullanıyorsanız:

  • Önünüzde bir reverse proxy / load balancer varsa, backend IP’sini Blue’dan Green’e çekebilirsiniz.
  • DNS üzerinden A/AAAA kayıtlarını Blue sunucudan Green sunucuya taşıyabilirsiniz.

DNS tabanlı geçiş yaparken en kritik konu TTL yönetimi. Geçişten bir süre önce TTL’leri düşürüp, geçiş sonrası tekrar yükseltmek, yayılım sürelerini kontrol altına almanızı sağlar. Bu konuyu adım adım ele aldığımız Zero-Downtime taşıma için TTL stratejileri rehberini Blue-Green planınıza mutlaka entegre etmenizi öneririm.

WooCommerce ve Laravel’de İzleme, Loglama ve Rollback

Blue-Green’in en önemli avantajlarından biri, risk almadan deneme yapabilme imkanıdır. Ancak bu, iyi bir izleme ve log yapınız varsa anlamlı hale gelir.

Geçiş öncesi ve sonrası metrikler

  • WooCommerce için sipariş sayısı, sepet terk oranı, 4xx/5xx hata oranları.
  • Laravel API’leri için hata oranı, response time, timeout sayıları.
  • Sunucu tarafında CPU, RAM, disk IO, database sorgu süreleri.

Geçişten önce ve sonra bu metrikleri kıyaslayarak yeni sürümün gerçekten daha iyi çalışıp çalışmadığını objektif olarak görebilirsiniz.

Rollback’i otomatikleştirmek mümkün mü?

Evet. CI/CD hattınız, belirli eşikleri (örneğin 5xx hata oranı %X’i geçerse) aştığında otomatik rollback tetikleyebilir. İlk etapta manuel onaylı (örneğin “rollback için onay ver” adımı olan) bir yapı ile başlamak, sonra tamamen otomatiğe geçmek daha güvenli bir yol olur.

DCHost Üzerinde Blue-Green İçin Doğru Altyapıyı Seçmek

Blue-Green deployment için illa devasa bir cluster kurmak zorunda değilsiniz. Çoğu WooCommerce ve Laravel projesi için şu senaryolar fazlasıyla yeterli oluyor:

  • Tek VPS, iki dizin: Küçük/orta ölçekli projeler için, aynı VPS üzerinde Blue ve Green dizinleri ve symlink ile geçiş.
  • İki VPS, tek veritabanı: Web trafiğini iki VPS arasında Blue/Green olarak değiştirip, ortak bir veritabanı sunucusuna bağlamak.
  • Uygulama + veritabanı ayrımı: Yüksek trafikli WooCommerce/Laravel projelerinde, uygulama ve veritabanını ayrı DCHost VPS veya dedicated sunucularda konumlandırmak.

Özellikle WooCommerce gibi I/O yoğun e-ticaret projelerinde CPU, RAM ve disk IOPS ihtiyacını doğru planlamak için WooCommerce kapasite planlama rehberindeki hesaplama metodlarını Blue-Green tasarımına entegre etmenizi tavsiye ederiz.

Özet: WooCommerce ve Laravel’de Blue-Green İçin Yol Haritası

Toparlayalım. Blue-Green deployment, WooCommerce ve Laravel projelerini “kırmadan” güncellemek için güçlü ve pratik bir yaklaşım sunuyor. Bir yanda trafiği alan Blue ortam, diğer yanda yeni sürümü güvenle hazırladığınız Green ortam var. Symlink, Nginx upstream, load balancer veya DNS ile trafiği saniyeler içinde Green’e alabiliyor; herhangi bir sorun yaşarsanız yine saniyeler içinde Blue’ya geri dönebiliyorsunuz.

WooCommerce tarafında tema/eklenti güncellemeleri, veritabanı yapısı ve önbellek yönetimi; Laravel tarafında ise migrations, queue işçileri ve release yönetimi kritik noktalar. Bunların hepsi, doğru CI/CD akışı ve ölçülü bir altyapı planlaması ile çözülebilir. DCHost olarak, ister tek VPS üzerinde symlink ile ister çoklu VPS/dedicated mimarilerle olsun, Blue-Green deployment kurmak isteyen ekiplerle sahada sık sık birlikte çalışıyoruz.

Eğer siz de WooCommerce mağazanızı veya Laravel uygulamanızı sıfır kesintiyle güncellemek, rollback korkusunu ortadan kaldırmak ve daha güvenle deploy edebilmek istiyorsanız, mevcut altyapınızı birlikte gözden geçirip en uygun Blue-Green senaryosunu çıkartabiliriz. DCHost üzerindeki hosting, VPS, dedicated ve colocation seçenekleriyle uygulamanıza ve bütçenize en uygun yapıyı planlamak için bizimle iletişime geçmeniz yeterli.

Sıkça Sorulan Sorular

WooCommerce mağazalarında her güncelleme aslında gelirinizi doğrudan etkileyen bir risk. Tema/eklenti güncellemeleri, WooCommerce çekirdeği veya ödeme altyapısındaki değişiklikler sırasında sitenin birkaç dakika bile kapalı kalması, hem sepet terk oranını artırır hem de marka algısını zedeler. Blue-Green deployment bu riski minimuma indiriyor; yeni sürümü Green ortamda test edip, trafiği saniyeler içinde Blue’dan Green’e almanızı sağlıyor. Ayrıca rollback süresi de ciddi biçimde kısalıyor. Özellikle kampanya dönemleri, yoğun trafiğe sahip e-ticaret siteleri ve kurumsal mağazalar için Blue-Green yaklaşımı “güzel bir opsiyon” değil, sürdürülebilir bir zorunluluk diyebiliriz.

Blue-Green deployment, trafiğin neredeyse tamamını bir anda Blue’dan Green’e aldığınız, nispeten keskin fakat rollback’i çok hızlı olan bir yöntemdir. Canary deployment ise yeni sürümü önce trafiğin küçük bir yüzdesine açar (örneğin %5), metrikler iyi görünürse bu oranı kademeli olarak artırırsınız. Laravel uygulamalarında Blue-Green, çoğu KOBİ ve orta ölçekli proje için daha basit ve yeterli oluyor; canary ise çok yüksek trafik alan, risk almak istemeyen büyük SaaS projelerinde tercih ediliyor. İki yaklaşım da doğru altyapı ve gözlemleme araçlarıyla uygulanabilir; fakat başlangıç için genellikle Blue-Green daha yönetilebilir ve sade bir model sunuyor.

Hayır, Blue-Green deployment’ın en yaygın senaryosu tek bir veritabanı üzerinden çalışmaktır. Blue ve Green ortamlar genellikle aynı veritabanına bağlanır; fark kod ve yapılandırma katmanında olur. Burada kritik nokta, veritabanı şema değişikliklerini ileri uyumlu olacak şekilde planlamaktır. Örneğin önce yeni kolon ekleyip her iki sürümün de bu şemada çalışabilmesini sağlamak, gerekmeyen eski alanları daha sonra kaldırmak gibi iki aşamalı bir yaklaşım kullanılmalıdır. Aşırı yüksek trafikli ve regülasyon kritik projelerde her ortam için ayrı veritabanı ve replikasyon tabanlı Blue-Green kurguları da yapılabilir; ancak bu, çoğu WooCommerce ve Laravel uygulaması için zorunlu değildir.

Teorik olarak, bazı paylaşımlı hosting ortamlarında iki farklı klasör ve tek bir symlink ile çok basit bir Blue-Green benzeri kurgu yapılabilir. Ancak paylaşımlı hostinglerde genellikle symlink yönetimi, özel Nginx/Apache ayarları, queue işçileri, otomatik deploy script’leri gibi Blue-Green’in gücünü ortaya çıkaran bileşenler üzerinde tam kontrolünüz olmaz. Bu yüzden gerçek anlamda esnek ve güvenilir bir Blue-Green yapısı için genellikle DCHost üzerindeki VPS veya dedicated sunucu çözümlerini tercih etmenizi öneririz. Böylece hem web sunucusu hem PHP-FPM, hem de CI/CD pipeline’ı üzerinde tam kontrol sahibi olur, rollback ve ölçekleme kararlarını özgürce alabilirsiniz.

Blue-Green deployment için ihtiyaç duyacağınız kaynaklar, projenizin büyüklüğüne göre değişiyor. Küçük ve orta ölçekli WooCommerce veya Laravel projelerinde tek bir güçlü DCHost VPS üzerinde iki ayrı dizin (Blue/Green) ve symlink yaklaşımı çoğu zaman yeterli oluyor. Trafiğiniz ve veriniz büyüdükçe, uygulama ve veritabanını ayrı DCHost VPS’lere ayırmak veya dedicated sunucuya geçmek mantıklı hale geliyor. Çok kritik projelerde ise load balancer arkasında birden fazla VPS, ayrı veritabanı sunucuları ve gerektiğinde colocation çözümleriyle mimarinizi ölçekleyebilirsiniz. Emin değilseniz, mevcut yükünüzü ve büyüme planınızı bizimle paylaşmanız, birlikte gerçekçi bir Blue-Green altyapı tasarlamamız için en sağlıklı yol olacaktır.