Git ile WordPress ve PHP Sitelerini Otomatik Deploy Etmek

WordPress ya da özel yazılmış bir PHP site üzerinde çalışırken en çok zaman kaybettiren ve hata üreten iş neredeyse her zaman aynıdır: güncellemeleri canlı sunucuya taşımak. Dosyaları FTP ile tek tek sürükleyip bırakmak, hangi dosyaların güncel olduğunu hatırlamaya çalışmak, canlı sitede beyaz ekran görmemek için dua etmek… Birkaç müşterili küçük bir ajansken bile yorucu, onlarca WordPress sitesi yöneten bir ekipte ise sürdürülemez hale geliyor.

Git tabanlı otomatik deploy ve basit bir CI/CD (Continuous Integration / Continuous Delivery) hattı kurduğunuzda, bu kaos ortadan kalkıyor. Kod değişikliklerini bir branch üzerinde geliştiriyor, test ediyor, daha sonra tek bir komutla veya otomatik olarak paylaşımlı hosting ya da VPS sunucunuza güvenle gönderiyorsunuz. Üstelik neyin, ne zaman, kim tarafından canlıya alındığı tamamen kayıt altında kalıyor.

Biz DCHost ekibi olarak hem paylaşımlı hosting hem de VPS tarafında Git ile otomatik deploy kuran yüzlerce müşteri gördük. Bu yazıda, WordPress ve genel PHP projeleri için, Git ile otomatik deploy mantığını; paylaşımlı hosting ve VPS senaryolarını; sıfır kesinti hedefleyen CI/CD akışlarını adım adım ve gerçekçi örneklerle anlatacağız. Elinizdeki altyapı ne olursa olsun, yazının sonunda kendi projeniz için uygulanabilir bir yol haritanız olsun istiyoruz.

Git ile Otomatik Deploy ve CI/CD Temelleri

Git ile otomatik deploy, özünde tek bir fikre dayanır: Canlı sunucuya manuel dosya kopyalamak yerine, kodu Git deposundan çekmek veya CI sunucusunun ürettiği paketi otomatik olarak dağıtmak. Bunun üzerine eklenen CI/CD kavramları ise süreci daha güvenli ve tekrar edilebilir hale getirir.

Önce temel kavramları netleştirelim:

• Git deposu: Kodunuzun tutulduğu yer. GitHub, GitLab, Bitbucket veya DCHost üzerinde kendi Git sunucunuz olabilir.
• Branch (dal): Farklı geliştirme akışlarını ayırdığınız kollar. Örneğin dev, staging ve main gibi.
• Continuous Integration (CI): Her push sonrasında otomatik test, kod analizi, build gibi işleri tetikleyen süreç.
• Continuous Delivery / Deployment (CD): CI sürecinden geçen kodun staging ya da canlı ortama otomatik veya yarı otomatik dağıtılması.
• Pipeline: Test, build, paketleme, deploy gibi adımlardan oluşan otomatik akış.

Basit bir WordPress veya PHP projesi için tipik bir pipeline şöyle görünebilir:

• Geliştirici kodu localde değiştirir, commit eder ve Git deposuna push eder.
• CI sistemi (örneğin GitHub Actions) testleri çalıştırır, derlenmesi gereken bir şey varsa derler (SCSS, JS bundling gibi).
• Başarılı olursa paylaşımlı hosting veya VPS sunucuya SSH üzerinden bağlanır, son sürüm kodu indirir veya rsync ile senkronize eder.
• Gerekliyse veritabanı migration komutlarını çalıştırır, cache temizler, PHP-FPM veya Nginx yeniden yüklenir.

cPanel, Plesk ve VPS tarafında temel Git entegrasyonunu daha önce detaylıca anlattığımız Git ile otomatik deploy kurulum rehberine de göz atabilirsiniz; bu yazıda ise özellikle WordPress ve PHP siteleri için pratik CI/CD tasarımına odaklanacağız.

Paylaşımlı Hosting Üzerinde Git ile Otomatik Deploy

