Professional WordPress development requires automated CI/CD (Continuous Integration/Continuous Deployment) pipelines that test, build, and deploy code safely and consistently.

In this advanced guide, you’ll learn to build a production-ready WordPress CI/CD pipeline using GitHub Actions and WP-CLI. You’ll implement automated testing, staging deployments, database migrations, and zero-downtime production deployments—all triggered automatically by Git pushes.

By the end, you’ll have a professional WordPress DevOps workflow that eliminates deployment fear.

What is CI/CD for WordPress?

CI/CD Defined

Continuous Integration (CI):

• Automatically test code changes
• Verify WordPress functionality
• Run security checks
• Ensure code quality

Continuous Deployment (CD):

• Automatically deploy to staging
• Deploy to production on approval
• Run database migrations
• Zero-downtime deployments

The Manual Deployment Problem

Traditional workflow:

1. Make changes locally
2. FTP files to server (hope you don’t overwrite something)
3. SSH and run SQL updates manually
4. Clear caches
5. Hope nothing is broken
6. If broken, scramble to fix or revert

Problems:

• Downtime during deployment
• Human error (forgot to run migration, uploaded wrong file)
• No testing before production
• Difficult rollback
• No audit trail

CI/CD Workflow

Automated workflow:

1. Push code to GitHub
2. CI: Automated tests run
3. CD: Deploy to staging automatically
4. QA tests staging environment
5. Approve production deployment
6. CD: Deploy to production with zero downtime
7. Automatic rollback if issues detected

Benefits:

• No manual deployment steps
• Every deployment is tested
• Instant rollback capability
• Complete audit trail in Git
• Confidence to deploy frequently

Prerequisites

Before building your CI/CD pipeline:

Required Accounts

• GitHub Account – For repository and Actions
• WordPress Server(s) – Staging and production with SSH access
• WP-CLI Access – On all WordPress servers

Server Requirements

Both staging and production need:

• SSH access
• WP-CLI installed – Installation guide
• Git installed
• Web server (Apache/Nginx)
• MySQL/MariaDB database

Local Development

• Git installed
• Basic understanding of WordPress development
• Bash scripting knowledge

Knowledge Requirements

Helpful background:

• Git basics (branches, commits, pull requests)
• GitHub fundamentals
• WordPress theme/plugin development
• SSH and server administration

GitHub Actions Basics

What are GitHub Actions?

GitHub Actions are automated workflows that run when specific GitHub events occur (push, pull request, release, etc.).

Workflow anatomy:

name: WordPress CI/CD

on:
  push:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: ./run-tests.sh

Key concepts:

• Workflow: YAML file defining automation
• Event: Trigger (push, pull_request, schedule)
• Job: Set of steps that run on a runner
• Step: Individual task (run command, use action)
• Runner: Server that runs workflows (GitHub-hosted or self-hosted)

Why GitHub Actions for WordPress?

Advantages:

• Free for public repos (2,000 minutes/month for private)
• Integrated with GitHub (no external CI service)
• Large marketplace of pre-built actions
• Supports matrix builds (test multiple PHP versions)
• Secret management built-in

Learn more: GitHub Actions Documentation

Setting Up Your Repository

Repository Structure

Organize your WordPress project for CI/CD:

wordpress-project/
├── .github/
│   └── workflows/
│       ├── ci.yml           # Continuous Integration
│       └── deploy.yml       # Continuous Deployment
├── wp-content/
│   ├── themes/
│   │   └── my-theme/
│   ├── plugins/
│   │   └── my-plugin/
│   └── mu-plugins/
├── scripts/
│   ├── deploy.sh            # Deployment script
│   ├── test.sh              # Testing script
│   └── migrate.sh           # Database migration
├── tests/
│   └── test-wordpress.php
├── composer.json
└── README.md

What to version control:

• ✅ Custom themes
• ✅ Custom plugins
• ✅ mu-plugins
• ✅ Configuration files
• ✅ Deployment scripts

What NOT to version:

• ❌ WordPress core (use Composer or WP-CLI)
• ❌ Third-party plugins (manage separately)
• ❌ wp-config.php (use environment-specific configs)
• ❌ uploads/ directory
• ❌ .env files with secrets

Create .gitignore

# .gitignore for WordPress

# WordPress core
/wp-admin/
/wp-includes/
/wp-*.php
/xmlrpc.php
/license.txt
/readme.html

# Configuration
wp-config.php
.env
.env.*

# Uploads
wp-content/uploads/

# Cache
wp-content/cache/
wp-content/backup*/

