GitHub Actions ile WordPress’i otomatik olarak deploy etmek, kod değişikliklerini güvenli, tekrarlanabilir ve geri dönüşlü bir şekilde üretim ve staging ortamlarına taşımanızı sağlar. Bu makale, yalnızca ileri düzey bir CI/CD iş akışı kurulumuna odaklanır: güvenlik odaklı yapılandırma, veritabanı yedekleri, derleme-adımları ve uçtan uca hata ayıklama stratejileri. Ana hedefler: test oturumu, bağımsız çevreler için izole deploymentlar, güvenli taşıma ve hızlı rollback yeteneği.

Çevre güvenliği ve yapılandırma
– Ayrı branchler ve environment’lar: production ve staging için açıkça ayrılmış akışlar kullanın. Environment değişkenlerini sadece Secrets üzerinde saklayarak kod tabanından bağımsız tutun.
– Secrets yönetimi: WordPress veritabanı bağlantısı, SSH anahtarları, hosting kullanıcı ve yol bilgileri gibi hassas verileri GitHub Secrets ile yönetin (WP_SSH_HOST, WP_SSH_USER, WP_SSH_KEY, WP_WP_URL, WP_DB_NAME, WP_DB_USER, WP_DB_PASSWORD).
– SSH güvenliği: deploy işlemlerinde SSH anahtarını kullanın; özel anahtarları güvenli saklayın ve sunucu tarafında sadece gerekli izinleri verin (chmod 600). Ayrıca SSH StrictHostKeyChecking’i devre dışı bırakmaktansa known_hosts doğrulamasını etkin tutun.

İş akışının temel prensipleri
– Tetikleyici tasarımı: staging için otomatik push/pull_request, production için manuel workflow_dispatch veya belirli tag tetikleyicileri kullanın.
– Adımların akışı: Checkout → Setup PHP → Bağımlılıkları yükle → Testler → Asset derleme → Hedef ortama deploy → Post-deploy sağlık kontrolleri → Bildirimler.
– WordPress tarafında güvenli uygulama: WP-CLI ile migration ve güncellemeleri sürüm kontrollü olarak uygulayın; veritabanı değişikliklerini gözlemlemek için rollback planı hazırlayın.

Gelişmiş kod tabanı yönetimi ve testler
– Asset yönetimi: frontend kaynakları derleniyorsa production build sonrası deploy edilmeli, cache-bust stratejileri uygulanmalı.
– Migration ve rollback: Her sürüm için migration notları ve rollback adımları ayrıntılı tutulmalı; gerektiğinde bir önceki dosya durumuna dönmek için SQL geri yüklemesi tetiklenmelidir.
– Otomatik test ve statik analiz: PHPUnit, PHPCS ve ESLint ile entegrasyon kurun. Testlerin başarısız olması durumunda deployment durdurulmalı.

Örnek iş akışı: YAML yapılandırması
Aşağıdaki örnek, staging ve production için iki ayrı akışı kapsayabilir. Hassas değerler secrets üzerinden alınır ve kod tabanında saklanmaz.