Birçok ajans ve geliştirici için ilk adım, mevcut paylaşımlı hosting hesabı üzerinde Git ile otomatik deploy kurmak oluyor. Kaynaklar sınırlı, root erişimi yok; ama doğru kurguyla yine de oldukça verimli bir akış oluşturmak mümkün.

Paylaşımlı hostingte gerçekçi kısıtlar

Önce sınırları netleştirelim:

• Root erişiminiz yok; sistem paketleri, global servisler üzerinde kontrol sınırlı.
• SSH erişimi bazı paketlerde açık, bazılarında kapalı olabilir. SSH varsa işler çok kolaylaşır.
• cPanel veya Plesk gibi kontrol panellerinde Git entegrasyonu olabilir ama her zaman tüm ihtiyaçları karşılamayabilir.
• Crontab erişimi genelde var; belirli aralıklarla script çalıştırabilirsiniz.

Bu kısıtlar içinde üç ana yaklaşım görüyoruz:

• cPanel / Plesk Git entegrasyonu ile otomatik çekme
• Manuel tetiklenen deploy scripti (SSH ile)
• Belirli aralıklarla çalışan cron tabanlı deploy scripti

cPanel Git entegrasyonu ile basit otomatik deploy

Eğer hosting hesabınızda cPanel kullanıyorsanız, çoğu modern sürümde Git Version Control modülü bulunur. Temel akış:

1. Git deposunu GitHub / GitLab üzerinde oluşturun.
2. cPanel içinden yeni bir Git deposu ekleyin, uzak depo adresini tanımlayın.
3. Deploy etmek istediğiniz klasörü (örneğin public_html) work tree olarak ayarlayın.
4. Her yeni sürümde cPanel arayüzünden veya SSH ile ilgili komutu çalıştırarak git pull yapın.

Bu yaklaşım, özellikle küçük WordPress siteleri veya basit PHP projeleri için yeterli olabilir. Yine de tam anlamıyla CI/CD sayılmaz; çünkü test, build, backup gibi adımlar manuel veya yarı otomatik kalır.

SSH ile hook tabanlı deploy

SSH erişiminiz varsa daha esnek ve otomatik bir kurgu kurabilirsiniz. Örneğin:

1. Hosting hesabınızda, public_html dışında bir dizinde bare repo oluşturun. Örnek: /home/kullanici/repo/site.git
2. Bu repo için post-receive hook yazarak, her push sonrası kodu public_html dizinine checkout edecek bir script çalıştırın.
3. Local geliştirme makinenizden bu bare repo’ya push yapın.

Basit bir post-receive hook örneği:

#!/bin/bash
GIT_WORK_TREE=/home/kullanici/public_html git checkout -f
cd /home/kullanici/public_html
# Örneğin cache temizleme veya composer install gibi ek adımlar

Bu yöntemle canlı dosyalar, localden ya da merkezi Git platformundan sunucudaki bare repo’ya push ettiğiniz anda otomatik güncellenir. WordPress teması veya eklentisi geliştiriyorsanız oldukça konforludur.

Cron tabanlı deploy

Bazı projelerde doğrudan push ile canlıyı tetiklemek istemeyebilirsiniz; örneğin önce staging ortamında test etmek istersiniz. Bu durumda paylaşımlı hostingte aşağıdaki gibi bir yaklaşım kullanılabilir:

• Sunucuda normal (bare olmayan) bir repo oluşturun ve origin uzak depo adresini tanımlayın.
• Cron ile her 5-10 dakikada bir basit bir script çalıştırın:

#!/bin/bash
cd /home/kullanici/public_html
git fetch origin
git reset --hard origin/main

Bu sayede ana branch üzerinde onayladığınız değişiklikler kısa aralıklarla canlıya yansır. Dezavantajı, sıfır kesinti ve atomik deploy senaryoları için yeterli olmamasıdır; yine de manuel FTP’den çok daha güvenlidir.

Paylaşımlı hostingte WordPress için özel notlar

WordPress projelerinde Git ile deploy yaparken en çok karıştırılan kısım, hangi dosyaların repoda tutulacağı meselesidir. Genel olarak şu yaklaşımı öneriyoruz:

• core WordPress dosyaları (wp-admin, wp-includes) genelde repoda tutulabilir, ancak güncelleme yönetimini iyi kurgulamanız gerekir.
• wp-content/themes içindeki kendi temanızı ve özel eklentilerinizi mutlaka Git ile yönetin.
• wp-content/uploads klasörünü repoya eklemeyin; bunu .gitignore ile hariç bırakın. Bu klasör canlı ortamda kullanıcı yüklemeleriyle sürekli değişir.

Paylaşımlı hostingte staging ortamı kurmak, özellikle WordPress içinde kritik bir adımdır. cPanel üzerinde alt alan adı ve klonlama adımlarını detaylı anlattığımız WordPress staging ortamı kurma rehberini mutlaka bu yazıyla birlikte okumanızı öneririz. Staging ortamıyla birlikte, Git tabanlı deploy çok daha güvenli hale gelir.

VPS Üzerinde Git ile CI/CD ve Sıfır Kesinti Deploy

VPS tarafına geçtiğinizde oyun bambaşka bir seviyeye çıkıyor. Root erişiminiz, tam dosya sistemi kontrolünüz ve servisleri yeniden başlatabilme özgürlüğünüz var. Bu da gerçek anlamda CI/CD, sıfır kesinti deploy ve daha gelişmiş mimariler kurmanıza izin veriyor.

Temel mimari: repo, build, release klasörleri

DCHost VPS üzerinde önerdiğimiz klasik yapı, Capistrano benzeri bir release dizin mimarisi:

• /var/www/proje/repo: Sunucudaki Git deposu (bare veya normal olabilir).
• /var/www/proje/releases: Her deploy için ayrı klasör, örneğin 2024-02-03_1530 gibi timestamp ile.
• /var/www/proje/current: Nginx / Apache’nin kök dizini olarak işaret ettiği sembolik link.

Deploy sırasında yapılanlar:

1. Yeni release klasörü oluşturulur.
2. İlgili commit bu klasöre checkout edilir veya CI’nin ürettiği paket buraya açılır.
3. composer install, npm build, asset kopyalama, cache clear gibi adımlar bu klasörde çalıştırılır.
4. Veritabanı migration gerekiyorsa uygulanır.
5. current sembolik linki yeni release klasörüne güncellenir.
6. PHP-FPM / queue worker gibi servisler reload edilir.

Bu akış sayesinde deploy işlemi, tek bir sembolik link güncellemesiyle neredeyse atomik hale gelir; eski release klasörünü sakladığınız için rollback de saniyeler sürer.

Bu prensibin üzerine kurulu, rsync ve sembolik sürümlerle sıfır kesinti dağıtımı adım adım anlattığımız VPS’e sıfır kesinti CI/CD rehberimize mutlaka göz atın; burada ise WordPress ve PHP odağında pratik detayları netleştireceğiz.

CI tarafı: GitHub Actions örneği ile düşünmek

VPS için modern ve yaygın pratik, deploy işini Git deposu tarafındaki CI sistemine bırakmaktır. Örneğin GitHub Actions ile şu adımları kolaylıkla kurgulayabilirsiniz:

• main branch’e her push olduğunda tetiklenen workflow
• PHP unit testleri, lint ve basit güvenlik taramaları
• SCSS/JS build adımları (npm, yarn vs.)
• Ortaya çıkan artefaktın VPS’e rsync ile gönderilmesi
• Sunucuda deploy scriptinin tetiklenmesi

GitHub Actions ile gerçek bir senaryoyu, örnek YAML dosyasıyla beraber GitHub Actions ile VPS’e otomatik deploy ve sıfır kesinti yayın yazımızda ayrıntılı olarak gösterdik. Bu yazıyı, burada anlattığımız mimariyle birlikte okursanız, teoriden pratiğe geçiş oldukça hızlı olacaktır.

VPS’te WordPress için Git tabanlı mimari

WordPress’i VPS üzerinde yönetirken Git ve CI/CD kullanmanın iki temel yaklaşımdan biriyle yapıldığını görüyoruz:

1. Klasik yaklaşım: Tam WordPress kurulumunu (core + tema + eklentiler) repoda tutmak.
2. Composer tabanlı yaklaşım: WordPress’i bir bağımlılık olarak yöneten, daha modern ama daha teknik bir mimari.

