Deployment Automation

Overview

To maintain the stability and performance of our WordPress MVP, we use automated deployment pipelines. This ensures that every patch, plugin update, or theme change is vetted in a staging environment before being promoted to production.

The deployment process is primarily driven by GitHub Actions, leveraging WP-CLI and rsync/SSH for secure file transfers and remote command execution.

Environment Setup

Before triggering deployments, ensure your repository has the following GitHub Secrets configured. These are required for the automation scripts to authenticate with your hosting providers.

| Secret Name | Description | Example | | :--- | :--- | :--- | | STAGING_SSH_KEY | Private SSH key for the staging server. | -----BEGIN OPENSSH... | | STAGING_HOST | IP address or hostname of the staging server. | staging.example.com | | PROD_SSH_KEY | Private SSH key for the production server. | -----BEGIN OPENSSH... | | PROD_HOST | IP address or hostname of the production server. | wp.example.com | | SERVER_USER | The SSH username used for deployment. | deploy-user |

Deployment Workflows

1. Staging Deployment (Automated)

The staging environment acts as a sandbox for testing weekly contributions. Any push to the develop branch automatically triggers a deployment to the staging site.

• Trigger: Push to develop.
• Actions: Runs PHP Linting, installs Composer dependencies, and syncs the wp-content directory.

2. Production Deployment (Manual/Release)

To ensure zero downtime and prevent accidental breaks, production deployments are restricted to GitHub Releases or manual triggers via the Actions tab.

• Trigger: Creation of a new Release or manual workflow_dispatch.
• Safety Check: The workflow validates the build locally before initiating the transfer.

Usage Examples

Triggering a Manual Production Push

If you need to deploy a hotfix outside of the standard release cycle:

1. Navigate to the Actions tab in the GitHub repository.
2. Select the "Deploy to Production" workflow.
3. Click Run workflow, choosing the branch (usually main) you wish to deploy.

Configuration via deployment-config.json

You can customize which directories are excluded from the sync (e.g., local logs or node_modules) by modifying the internal exclusion list in the deployment script. While the script is internal, you can interface with it by adding an .ignore file in your root:

# .deployment-ignore
wp-config.php
.git/
node_modules/
/uploads/
*.log

Post-Deployment Automation

Once files are transferred, the pipeline automatically executes the following WP-CLI commands to ensure the site is ready:

# Example of commands run by the deployment runner
wp cache flush --path=/var/www/html
wp core update-db --path=/var/www/html
wp rewrite flush --path=/var/www/html

Handling Database Migrations

We recommend using a "Code-First" approach. For structural changes (e.g., new ACF fields or custom tables), include the necessary wp-cli commands in a migration script within the /bin directory. The deployment runner will detect and execute these scripts during the post-deploy phase.