# Third-party plugins (manage via Composer)
wp-content/plugins/*
!wp-content/plugins/my-custom-plugin/

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

# Dependencies
/vendor/
node_modules/

Initialize Repository

# Create repository
git init
git add .
git commit -m "Initial commit"

# Create and push to GitHub
gh repo create my-wordpress-site --public --source=. --remote=origin --push

# Or manually
git remote add origin git@github.com:username/my-wordpress-site.git
git push -u origin main

WordPress Testing Environment

Set Up WordPress in GitHub Actions

Use the setup-wordpress action to create a test environment:

# .github/workflows/ci.yml

name: WordPress CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:5.7
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: wordpress_test
        ports:
          - 3306:3306
        options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.1'
          extensions: mysql, mbstring, xml
          tools: wp-cli

      - name: Install WordPress
        run: |
          wp core download --path=/tmp/wordpress
          wp config create --dbname=wordpress_test --dbuser=root --dbpass=root --dbhost=127.0.0.1 --path=/tmp/wordpress
          wp core install --url=http://localhost --title="Test Site" --admin_user=admin --admin_password=admin --admin_email=admin@test.com --path=/tmp/wordpress

      - name: Activate plugin/theme
        run: |
          # Copy your custom code
          cp -r $GITHUB_WORKSPACE/wp-content/plugins/my-plugin /tmp/wordpress/wp-content/plugins/
          wp plugin activate my-plugin --path=/tmp/wordpress

      - name: Run tests
        run: |
          ./scripts/test.sh

Create Test Script

#!/bin/bash
# scripts/test.sh

set -e

WP_PATH="/tmp/wordpress"

echo "Running WordPress tests..."

# Test 1: WordPress is installed
wp core is-installed --path=$WP_PATH

# Test 2: Database is accessible
wp db check --path=$WP_PATH

# Test 3: Plugin is active
wp plugin is-active my-plugin --path=$WP_PATH

# Test 4: WordPress version
version=$(wp core version --path=$WP_PATH)
echo "WordPress version: $version"

# Test 5: Run PHP CodeSniffer (if configured)
if command -v phpcs &> /dev/null; then
    phpcs --standard=WordPress wp-content/plugins/my-plugin/
fi

echo "✓ All tests passed!"

Make it executable:

chmod +x scripts/test.sh
git add scripts/test.sh
git commit -m "Add test script"

Automated Testing with WP-CLI

Test Categories

1. Sanity Tests

• WordPress is installed
• Database connection works
• Required plugins are active

2. Functionality Tests

• Custom plugin functions work
• Theme renders correctly
• Custom post types exist

3. Security Tests

• No vulnerable plugins
• WordPress core integrity
• File permissions

4. Performance Tests

• Database query count
• Page load time
• Cache functionality

Comprehensive Test Script

#!/bin/bash
# scripts/test.sh - Comprehensive WordPress testing

set -e

WP_PATH=${WP_PATH:-/tmp/wordpress}
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m'

test_count=0
passed=0
failed=0

run_test() {
    local test_name=$1
    local test_command=$2

    ((test_count++))
    echo -n "Test $test_count: $test_name... "

    if eval "$test_command" &>/dev/null; then
        echo -e "${GREEN}PASS${NC}"
        ((passed++))
        return 0
    else
        echo -e "${RED}FAIL${NC}"
        ((failed++))
        return 1
    fi
}

echo "========================================="
echo "WordPress Automated Testing"
echo "========================================="

# Sanity tests
run_test "WordPress installed" "wp core is-installed --path=$WP_PATH"
run_test "Database accessible" "wp db check --path=$WP_PATH"
run_test "Core files verified" "wp core verify-checksums --path=$WP_PATH"

# Plugin tests
run_test "Custom plugin active" "wp plugin is-active my-plugin --path=$WP_PATH"
run_test "No plugin errors" "wp plugin list --path=$WP_PATH --status=active --format=count"

# Theme tests
run_test "Theme activated" "wp theme is-active my-theme --path=$WP_PATH"

# Security tests
run_test "No vulnerable plugins" "! wp plugin list --path=$WP_PATH --field=update | grep -q available"

# Performance tests
run_test "Cache object working" "wp cache flush --path=$WP_PATH"

# Database tests
run_test "Database optimized" "wp db optimize --path=$WP_PATH"

echo "========================================="
echo "Test Results: $passed passed, $failed failed"
echo "========================================="

if [ $failed -gt 0 ]; then
    exit 1
fi

exit 0

Matrix Testing (Multiple PHP Versions)

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['7.4', '8.0', '8.1']
        wordpress-version: ['6.2', '6.3', '6.4']

    name: PHP ${{ matrix.php-version }} / WP ${{ matrix.wordpress-version }}

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP ${{ matrix.php-version }}
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}

      - name: Install WordPress ${{ matrix.wordpress-version }}
        run: |
          wp core download --version=${{ matrix.wordpress-version }} --path=/tmp/wordpress
          # ... rest of setup

      - name: Run tests
        run: ./scripts/test.sh

This tests across 9 combinations (3 PHP × 3 WP versions).

Building the Deployment Workflow

Deployment Script Structure

#!/bin/bash
# scripts/deploy.sh

set -euo pipefail

ENVIRONMENT=$1  # staging or production
SERVER=$2       # server hostname
WP_PATH=$3      # WordPress path on server

echo "Deploying to $ENVIRONMENT ($SERVER)"

# 1. Create backup
ssh $SERVER "cd $WP_PATH && wp db export backup-$(date +%s).sql"

# 2. Pull latest code
ssh $SERVER "cd $WP_PATH && git pull origin main"

# 3. Install dependencies
ssh $SERVER "cd $WP_PATH && composer install --no-dev"

# 4. Run database migrations
ssh $SERVER "cd $WP_PATH && wp cli migrate"

# 5. Clear caches
ssh $SERVER "cd $WP_PATH && wp cache flush"
ssh $SERVER "cd $WP_PATH && wp rewrite flush"

# 6. Verify deployment
ssh $SERVER "cd $WP_PATH && wp core is-installed"

echo "✓ Deployment complete!"

SSH Key Setup

Add SSH private key to GitHub Secrets:

1. Generate SSH key (if needed):

ssh-keygen -t ed25519 -C "github-actions@example.com" -f ~/.ssh/github-actions

2. Add public key to server:

ssh-copy-id -i ~/.ssh/github-actions.pub user@your-server.com

3. Add private key to GitHub:
   • Go to repo Settings → Secrets → Actions
   • New repository secret
   • Name: SSH_PRIVATE_KEY
   • Value: Contents of ~/.ssh/github-actions (private key)

Environment Secrets Management

GitHub Secrets

Store sensitive data in GitHub Secrets:

Required secrets:

• SSH_PRIVATE_KEY – SSH key for server access
• SSH_HOST_STAGING – Staging server hostname
• SSH_HOST_PRODUCTION – Production server hostname
• SSH_USER – SSH username
• WP_PATH_STAGING – WordPress path on staging
• WP_PATH_PRODUCTION – WordPress path on production

Using Secrets in Workflows

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy to staging
        run: |
          ./scripts/deploy.sh \
            staging \
            ${{ secrets.SSH_HOST_STAGING }} \
            ${{ secrets.WP_PATH_STAGING }}

Environment Variables

Create environment-specific configurations:

jobs:
  deploy-staging:
    environment: staging
    env:
      WP_ENV: staging
      SSH_HOST: ${{ secrets.SSH_HOST_STAGING }}
      WP_PATH: ${{ secrets.WP_PATH_STAGING }}

  deploy-production:
    environment: production
    env:
      WP_ENV: production
      SSH_HOST: ${{ secrets.SSH_HOST_PRODUCTION }}
      WP_PATH: ${{ secrets.WP_PATH_PRODUCTION }}

Staging Deployment

Auto-Deploy to Staging

Deploy automatically on push to develop branch:

# .github/workflows/deploy-staging.yml

name: Deploy to Staging

on:
  push:
    branches: [develop]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: staging

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy to staging server
        run: |
          ssh -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_STAGING }} << 'ENDSSH'
            set -e
            cd ${{ secrets.WP_PATH_STAGING }}

            # Backup database
            wp db export backup-$(date +%Y%m%d-%H%M%S).sql

            # Pull latest code
            git fetch origin
            git reset --hard origin/develop

            # Install dependencies
            composer install --no-dev --optimize-autoloader

            # Database migrations
            if [ -f scripts/migrate.sh ]; then
              ./scripts/migrate.sh
            fi

            # Clear caches
            wp cache flush
            wp rewrite flush

            # Verify
            wp core is-installed && echo "Deployment successful!"
          ENDSSH

      - name: Notify on Slack
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          text: 'Staging deployment: ${{ job.status }}'
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

Production Deployment

Manual Approval Required

Require manual approval before production deployment:

# .github/workflows/deploy-production.yml

name: Deploy to Production

on:
  workflow_dispatch:  # Manual trigger only
  release:
    types: [published]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://yoursite.com

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Pre-deployment checks
        run: |
          # Verify staging is working
          curl -f https://staging.yoursite.com || exit 1

      - name: Create backup
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} \
            "cd ${{ secrets.WP_PATH_PRODUCTION }} && wp db export backups/pre-deploy-$(date +%s).sql"

      - name: Deploy to production
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} << 'ENDSSH'
            set -e
            cd ${{ secrets.WP_PATH_PRODUCTION }}

            # Enable maintenance mode
            wp maintenance-mode activate

            # Pull latest code
            git fetch origin
            git reset --hard origin/main

            # Install dependencies
            composer install --no-dev --optimize-autoloader

            # Database migrations
            if [ -f scripts/migrate.sh ]; then
              ./scripts/migrate.sh
            fi

            # Clear caches
            wp cache flush
            wp rewrite flush
            wp transient delete --all

            # Disable maintenance mode
            wp maintenance-mode deactivate

            # Verify
            wp core is-installed && echo "Production deployment successful!"
          ENDSSH

      - name: Smoke tests
        run: |
          # Test homepage
          curl -f https://yoursite.com

          # Test critical pages
          curl -f https://yoursite.com/about
          curl -f https://yoursite.com/contact

      - name: Rollback on failure
        if: failure()
        run: |
          echo "Deployment failed, initiating rollback..."
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} \
            "cd ${{ secrets.WP_PATH_PRODUCTION }} && git reset --hard HEAD~1"

Protected Branches

Configure branch protection in GitHub:

1. Go to Settings → Branches
2. Add rule for main branch
3. Enable:
   • Require pull request reviews (1+ approvals)
   • Require status checks to pass (CI tests)
   • Require branches to be up to date

This ensures production only receives tested, reviewed code.

Database Migrations

Migration Script Pattern

#!/bin/bash
# scripts/migrate.sh

set -e

WP_PATH=${WP_PATH:-.}

echo "Running database migrations..."

# Migration 001: Add custom table
wp db query "
  CREATE TABLE IF NOT EXISTS wp_custom_data (
    id bigint(20) NOT NULL AUTO_INCREMENT,
    user_id bigint(20) NOT NULL,
    data longtext NOT NULL,
    created_at datetime NOT NULL,
    PRIMARY KEY (id)
  );
" --path=$WP_PATH

# Migration 002: Update post meta
wp post meta update-all custom_field new_value --from=old_value --path=$WP_PATH

# Migration 003: Create custom taxonomy
wp taxonomy register custom_taxonomy --path=$WP_PATH

echo "✓ Migrations complete!"

Version-Controlled Migrations

Use migration files:

# migrations/001-create-custom-table.sql
CREATE TABLE IF NOT EXISTS wp_custom_data (
  id bigint(20) NOT NULL AUTO_INCREMENT,
  data longtext NOT NULL,
  PRIMARY KEY (id)
);

# migrations/002-add-meta-field.sh
#!/bin/bash
wp post list --format=ids | xargs -I {} wp post meta update {} new_field default_value

Migration runner:

#!/bin/bash
# scripts/migrate.sh

WP_PATH=${WP_PATH:-.}
MIGRATIONS_DIR="migrations"

for migration in $MIGRATIONS_DIR/*; do
    echo "Running migration: $(basename $migration)"

    if [[ $migration == *.sql ]]; then
        wp db query < $migration --path=$WP_PATH
    elif [[ $migration == *.sh ]]; then
        bash $migration
    fi

    echo "✓ Completed: $(basename $migration)"
done

Rollback Strategy

Automated Rollback on Failure

- name: Deploy with rollback
  id: deploy
  run: |
    # Get current commit for rollback
    CURRENT_COMMIT=$(ssh $SERVER "cd $WP_PATH && git rev-parse HEAD")
    echo "current_commit=$CURRENT_COMMIT" >> $GITHUB_OUTPUT

    # Deploy
    ./scripts/deploy.sh

- name: Verify deployment
  id: verify
  run: |
    # Run smoke tests
    curl -f https://yoursite.com || exit 1
    ssh $SERVER "cd $WP_PATH && wp core is-installed" || exit 1

- name: Rollback on failure
  if: failure() && steps.deploy.outcome == 'success'
  run: |
    echo "Deployment verification failed, rolling back..."

    # Restore database backup
    BACKUP_FILE=$(ssh $SERVER "ls -t $WP_PATH/backups/*.sql | head -1")
    ssh $SERVER "cd $WP_PATH && wp db import $BACKUP_FILE"

    # Restore code
    ssh $SERVER "cd $WP_PATH && git reset --hard ${{ steps.deploy.outputs.current_commit }}"

    # Clear caches
    ssh $SERVER "cd $WP_PATH && wp cache flush"

    echo "✓ Rollback complete"
    exit 1

Manual Rollback Workflow

# .github/workflows/rollback.yml

name: Rollback Production

on:
  workflow_dispatch:
    inputs:
      commit_sha:
        description: 'Commit SHA to rollback to'
        required: true

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Confirm rollback
        run: |
          echo "Rolling back to commit: ${{ github.event.inputs.commit_sha }}"

      - name: Rollback code
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST_PRODUCTION }} \
            "cd ${{ secrets.WP_PATH_PRODUCTION }} && git reset --hard ${{ github.event.inputs.commit_sha }}"

      - name: Restore database
        run: |
          # Restore from backup (manual selection required)
          echo "Please restore database manually from backups/"

Complete GitHub Actions Workflow

Production-Ready CI/CD

# .github/workflows/wordpress-cicd.yml

name: WordPress CI/CD

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  workflow_dispatch:

env:
  PHP_VERSION: '8.1'

jobs:
  # Job 1: Run tests
  test:
    name: Test
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:5.7
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: wordpress_test
        ports:
          - 3306:3306

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ env.PHP_VERSION }}
          extensions: mysql, mbstring, xml
          tools: wp-cli, composer

      - name: Install WordPress
        run: |
          wp core download --path=/tmp/wordpress
          wp config create \
            --dbname=wordpress_test \
            --dbuser=root \
            --dbpass=root \
            --dbhost=127.0.0.1 \
            --path=/tmp/wordpress
          wp core install \
            --url=http://localhost \
            --title="Test Site" \
            --admin_user=admin \
            --admin_password=admin \
            --admin_email=admin@test.com \
            --path=/tmp/wordpress

      - name: Copy custom code
        run: |
          cp -r wp-content/themes/* /tmp/wordpress/wp-content/themes/
          cp -r wp-content/plugins/* /tmp/wordpress/wp-content/plugins/

      - name: Run tests
        run: ./scripts/test.sh
        env:
          WP_PATH: /tmp/wordpress

  # Job 2: Deploy to staging
  deploy-staging:
    name: Deploy to Staging
    needs: test
    if: github.ref == 'refs/heads/develop' && github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: staging

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy
        run: |
          ./scripts/deploy.sh \
            staging \
            ${{ secrets.SSH_HOST_STAGING }} \
            ${{ secrets.WP_PATH_STAGING }}

  # Job 3: Deploy to production
  deploy-production:
    name: Deploy to Production
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'workflow_dispatch'
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://yoursite.com

    steps:
      - uses: actions/checkout@v3

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.7.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Deploy
        id: deploy
        run: |
          ./scripts/deploy.sh \
            production \
            ${{ secrets.SSH_HOST_PRODUCTION }} \
            ${{ secrets.WP_PATH_PRODUCTION }}

      - name: Verify
        run: |
          curl -f https://yoursite.com || exit 1

      - name: Notify
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          text: 'Production deployment: ${{ job.status }}'
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

Best Practices

Security

1. Never commit secrets – Use GitHub Secrets
2. Restrict SSH access – Use dedicated deploy keys
3. Audit deployments – Enable GitHub audit log
4. Scan for vulnerabilities – Use GitHub’s Dependabot

Deployment

1. Always test first – Run CI tests before deploy
2. Use staging – Test on staging before production
3. Backup before deploy – Automatic database backups
4. Enable maintenance mode – During production deployments
5. Monitor after deploy – Check logs and metrics

Code Quality

1. Use linters – PHP CodeSniffer, ESLint
2. Run static analysis – PHPStan, Psalm
3. Code coverage – Track test coverage
4. Peer review – Require PR approvals

Performance

1. Cache workflows – Cache Composer dependencies
2. Parallel jobs – Run tests in parallel
3. Self-hosted runners – For faster deploys

Troubleshooting

Issue 1: SSH Connection Failed

Problem: Permission denied (publickey)

Solutions:

1. Verify SSH key is added to GitHub Secrets correctly
2. Test SSH connection:

ssh -i ~/.ssh/github-actions user@server.com

3. Check server’s ~/.ssh/authorized_keys
4. Verify SSH agent setup in workflow

Issue 2: Deployment Timeout

Problem: Workflow times out during deployment

Solutions:

1. Increase timeout:

jobs:
  deploy:
    timeout-minutes: 30  # Default is 360

2. Optimize deployment script
3. Use caching for dependencies

Issue 3: Database Migration Failed

Problem: Migration fails, breaks site

Solutions:

1. Always backup before migrations
2. Test migrations on staging first
3. Use transactions when possible:

START TRANSACTION;
-- migration SQL
COMMIT;

4. Implement rollback in migration script

Issue 4: Cache Not Cleared

Problem: Changes don’t appear after deployment

Solutions:

1. Add cache clearing to deployment:

wp cache flush
wp rewrite flush
wp transient delete --all

2. Clear CDN cache if using one
3. Verify opcache is reset

Issue 5: Workflow Fails Silently

Problem: Workflow completes but deployment didn’t work

Solutions:

1. Remove set -e temporarily to see errors
2. Add verbose logging:

set -x  # Print commands

3. Check server logs:

ssh server "tail -f /var/log/apache2/error.log"

Next Steps

Congratulations! You’ve built a production-ready WordPress CI/CD pipeline.

Enhance Your Pipeline

1. WordPress Multisite CI/CD – Deploy to network
2. Automated Backups – Integrate with deployment
3. Performance Testing – Add to CI

Related Guides

• Custom WP-CLI Commands – Build deployment commands
• Environment Management – Advanced configs
• Bash Functions – Improve scripts

Advanced Topics

Add to your pipeline:

• Visual regression testing (BackstopJS, Percy)
• Load testing (k6, Apache JBench)
• Security scanning (OWASP ZAP)
• Accessibility testing (pa11y)
• SEO validation
• Automated changelogs

Master WordPress DevOps

Want to build enterprise-grade WordPress automation?

Join WPCLI Mastery and learn:

• Complete CI/CD pipeline templates
• Multi-environment WordPress architecture
• Blue-green deployments
• Automated rollbacks and disaster recovery
• Early bird course pricing ($99 vs $199)

Conclusion

Automated CI/CD pipelines eliminate deployment fear and enable rapid, confident WordPress development. The GitHub Actions workflow you built today provides:

• Automated testing on every push
• Safe staging deployments
• Controlled production releases
• Instant rollback capability
• Complete audit trail

Key takeaways:

• CI/CD catches errors before production
• GitHub Actions integrates seamlessly with WordPress
• WP-CLI makes WordPress automation possible
• Staging → Production workflow ensures safety
• Automated rollbacks prevent disasters
• Database migrations need careful handling

The CI/CD pipeline you implemented today is the foundation of professional WordPress DevOps. Deploy with confidence.

Ready to implement? Start with the complete workflow and adapt to your needs.

Questions about WordPress CI/CD? Drop a comment below!

Found this helpful? Share with WordPress developers building automation.

Next: Explore advanced WordPress deployment strategies and zero-downtime techniques.

The post WordPress CI/CD Pipeline with GitHub Actions and WP-CLI appeared first on WP-CLI Mastery.

Docker + WP-CLI creates isolated, reproducible WordPress environments in minutes. Spin up fresh WordPress installs with one command, test on multiple PHP versions simultaneously, and share identical environments with your entire team.

In this guide, you’ll learn to build production-ready WordPress development environments using Docker and WP-CLI, with automated setup scripts and best practices used by modern WordPress development teams.

Why Docker for WordPress Development?

Docker containers provide isolated, consistent environments for WordPress development without polluting your local system.

Problems with Traditional Local WordPress

Version conflicts: Multiple PHP versions cause headaches and break projects.

Configuration drift: Development doesn’t match staging or production environments.

Slow setup: Installing WordPress manually on each project wastes 30-60 minutes.

Team inconsistency: Developers have different local setups causing “works on my machine” bugs.

Resource waste: Running multiple databases and servers consumes system resources.

Docker + WP-CLI Advantages

Isolated environments: Each project runs independently without conflicts.

Instant setup: Launch complete WordPress stack in under 2 minutes.

Version flexibility: Test on PHP 7.4, 8.0, 8.1 simultaneously.

Team consistency: Everyone runs identical environments via docker-compose.yml.

Easy cleanup: Delete containers without leaving system residue.

According to Docker adoption surveys, 65% of professional WordPress developers use Docker for local development.

Docker WordPress Setup

Create a complete WordPress development environment with Docker Compose.

Basic docker-compose.yml

version: "3.8"

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./wordpress:/var/www/html
    depends_on:
      - db

  db:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
      MYSQL_ROOT_PASSWORD: rootpassword
    volumes:
      - db_data:/var/lib/mysql

  wpcli:
    image: wordpress:cli
    user: "33:33"
    volumes:
      - ./wordpress:/var/www/html
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    depends_on:
      - db
      - wordpress

volumes:
  db_data:

Launch Environment

# Start all services
docker-compose up -d

# Check status
docker-compose ps

# Access WordPress
open http://localhost:8080

# View logs
docker-compose logs -f wordpress

Run WP-CLI in Container

# Execute WP-CLI commands
docker-compose run --rm wpcli wp --info

# Install WordPress core
docker-compose run --rm wpcli wp core install \
    --url=localhost:8080 \
    --title="Docker WordPress" \
    --admin_user=admin \
    --admin_password=admin \
    --admin_email=admin@example.com

# Install plugins
docker-compose run --rm wpcli wp plugin install contact-form-7 --activate

Learn more about Docker Compose configuration.

Advanced Docker Configuration

Enhance your Docker WordPress environment with professional features.

Multiple PHP Versions

# docker-compose.yml with PHP version control
version: "3.8"

services:
  wordpress-php74:
    image: wordpress:php7.4-apache
    ports:
      - "8074:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wp_php74
    volumes:
      - ./wp-php74:/var/www/html

  wordpress-php80:
    image: wordpress:php8.0-apache
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wp_php80
    volumes:
      - ./wp-php80:/var/www/html

  wordpress-php81:
    image: wordpress:php8.1-apache
    ports:
      - "8081:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wp_php81
    volumes:
      - ./wp-php81:/var/www/html

Use Case: Test plugin compatibility across PHP versions simultaneously.

Custom PHP Configuration

# docker-compose.yml with custom PHP settings
services:
  wordpress:
    image: wordpress:latest
    volumes:
      - ./wordpress:/var/www/html
      - ./php.ini:/usr/local/etc/php/conf.d/custom.ini

php.ini:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300
display_errors = On
error_reporting = E_ALL

Add PHPMyAdmin

services:
  phpmyadmin:
    image: phpmyadmin:latest
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db
      PMA_USER: wordpress
      PMA_PASSWORD: wordpress
    depends_on:
      - db

Access PHPMyAdmin at http://localhost:8081.

Automated WordPress Setup

Create scripts for one-command WordPress environment initialization.

Complete Setup Script

#!/bin/bash
# wp-docker-init.sh - Initialize WordPress Docker environment

set -e

PROJECT_NAME="${1:-wordpress-project}"
ADMIN_USER="admin"
ADMIN_PASS="admin"
ADMIN_EMAIL="admin@example.com"

echo "Initializing WordPress Docker environment: $PROJECT_NAME"

# Create project directory
mkdir -p "$PROJECT_NAME"
cd "$PROJECT_NAME"

# Create docker-compose.yml
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./wordpress:/var/www/html
    depends_on:
      - db

  db:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
      MYSQL_ROOT_PASSWORD: rootpassword
    volumes:
      - db_data:/var/lib/mysql

  wpcli:
    image: wordpress:cli
    user: "33:33"
    volumes:
      - ./wordpress:/var/www/html
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    depends_on:
      - db
      - wordpress

volumes:
  db_data:
EOF

# Start containers
echo "Starting Docker containers..."
docker-compose up -d

# Wait for WordPress to be ready
echo "Waiting for WordPress..."
sleep 10

# Install WordPress
echo "Installing WordPress..."
docker-compose run --rm wpcli wp core install \
    --url=localhost:8080 \
    --title="$PROJECT_NAME" \
    --admin_user="$ADMIN_USER" \
    --admin_password="$ADMIN_PASS" \
    --admin_email="$ADMIN_EMAIL"

# Install essential plugins
echo "Installing plugins..."
docker-compose run --rm wpcli wp plugin install \
    contact-form-7 \
    yoast-seo \
    wordfence \
    --activate

# Install theme
echo "Installing theme..."
docker-compose run --rm wpcli wp theme install astra --activate

# Set permalinks
docker-compose run --rm wpcli wp rewrite structure '/%postname%/'

echo "✓ WordPress environment ready!"
echo "URL: http://localhost:8080"
echo "Admin: $ADMIN_USER / $ADMIN_PASS"

Run it:

chmod +x wp-docker-init.sh
./wp-docker-init.sh my-project

Development Helper Scripts

# wp.sh - WP-CLI wrapper for Docker
#!/bin/bash
docker-compose run --rm wpcli wp "$@"

# Usage:
chmod +x wp.sh
./wp.sh plugin list
./wp.sh post create --post_title="Test" --post_status=publish

Docker WordPress Workflows

Professional development patterns with Docker and WP-CLI.

Import Existing Site

#!/bin/bash
# import-to-docker.sh - Import existing WordPress site

BACKUP_SQL="$1"
BACKUP_FILES="$2"

if [ -z "$BACKUP_SQL" ]; then
    echo "Usage: $0 <backup.sql> <files.tar.gz>"
    exit 1
fi

# Start containers
docker-compose up -d
sleep 10

# Import database
echo "Importing database..."
docker-compose exec -T db mysql -uwordpress -pwordpress wordpress < "$BACKUP_SQL"

# Extract files
echo "Extracting files..."
tar -xzf "$BACKUP_FILES" -C ./wordpress/

# Update URLs
echo "Updating URLs..."
docker-compose run --rm wpcli wp search-replace \
    'https://oldsite.com' 'http://localhost:8080' \
    --skip-columns=guid

# Flush cache
docker-compose run --rm wpcli wp cache flush

echo "✓ Site imported successfully"

Export for Production

#!/bin/bash
# export-from-docker.sh

DATE=$(date +%Y%m%d)

echo "Exporting WordPress from Docker..."

# Export database
docker-compose run --rm wpcli wp db export - > "backup-$DATE.sql"

# Compress database
gzip "backup-$DATE.sql"

# Archive files
tar -czf "files-$DATE.tar.gz" -C ./wordpress .

echo "✓ Export complete:"
echo "  Database: backup-$DATE.sql.gz"
echo "  Files: files-$DATE.tar.gz"

Reset Development Environment

#!/bin/bash
# reset-docker-wordpress.sh

read -p "This will destroy all data. Continue? (y/n) " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    exit 0
fi

# Stop and remove containers
docker-compose down -v

# Remove WordPress files
rm -rf ./wordpress/*

# Start fresh
docker-compose up -d
sleep 10

# Reinstall
docker-compose run --rm wpcli wp core install \
    --url=localhost:8080 \
    --title="Fresh WordPress" \
    --admin_user=admin \
    --admin_password=admin \
    --admin_email=admin@example.com

echo "✓ Environment reset complete"

Testing and Debugging

Debug WordPress issues in Docker containers.

View Container Logs

# WordPress logs
docker-compose logs -f wordpress

# Database logs
docker-compose logs -f db

# All logs
docker-compose logs -f

# Last 50 lines
docker-compose logs --tail=50 wordpress

Access Container Shell

# WordPress container bash
docker-compose exec wordpress bash

# Once inside, check PHP info
php -i

# Check Apache config
cat /etc/apache2/sites-available/000-default.conf

# View error logs
tail -f /var/log/apache2/error.log

Debug WP-CLI Issues

# Check WP-CLI version
docker-compose run --rm wpcli wp cli version

# Verify WordPress installation
docker-compose run --rm wpcli wp core is-installed

# Check database connection
docker-compose run --rm wpcli wp db check

# List environment variables
docker-compose run --rm wpcli env

Performance Optimization

Improve Docker WordPress performance for development.

Enable Object Caching

services:
  redis:
    image: redis:alpine
    ports:
      - "6379:6379"

  wordpress:
    # ... existing config
    depends_on:
      - db
      - redis

Install Redis plugin:

docker-compose run --rm wpcli wp plugin install redis-cache --activate
docker-compose run --rm wpcli wp redis enable

Optimize MySQL

services:
  db:
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password --innodb-buffer-pool-size=256M

Volume Performance

# Use cached mode for better performance on macOS
volumes:
  - ./wordpress:/var/www/html:cached

Learn about Docker volume performance optimization.

Next Steps

You now have professional Docker-based WordPress development skills with WP-CLI integration.

Recommended Learning Path

Week 1: Basic Docker setup

• Launch WordPress with Docker Compose
• Run WP-CLI in containers
• Import/export sites

Week 2: Advanced configuration

• Test multiple PHP versions
• Add development tools
• Optimize performance

Week 3: Automation

• Build setup scripts
• Create helper commands
• Implement CI/CD

Week 4: Team workflows

• Share configurations
• Document processes
• Standardize environments

Advanced Topics

1. Docker Multi-Stage Builds – Optimized production images
2. Kubernetes WordPress – Container orchestration
3. CI/CD Pipelines – Automated deployment

Get More Resources

Download Docker WordPress configs including:

• Complete docker-compose files
• Setup automation scripts
• Development tools

Join our email course for:

• Weekly WP-CLI tutorials
• Docker best practices
• Modern WordPress DevOps

Conclusion

Docker and WP-CLI together create the ultimate WordPress development environment—fast, consistent, isolated, and completely reproducible across your entire team.

What we covered:

✅ Docker Compose WordPress configuration
✅ WP-CLI integration in containers
✅ Advanced Docker features (multiple PHP versions, tools)
✅ Automated setup and teardown scripts
✅ Import/export workflows
✅ Testing, debugging, and optimization

Master these techniques, and you’ll never waste time on local WordPress setup again—spin up fresh environments in seconds, test across PHP versions, and share identical setups with your team.

Ready for more? Learn WordPress CI/CD pipelines or Kubernetes deployment.

Questions about Docker WordPress with WP-CLI? Drop a comment below!

Found this helpful? Share with other WordPress developers.

The post WordPress Development with Docker and WP-CLI: Complete Setup Guide appeared first on WP-CLI Mastery.

Understanding WordPress Environment Architecture

A robust WordPress workflow typically includes three distinct environments: development for building new features, staging for testing changes in production-like conditions, and production where live users interact with your site.

Each environment serves a specific purpose. Development allows rapid iteration without affecting users, staging validates changes before release, and production serves actual traffic. Proper environment management ensures code flows smoothly through this pipeline while maintaining data integrity and security.

Setting Up Environment-Specific Configurations

WordPress 5.5 introduced native environment type support through the WP_ENVIRONMENT_TYPE constant. WP-CLI leverages this for environment-aware operations.

# Set environment type in wp-config.php
wp config set WP_ENVIRONMENT_TYPE 'development' --raw

# Verify current environment
wp config get WP_ENVIRONMENT_TYPE

# Different values: local, development, staging, production

Create environment-specific configuration files:

# wp-config-local.php for development
cat > wp-config-local.php << 'EOF'
<?php
// Development settings
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

// Disable caching in development
define('WP_CACHE', false);

// Development database
define('DB_NAME', 'wp_dev');
define('DB_USER', 'dev_user');
define('DB_PASSWORD', 'dev_password');
define('DB_HOST', 'localhost');
EOF

# wp-config-staging.php
cat > wp-config-staging.php << 'EOF'
<?php
// Staging settings
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// Prevent search engine indexing
define('DISCOURAGE_SEARCH', true);

// Staging database
define('DB_NAME', 'wp_staging');
define('DB_USER', 'staging_user');
define('DB_PASSWORD', 'staging_password');
define('DB_HOST', 'localhost');
EOF

# wp-config-production.php
cat > wp-config-production.php << 'EOF'
<?php
// Production settings
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

// Security enhancements
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', false);
define('FORCE_SSL_ADMIN', true);

// Production database
define('DB_NAME', 'wp_production');
define('DB_USER', 'prod_user');
define('DB_PASSWORD', 'secure_production_password');
define('DB_HOST', 'production-db.example.com');
EOF

Database Synchronization Strategies

Syncing databases between environments requires careful handling of environment-specific data like URLs, file paths, and credentials.

#!/bin/bash
# sync-db-staging-to-dev.sh - Sync staging database to development

set -euo pipefail

STAGING_PATH="/var/www/staging"
DEV_PATH="/var/www/development"
BACKUP_DIR="/backups"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)

echo "Starting database sync from staging to development"

# Backup development database before sync
echo "Backing up development database..."
wp --path="$DEV_PATH" db export "$BACKUP_DIR/dev-pre-sync-$TIMESTAMP.sql"

# Export staging database
echo "Exporting staging database..."
wp --path="$STAGING_PATH" db export "$BACKUP_DIR/staging-export-$TIMESTAMP.sql"

# Get staging URL
STAGING_URL=$(wp --path="$STAGING_PATH" option get siteurl)

# Get development URL
DEV_URL=$(wp --path="$DEV_PATH" option get siteurl)

# Import to development
echo "Importing to development..."
wp --path="$DEV_PATH" db import "$BACKUP_DIR/staging-export-$TIMESTAMP.sql"

# Update URLs
echo "Updating URLs from $STAGING_URL to $DEV_URL"
wp --path="$DEV_PATH" search-replace "$STAGING_URL" "$DEV_URL" --all-tables

# Update file paths if different
STAGING_PATH_ABS=$(wp --path="$STAGING_PATH" eval 'echo ABSPATH;')
DEV_PATH_ABS=$(wp --path="$DEV_PATH" eval 'echo ABSPATH;')

if [ "$STAGING_PATH_ABS" != "$DEV_PATH_ABS" ]; then
    echo "Updating file paths..."
    wp --path="$DEV_PATH" search-replace "$STAGING_PATH_ABS" "$DEV_PATH_ABS" --all-tables
fi

# Flush cache
wp --path="$DEV_PATH" cache flush

# Update permalinks
wp --path="$DEV_PATH" rewrite flush

echo "Database sync completed successfully"

Selective Data Synchronization

Production databases often contain sensitive user data that shouldn’t be copied to development environments. Implement selective synchronization:

#!/bin/bash
# sync-selective.sh - Sync database with data sanitization

WP_PATH="/var/www/development"
TEMP_SQL="/tmp/staging-sanitized.sql"

# Export from staging (on staging server)
ssh staging@staging.example.com "wp --path=/var/www/html db export - " > "$TEMP_SQL"

# Import to development
wp --path="$WP_PATH" db import "$TEMP_SQL"

# Sanitize sensitive data in development
echo "Sanitizing user data..."

# Anonymize user emails (except admin)
wp --path="$WP_PATH" db query "
UPDATE wp_users
SET user_email = CONCAT('user', ID, '@example.local')
WHERE ID != 1
"

# Clear user passwords
wp --path="$WP_PATH" db query "
UPDATE wp_users
SET user_pass = MD5(CONCAT('dev_password_', ID))
"

# Remove personal data from comments
wp --path="$WP_PATH" db query "
UPDATE wp_comments
SET comment_author_email = CONCAT('commenter', comment_ID, '@example.local'),
    comment_author_IP = '127.0.0.1'
"

# Clear transients and cached data
wp --path="$WP_PATH" transient delete --all

# Update site URLs
wp --path="$WP_PATH" search-replace 'https://staging.example.com' 'http://dev.local' --all-tables

echo "Selective sync completed with data sanitization"
rm "$TEMP_SQL"

File Synchronization

Sync uploads and plugin/theme files between environments while excluding unnecessary files.

#!/bin/bash
# sync-files.sh - Sync WordPress files between environments

SOURCE_PATH="/var/www/staging"
DEST_PATH="/var/www/development"

# Sync uploads directory
echo "Syncing uploads..."
rsync -avz --delete \
    --exclude='cache/' \
    --exclude='backup/' \
    "$SOURCE_PATH/wp-content/uploads/" \
    "$DEST_PATH/wp-content/uploads/"

# Sync plugins (optional - usually managed by version control)
echo "Syncing plugins..."
rsync -avz --delete \
    --exclude='*/cache' \
    --exclude='*.log' \
    "$SOURCE_PATH/wp-content/plugins/" \
    "$DEST_PATH/wp-content/plugins/"