Klasik senaryo için uygulanabilir bir akış şöyle olabilir:

• WordPress core, tema ve kullandığınız özel eklentiler Git repoda.
• wp-config.php’nin hassas kısımları (.env dosyasından okunan) ortam değişkenleri ile besleniyor.
• wp-content/uploads klasörü repoda değil; canlı ortamda local disk veya Object Storage üzerinde saklanıyor.
• Deploy sırasında uploads klasörü dokunulmadan bırakılıyor, sadece kod tarafı güncelleniyor.

Geliştirme, staging ve canlı ortamlar için kaynak ayrımı ve veri senkronizasyonu gibi konuları, WordPress ve Laravel odaklı olarak geliştirme–staging–canlı yolculuğu rehberimizde detaylı anlattık. Oradaki kavramları, burada anlattığımız Git tabanlı deploy modeliyle birleştirdiğinizde oldukça sağlam bir mimari ortaya çıkar.

Genel PHP projeleri (Laravel, Symfony, özel yazılım) için notlar

WordPress dışındaki PHP projelerinde (Laravel, Symfony veya tamamen özel bir framework) CI/CD konusu genellikle şu adımları içerir:

• CI ortamında composer install –no-dev ve production optimizasyonları (config cache, route cache vs.)
• Ön uç derleme adımları (Vite, Webpack, Mix vs.)
• Ortaya çıkan build klasörlerinin pakete dahil edilmesi
• VPS üzerinde .env dosyalarının ve gizli anahtarların yönetimi

.env ve benzeri gizli bilgileri Git repoda asla tutmamalısınız. Bu konuda DCHost VPS üzerinde pratik öneriler sunduğumuz VPS’te .env ve gizli anahtar yönetimi yazımızı mutlaka incelemenizi tavsiye ederiz.

WordPress ve PHP Siteleri İçin Uygulanabilir CI/CD Senaryoları

Şimdi biraz daha somutlaşalım. Farklı profil ve ekipler için üç tipik senaryo çizelim: tek WordPress sitesi olan küçük işletme, birden çok müşteri sitesi yöneten ajans ve karma PHP/WordPress projeleri olan ürün ekipleri.

Senaryo 1: Tek WordPress sitesi olan küçük işletme

Elinizde tek bir WordPress sitesi, paylaşımlı hosting ve basit bir geliştirme akışı olduğunu düşünelim. Bu durumda önerdiğimiz minimum kurgu:

• Localde geliştirme (tema / child tema, ufak eklentiler).
• Kodun Git’te tutulması (en azından tema klasörü seviyesinde).
• cPanel Git entegrasyonu veya SSH ile bare repo + post-receive hook.
• Canlıya almadan önce staging alt alanında testi yapılmış branch’ten merge ve deploy.

Burada CI tarafını çok karmaşıklaştırmaya gerek yok; önemli olan, FTP yerine Git kullanarak her değişikliğin kaydının tutulması ve istenirse geri dönülebilmesi. Ayrıca WordPress yedekleme stratejilerini anlatan WordPress yedekleme rehberimizde anlattığımız gibi, düzenli dosya ve veritabanı yedekleriyle bu akışı desteklerseniz risk büyük ölçüde azalır.

Senaryo 2: Onlarca WordPress sitesi yöneten ajans

Ajans tarafında birden fazla müşteri, ortak kullanılan tema/eklenti paketleri ve yoğun teslim takvimi devreye girer. Burada Git ve CI/CD, neredeyse mecburi hale gelir. Örnek bir mimari:

• Her müşteri için ayrı Git deposu, ortak paketler (tema/eklenti) için ayrı monorepo veya paket deposu.
• Geliştirme, staging, canlı için ayrı branch yapısı (örneğin feature, develop, main).
• DCHost üzerindeki paylaşımlı hosting veya VPS hesaplarında staging alt alanları.
• CI tarafında: kod kalitesi kontrolü, temel testler ve paketleme.
• Deploy scriptleriyle her müşteri sitesini ilgili sunucuya SSH + rsync üzerinden otomatik dağıtma.

