Deploy & Test
Safer WordPress release workflows
A WordPress plugin that lets trusted users trigger configured GitHub Actions deploy and test workflows, follow their status, review test summaries, and inspect an audit trail without direct GitHub access or personal access tokens.
I am the sole creator of the project and took it from product definition through design, development, testing, documentation, packaging, and release.
The problem
WordPress teams may manage content and site operations inside the CMS while their deployment and automated testing workflows live in GitHub. A trusted site manager may need to run an approved action, but should not need repository access, workflow configuration permissions, or personal access tokens.
Putting a button in WordPress is only the visible part of the problem. A release-related interface must also control who can configure and operate it, validate the exact target, prevent duplicate workflows, explain current state, handle failures safely, and preserve a useful trace afterwards.
The workflow I built
An Administrator configures the permitted repositories, refs, workflow files, environments, and actions. Sensitive GitHub App values remain in server configuration rather than database-backed plugin settings.
An authorized Administrator or Editor can then run a preview, production, or test action. WordPress creates a short-lived installation token, dispatches the configured workflow, polls for status, renders test-summary artifacts, and records the operation in the audit log.
Designing around release risk
I treated failure modes as product requirements, not as implementation details to consider after the interface was complete.
Separate configuration from operation
Administrators manage connections and cleanup settings. Editors can run approved actions without changing the integration, while Subscribers cannot access the plugin.
Validate before dispatch
Repository, ref, workflow, environment, and action values are validated before they can reach the GitHub integration boundary.
Prevent competing actions
Immediate UI feedback and server-side locks block rapid duplicates and cross-action concurrency while a workflow is active.
Make outcomes traceable
Status panels connect an action to its GitHub run, while the audit log records the actor, action, status, time, and safe details.
Deploy, test, and review
The normal workflow runs a controlled deployment, starts automated tests, restores the available actions after completion, and brings the resulting test evidence back into WordPress.
A layered QA strategy
The test strategy assigns each risk to the smallest reliable layer instead of forcing every check through one slow end-to-end path.
Local WordPress
Activation, configuration, roles, audit retention, and uninstall data handling.
Mocked GitHub API
Dispatch contracts, controlled errors, timeouts, malformed responses, locks, and artifact boundaries.
PHPUnit
Permissions, nonces, validation, authentication, escaping, credential leakage, status, audit, and cleanup.
Playwright
Seven Administrator, Editor, and Subscriber journeys, including restoration and a stored-content XSS boundary.
QA sandbox
Real GitHub App authentication, workflow dispatch, polling, concurrency, and artifact downloads away from production.
The documented manual suite contains 24 critical scenarios, including successful and intentionally failing workflows, malformed configuration and artifacts, controlled API errors, duplicate submission, cross-session locking, and both cleanup and data-preservation uninstall modes.
When testing changed the product
Foundation testing found that test actions remained unavailable after completion until the user manually refreshed the page. Refreshing also returned the interface to Deploy status instead of preserving Test status.
I preserved the original behaviour in the QA report, tracked the improvement in issue #1, implemented the change through pull request #2, and added regression coverage. The fix first shipped in v1.0.3 and remains part of the current release.
Release confidence
The downloadable ZIP is tested as a release artifact. Publishing depends on the complete verification workflow rather than assuming source-level checks are enough.
- Composer dependency audit
- WordPress Coding Standards
- WordPress and PHP compatibility matrix
- WordPress Plugin Check
- Packaged ZIP installation and activation
- PHPUnit and seven Playwright journeys
An early compatibility-gate run exposed failures, the gate was corrected, and later verification and release runs completed successfully. The current release was published through this gated process.
View public workflow evidenceOutcome
Deploy & Test is a working public plugin with a downloadable release and an inspectable quality process. It gives trusted WordPress users a clearer way to operate approved GitHub Actions workflows while keeping configuration, credentials, concurrency controls, status, test evidence, and audit history within explicit boundaries.
The project reflects how I approach Quality Engineering alongside implementation: identify the highest-risk behaviours, choose the appropriate test layer, preserve evidence, turn findings into product improvements, and make release confidence repeatable.
Inspect the implementation and evidence
The repository includes the plugin, testing strategy, manual scenarios, automated suites, release workflows, and packaged releases.