# Sync themes
echo "Syncing themes..."
rsync -avz --delete \
    "$SOURCE_PATH/wp-content/themes/" \
    "$DEST_PATH/wp-content/themes/"

# Set correct permissions
chown -R www-data:www-data "$DEST_PATH/wp-content"
find "$DEST_PATH/wp-content" -type d -exec chmod 755 {} \;
find "$DEST_PATH/wp-content" -type f -exec chmod 644 {} \;

echo "File sync completed"

Environment-Aware Deployment Scripts

Create intelligent deployment scripts that adapt based on target environment.

#!/bin/bash
# deploy.sh - Environment-aware deployment script

set -euo pipefail

# Configuration
ENVIRONMENTS=("development" "staging" "production")
TARGET_ENV="$1"

if [[ ! " ${ENVIRONMENTS[@]} " =~ " ${TARGET_ENV} " ]]; then
    echo "Error: Invalid environment. Use: development, staging, or production"
    exit 1
fi

# Load environment-specific configuration
case $TARGET_ENV in
    development)
        WP_PATH="/var/www/development"
        BACKUP_RETENTION=7
        UPDATE_CORE=true
        UPDATE_PLUGINS=true
        ;;
    staging)
        WP_PATH="/var/www/staging"
        BACKUP_RETENTION=14
        UPDATE_CORE=true
        UPDATE_PLUGINS=true
        ;;
    production)
        WP_PATH="/var/www/html"
        BACKUP_RETENTION=30
        UPDATE_CORE=false  # Manual approval required
        UPDATE_PLUGINS=false
        ;;