Staging ve canlı ortam ayrımını, özellikle yüksek trafik alan WordPress siteleri için Blue-Green deployment ile sıfır kesinti güncelleme yazımızda daha ileri seviyede anlattık. Ajans yapılarında, bu stratejiyi en azından büyük müşteriler için uygulamanızı şiddetle öneriyoruz.

Senaryo 3: Karma PHP/WordPress projeleri olan ürün ekipleri

Hem WordPress tabanlı bir pazarlama sitesi, hem de arka tarafta Laravel gibi bir framework ile yazılmış uygulama barındıran ekiplerde durum biraz daha sofistike. Burada önerimiz:

• WordPress ve ana uygulama için ayrı Git depoları.
• VPS tarafında her biri için ayrı vhost ve ayrı deploy pipeline.
• CI tarafında ortak adımlar (test, build) ama deploy adımlarının proje bazında ayrılması.
• Ortak kullanılan servisler (Redis, veritabanı, queue, object storage) için iyi tanımlanmış env değişkenleri.

Bu tip yapılarda CI/CD ve ortamlara göre yapılandırma konularını daha derinlemesine ele aldığımız sıfır kesinti CI/CD rehberi ve WordPress ölçeklendirme yol haritası yazıları da size yol gösterecektir.

Veritabanı, Yedek ve Rollback Stratejileri

Ne kadar iyi CI/CD kurarsanız kurun, veritabanı ve geri dönüş planınız zayıfsa canlı ortamda risk halen yüksektir. WordPress ve genel PHP projeleri için dikkat edilmesi gereken başlıkları özetleyelim.

WordPress veritabanı güncellemeleri

WordPress’te veritabanı değişiklikleri genelde iki kaynaktan gelir:

• Core, tema ve eklenti güncellemelerinin otomatik veritabanı migration’ları.
• Özel geliştirme yaptığınız eklenti veya temadaki şema değişiklikleri.

CI/CD hattı kurduğunuzda şu prensiplere dikkat edin:

• Deploy öncesinde mutlaka tam veritabanı yedeği alın (mysqldump veya benzeri).
• Büyük şema değişikliklerini yoğun trafik dışı saatlere planlayın.
• Özel eklentileriniz için versiyon bazlı upgrade scriptleri yazın; böylece aynı migration iki kez çalışmaz.

Laravel ve benzeri framework’lerde migration yönetimi

Framework tabanlı PHP projelerinde (Laravel, Symfony vb.) veritabanı şema değişiklikleri migration dosyalarıyla yönetilir. CI/CD pipeline’ınıza genelde şu adımı eklemeniz gerekir:

php artisan migrate --force

Ancak bu komutun da riskleri var; çok uzun süren migration işlemleri canlı sitede lock ve yavaşlamaya sebep olabilir. Büyük değişikliklerde, önceden planlanmış bakım pencereleri ve okuma-yazma ayrımı gibi mimari kararlar devreye girer. Bu seviyede ihtiyaçlarınız varsa, veritabanı replikasyon ve yüksek erişilebilirlik konularını ele aldığımız yazılara da göz atmanızı öneririz.

Yedekleme ve geri dönüş (rollback) pratikleri

Sağlıklı bir CI/CD hattının ayrılmaz parçası yedek ve rollback mekanizmalarıdır. Genel öneriler:

• Dosya tarafında: VPS’te her release klasörünü, en azından birkaç sürüm boyunca saklayın; rollback için sadece sembolik linki geri almanız yeterli olsun.
• Veritabanı tarafında: Her üretim deploy’undan hemen önce otomatik dump alın ve saklama politikalarınızı (RPO/RTO) netleştirin.
• Paylaşımlı hostingte: cPanel yedeklerinizi CI/CD ile entegre düşünün; örneğin deploy sonrasında otomatik yedek tetikleyebilirsiniz.

Yedek stratejilerini genel olarak planlamak için, farklı iş yükleri için hazırladığımız RPO/RTO odaklı yedekleme rehberini de okumanızı öneririz.

Güvenlik, Erişim Yönetimi ve Gizli Bilgiler