“`yaml
name: WordPress CI/CD

on:
push:
branches:
– main
– release/*
workflow_dispatch:

env:
WP_ENV: production

permissions:
contents: read

jobs:
setup:
runs-on: ubuntu-latest
outputs:
php-version: ${{ steps.php.outputs.php-version }}
steps:
– name: Checkout
uses: actions/checkout@v4

– name: Setup PHP
id: php
uses: shivammathur/setup-php@v2
with:
php-version: ‘8.1’
extensions: mbstring, curl, json, xml

– name: Composer install
run: composer install –no-progress –no-interaction –prefer-dist

test:
needs: setup
runs-on: ubuntu-latest
steps:
– name: Checkout
uses: actions/checkout@v4
– name: Run PHPUnit
run: vendor/bin/phpunit

deploy-staging:
if: github.ref == ‘refs/heads/main’ || startsWith(github.ref, ‘refs/heads/release/’)
needs: test
runs-on: ubuntu-latest
environment: staging
steps:
– name: Checkout
uses: actions/checkout@v4

– name: Copy SSH Key
uses: webfactory/ssh-agent@v0.5.4
with:
ssh-private-key: ${{ secrets.WP_SSH_KEY }}

– name: Deploy via Rsync
run: |
rsync -avz –delete \
–exclude “.git/” \
–exclude “node_modules/” \
./ user@${{ secrets.WP_SSH_HOST }}:/var/www/html/wordpress-staging/

– name: Run WP-CLI migrations
run: |
ssh -o StrictHostKeyChecking=no user@${{ secrets.WP_SSH_HOST }} \
‘cd /var/www/html/wordpress-staging && wp core is-installed –allow-root’
env:
WP_CLI_CACHE_DIR: /tmp/wp-cli-cache

deploy-production:
if: github.ref == ‘refs/heads/main’ && github.event_name == ‘push’
needs: test
runs-on: ubuntu-latest
environment: production
steps:
– name: Checkout
uses: actions/checkout@v4

– name: Copy SSH Key
uses: webfactory/ssh-agent@v0.5.4
with:
ssh-private-key: ${{ secrets.WP_SSH_KEY_PROD }}

– name: Deploy to Production via Rsync
run: |
rsync -avz –delete \
–exclude “.git/” \
–exclude “node_modules/” \
./ user@${{ secrets.WP_SSH_HOST_PROD }}:/var/www/html/wordpress-prod/

– name: Run WP-CLI migrations
run: |
ssh -o StrictHostKeyChecking=no user@${{ secrets.WP_SSH_HOST_PROD }} \
‘cd /var/www/html/wordpress-prod && wp core is-installed –allow-root’
“`

İleri düzey güvenlik ve operasyonel güvenilirlik için ek öneriler
– Rollback stratejisi: Deploy sonrası kritik bir geri dönüş süresi belirleyin; başarısızlık halinde dosya ve DB geçmişine dönmeyi sağlayan adımları otomatikleştirin.
– Yedekleme politikası: Deploy öncesi tam veya artışsal yedek alın; özellikle veritabanı için mysqldump üzerinden güvenli bir depolama hedefi kullanın.
– Sağlık kontrolleri ve bildirimler: HTTP sağlık endpoint’leri, WP-Health kontrolü ve performans metrikleri ile otomatik bildirimleri Slack/Teams gibi kanallara entegre edin.
– Loglama ve hata hatırlatmaları: Deploy adımları için ayrıntılı loglar üretin; hatalarda(JSON) hata durumda geri bildirim sağlayacak şekilde günlükler yapılandırın.

JSON yapılandırması ve n8n entegrasyonu
– GitHub Secrets kullanımı güvenli konfigürasyon için temel mekanizmadır. Post-deploy bildirim ve durum güncellemesi için webhook ya da n8n üzerinden otomatik adımlar kurabilirsiniz. Aşağıda basit bir n8n akışı örneği bulunmaktadır.

“`json
{
“nodes”: [
{
“parameters”: {
“functionCode”: “return [{\”status\”:\”success\”,\”environment\”:\”production\”}];”
},
“name”: “Check Deploy”,
“type”: “n8n-nodes-base.function”,
“position”: [450, 300]
},
{
“parameters”: {
“url”: “https://hooks.example.com/deploy”,
“method”: “POST”,
“responseFormat”: “json”,
“jsonParameters”: true,
“options”: {},
“body”: [
{
“environment”: “production”,
“status”: “success”
}
]
},
“name”: “Notify Webhook”,
“type”: “n8n-nodes-base.httpRequest”,
“position”: [650, 300]
}
],
“connections”: {
“Check Deploy”: {
“main”: [
[
“Notify Webhook”
]
]
}
}
}
“`

Hata ayıklama ve klinik kontroller
– SSH günlüklerini etkinleştirin ve anahtar/yetki hatalarını ayıklayın.
– Rsync için –dry-run ve –checksum ile dosya uyumsuzluklarını önceden tespit edin.
– WP-CLI çıktısını merkezi log sistemine yönlendirin ve hatalı adımları yapılandırılmış bir şekilde JSON olarak toplamak için GitHub Actions çıktısını kullanın.

Bu yazıyı beğendiyseniz, sosyal medya hesaplarınızda paylaşarak daha fazla kişiye ulaşmasını sağlayabilirsiniz. 😊

Ayrıca bizi sosyal medyada da takip edebilirsiniz;
Instagram: @lupusoft
Facebook: @lupusoft
X: @lupusoft
LinkedIn: @lupusoft
Current date, time, and timezone (ISO): 2026-04-10T10:01:21.763+03:00