esac

echo "Deploying to: $TARGET_ENV"

# Pre-deployment checks
echo "Running pre-deployment checks..."

# Verify WordPress is installed
if ! wp --path="$WP_PATH" core is-installed; then
    echo "Error: WordPress not properly installed at $WP_PATH"
    exit 1
fi

# Check database connection
if ! wp --path="$WP_PATH" db check; then
    echo "Error: Database connection failed"
    exit 1
fi

# Create backup
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR="/backups/$TARGET_ENV"
mkdir -p "$BACKUP_DIR"

echo "Creating backup..."
wp --path="$WP_PATH" db export "$BACKUP_DIR/pre-deploy-$TIMESTAMP.sql"

# Clean old backups
find "$BACKUP_DIR" -name "pre-deploy-*.sql" -mtime +$BACKUP_RETENTION -delete

# Maintenance mode
if [[ "$TARGET_ENV" == "production" ]]; then
    echo "Enabling maintenance mode..."
    wp --path="$WP_PATH" maintenance-mode activate
fi

# Deploy code (assuming Git deployment)
echo "Pulling latest code..."
cd "$WP_PATH"
git pull origin "$(git rev-parse --abbrev-ref HEAD)"

# Install/update dependencies
if [ -f "composer.json" ]; then
    composer install --no-dev --optimize-autoloader