SSH ile otomatik deploy ve CI/CD kullanırken güvenlik tarafını ihmal etmek, kazandığınız tüm avantajları tek hamlede sıfırlayabilir. DCHost üzerinde gördüğümüz başarılı kurulumların ortak noktaları şunlar:

SSH anahtarları ve deploy kullanıcısı

• Deploy işlemleri için ayrı bir Linux kullanıcısı tanımlayın (örneğin deploy).
• Bu kullanıcı için güçlü, mümkünse yalnızca SSH anahtarlarıyla girişe izin verin.
• CI sisteminizin public anahtarını sadece bu kullanıcıya ekleyin; root’a doğrudan erişim vermeyin.
• Bu kullanıcının sadece gerekli dizinlere erişimi ve gerektiğinde sudo ile kısıtlı komut çalıştırma yetkisi olsun.

.env ve API anahtarlarının yönetimi

Daha önce de vurguladığımız gibi, .env dosyaları ve diğer gizli bilgiler kesinlikle Git deposunda olmamalı. Bunun yerine:

• VPS üzerinde .env dosyası sadece sunucuda tutulmalı, CI pipeline’ı bu dosyaya hiç dokunmamalı.
• Paylaşımlı hostingte de benzer şekilde, yapılandırma dosyalarını repodan ayırın.
• Gerektiğinde secret manager veya şifreli vault çözümleri kullanın.

Bu konuda, gerçek senaryolar üzerinden giden VPS’te gizli anahtar yönetimi yazımızdaki önerileri CI/CD tasarımınıza mutlaka entegre edin.

Log’lar, izleme ve alarm

Bir deploy başarısız olduğunda veya beklenmedik bir yavaşlama yaşandığında, olayı hızlı teşhis edebilmek için log ve izleme katmanı şart:

• Web sunucusu (Nginx/Apache) loglarını merkezi bir yerde toplayın.
• PHP hata loglarını CI/CD sonrası özellikle yakından izleyin.
• Uptime ve response time ölçümleri için basit bir monitoring aracı kullanın.

DCHost blogda VPS izleme ve alarm kurulumuna özel hazırladığımız rehberler, bu konuda sağlam bir başlangıç yapmanıza yardımcı olacaktır.

DCHost Üzerinde Git ile Otomatik Deploy’a Başlamak

Buraya kadar anlattığımız tüm kavramlar, ister paylaşımlı hosting ister VPS kullanın, DCHost altyapısı üzerinde uygulanabilir. Paylaşımlı hosting paketlerimizde cPanel ve SSH erişimi sayesinde basit Git tabanlı akışları rahatlıkla kurabilirsiniz. Daha kapsamlı CI/CD ve sıfır kesinti hedefleyen mimariler için ise DCHost VPS çözümleri, root erişimi ve esnek kaynak planlamasıyla size geniş bir hareket alanı sunar.

Özetlemek gerekirse:

• FTP ile manuel dosya kopyalamayı bırakıp, kodu her zaman Git ile yönetmeye geçin.
• Önce staging ortamı kurup, sonra canlı deploy’u otomatikleştirin.
• Paylaşımlı hostingte basit hook veya cron tabanlı senaryolarla başlayın.
• VPS’e geçtiğinizde release klasörleri, sembolik linkler ve CI pipeline’ları ile sıfır kesinti hedefine yaklaşın.
• Her zaman yedek, rollback ve güvenlik (SSH, .env, erişim yetkileri) tarafını ihmal etmeyin.

DCHost olarak, Git ile otomatik deploy ve CI/CD kurgularını gerçek projelerde her gün görüyoruz; bu yüzden nelerin sahada işe yaradığını, nelerin sadece teoride kaldığını iyi biliyoruz. Eğer mevcut WordPress veya PHP siteniz için bu geçişi planlıyorsanız, uygun DCHost paylaşımlı hosting ya da VPS planını seçip yukarıdaki adımlarla küçükten başlayın. İhtiyaçlar büyüdükçe, blogumuzda paylaştığımız daha ileri seviye rehberlerle mimarinizi adım adım olgunlaştırabilirsiniz.