fi

# Run database migrations if needed
if wp --path="$WP_PATH" plugin is-installed wp-migrate-db; then
    wp --path="$WP_PATH" migratedb migrate
fi

# Update plugins and core if allowed
if [[ "$UPDATE_PLUGINS" == true ]]; then
    echo "Updating plugins..."
    wp --path="$WP_PATH" plugin update --all --exclude=custom-plugin
fi

if [[ "$UPDATE_CORE" == true ]]; then
    echo "Updating WordPress core..."
    wp --path="$WP_PATH" core update --minor
fi

# Clear caches
echo "Clearing caches..."
wp --path="$WP_PATH" cache flush
wp --path="$WP_PATH" transient delete --expired

if wp --path="$WP_PATH" plugin is-installed wp-super-cache --status=active; then
    wp --path="$WP_PATH" cache flush
fi

# Regenerate assets if needed
if [ -f "package.json" ]; then
    npm run build
fi

# Update permalinks
wp --path="$WP_PATH" rewrite flush

# Deactivate maintenance mode
if [[ "$TARGET_ENV" == "production" ]]; then
    echo "Disabling maintenance mode..."
    wp --path="$WP_PATH" maintenance-mode deactivate
fi

# Post-deployment verification
echo "Running post-deployment verification..."

# Check site is accessible
SITE_URL=$(wp --path="$WP_PATH" option get siteurl)
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL")

if [ "$HTTP_CODE" != "200" ]; then
    echo "Warning: Site returned HTTP $HTTP_CODE"

    if [[ "$TARGET_ENV" == "production" ]]; then
        echo "Rolling back..."
        wp --path="$WP_PATH" db import "$BACKUP_DIR/pre-deploy-$TIMESTAMP.sql"
        exit 1
    fi
fi

# Verify core integrity
if ! wp --path="$WP_PATH" core verify-checksums; then
    echo "Warning: Core checksum verification failed"
fi

echo "Deployment to $TARGET_ENV completed successfully"

# Send notification (production only)
if [[ "$TARGET_ENV" == "production" ]]; then
    echo "Deployment completed at $(date)" | mail -s "Production Deployment Success" admin@example.com
fi

Configuration Management

Manage environment-specific settings without hardcoding sensitive values.

#!/bin/bash
# config-manager.sh - Environment configuration management

WP_PATH="/var/www/html"
ENV_FILE=".env"

# Load environment variables from .env file
if [ -f "$ENV_FILE" ]; then
    export $(cat "$ENV_FILE" | grep -v '^#' | xargs)
fi

# Set configuration based on environment
set_config() {
    local key="$1"
    local value="$2"
    local type="${3:-constant}"

    if [[ "$type" == "constant" ]]; then
        wp --path="$WP_PATH" config set "$key" "$value" --raw
    else
        wp --path="$WP_PATH" option update "$key" "$value"
    fi
}

# Get current environment
CURRENT_ENV=$(wp --path="$WP_PATH" config get WP_ENVIRONMENT_TYPE 2>/dev/null || echo "production")

echo "Configuring for environment: $CURRENT_ENV"

# Apply environment-specific settings
case $CURRENT_ENV in
    development|local)
        set_config WP_DEBUG true constant
        set_config WP_DEBUG_LOG true constant
        set_config WP_DEBUG_DISPLAY true constant
        set_config SCRIPT_DEBUG true constant
        set_config SAVEQUERIES true constant

        # Development plugins
        wp --path="$WP_PATH" plugin activate query-monitor
        wp --path="$WP_PATH" plugin activate debug-bar
        ;;

    staging)
        set_config WP_DEBUG true constant
        set_config WP_DEBUG_LOG true constant
        set_config WP_DEBUG_DISPLAY false constant
        set_config SCRIPT_DEBUG false constant

        # Disable search indexing
        set_config blog_public 0 option

        # Staging-specific plugins
        wp --path="$WP_PATH" plugin deactivate google-analytics
        ;;

    production)
        set_config WP_DEBUG false constant
        set_config WP_DEBUG_LOG false constant
        set_config WP_DEBUG_DISPLAY false constant
        set_config SCRIPT_DEBUG false constant

        # Security settings
        set_config DISALLOW_FILE_EDIT true constant
        set_config FORCE_SSL_ADMIN true constant

        # Enable search indexing
        set_config blog_public 1 option

        # Deactivate development plugins
        wp --path="$WP_PATH" plugin deactivate query-monitor --quiet 2>/dev/null || true
        wp --path="$WP_PATH" plugin deactivate debug-bar --quiet 2>/dev/null || true
        ;;
esac

echo "Configuration applied for $CURRENT_ENV environment"

Automated Environment Testing

Verify environment configuration and functionality before accepting deployments.

#!/bin/bash
# test-environment.sh - Automated environment testing

WP_PATH="/var/www/staging"

echo "=== Environment Testing ==="

# Test WordPress installation
echo "Testing WordPress installation..."
if wp --path="$WP_PATH" core is-installed; then
    echo "✓ WordPress is installed"
else
    echo "✗ WordPress installation check failed"
    exit 1
fi

# Test database connection
echo "Testing database connection..."
if wp --path="$WP_PATH" db check; then
    echo "✓ Database connection successful"
else
    echo "✗ Database connection failed"
    exit 1
fi

# Verify core files
echo "Verifying core files..."
if wp --path="$WP_PATH" core verify-checksums; then
    echo "✓ Core files verified"
else
    echo "⚠ Core checksum verification failed"
fi

# Check for required plugins
REQUIRED_PLUGINS=("wordpress-seo" "wordfence")
echo "Checking required plugins..."
for plugin in "${REQUIRED_PLUGINS[@]}"; do
    if wp --path="$WP_PATH" plugin is-installed "$plugin"; then
        STATUS=$(wp --path="$WP_PATH" plugin status "$plugin" 2>&1 | grep -o "Active" || echo "Inactive")
        echo "✓ $plugin: $STATUS"
    else
        echo "✗ $plugin: Not installed"
    fi
done

# Test URL accessibility
echo "Testing site accessibility..."
SITE_URL=$(wp --path="$WP_PATH" option get siteurl)
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL")

if [ "$HTTP_CODE" == "200" ]; then
    echo "✓ Site accessible (HTTP $HTTP_CODE)"
else
    echo "✗ Site returned HTTP $HTTP_CODE"
    exit 1
fi

# Check permalink structure
echo "Testing permalinks..."
wp --path="$WP_PATH" rewrite flush
if wp --path="$WP_PATH" rewrite list > /dev/null 2>&1; then
    echo "✓ Permalinks configured"
else
    echo "✗ Permalink configuration issue"
fi

# Performance checks
echo "Running performance checks..."
DB_SIZE=$(wp --path="$WP_PATH" db size --human-readable --format=json | jq -r '.Size')
echo "Database size: $DB_SIZE"

AUTOLOAD=$(wp --path="$WP_PATH" db query "SELECT CONCAT(ROUND(SUM(LENGTH(option_value))/1024/1024,2),'MB') as size FROM wp_options WHERE autoload='yes'" --skip-column-names)
echo "Autoload size: $AUTOLOAD"

echo "=== Environment Testing Complete ==="

Related Links

• WP-CLI Environment Commands
• WordPress Development Best Practices
• Version Control for WordPress
• Database Management with WP-CLI
• Continuous Deployment Strategies

The post Multi-Environment WordPress Management with WP-CLI (Dev/Staging/Prod) appeared first on WP-CLI Mastery.