Skip to content

release-readiness-validation.md

Latest commit

 

History

History
135 lines (95 loc) · 3.15 KB

release-readiness-validation.md

File metadata and controls

135 lines (95 loc) · 3.15 KB
file_type documentation
title Release Readiness Validation Workflow
description Portable workflow for validating release readiness across governance, quality, and documentation gates.
version v0.1.0
last_updated 2026-05-28
owners
LightSpeedWP Team

Release Readiness Validation Workflow

Overview

This workflow ensures that every release meets organizational standards for governance, code quality, documentation, and security.

Workflow Stages

Stage 1: Code Quality Gates

Objective: Ensure code meets quality standards before merge.

Checks:

  • All tests pass (unit, integration, E2E)
  • Code coverage ≥ 80%
  • Linting passes (ESLint, PHPCS, Prettier)
  • Static analysis passes (TypeScript, PHPStan)
  • No security vulnerabilities detected
  • No console errors or warnings

Tools:

  • Jest for JavaScript testing
  • PHPUnit for PHP testing
  • ESLint for linting
  • SonarQube for code analysis

Actions if Failed:

  • Block merge until fixed
  • Notify development team
  • Create follow-up issue for technical debt

Stage 2: Governance Gates

Objective: Ensure compliance with organizational standards.

Checks:

  • CHANGELOG.md updated with release notes
  • Version number bumped (semver)
  • All contributors credited
  • Dependency security audit passed
  • License compliance verified
  • No breaking changes without notice

Actions if Failed:

  • Block merge until resolved
  • Request documentation updates
  • Verify semver compliance

Stage 3: Documentation Gates

Objective: Ensure adequate documentation for users and developers.

Checks:

  • README.md updated with new features
  • API documentation complete (if applicable)
  • Installation instructions current
  • Examples provided for new features
  • CONTRIBUTING.md accurate
  • Migration guide (if breaking changes)

Actions if Failed:

  • Block merge until documented
  • Create documentation issues
  • Schedule documentation review

Stage 4: Release Validation

Objective: Verify release artifacts and metadata.

Checks:

  • Correct files included in release
  • Release notes match changelog
  • Git tag properly formatted
  • GitHub release created
  • Artifact sizes reasonable
  • No sensitive data in release

Actions if Failed:

  • Prevent release publication
  • Create issue to resolve
  • Request re-tagging if needed

Approval Process

  1. Automated Checks: All quality gates pass automatically
  2. Manual Review: Team lead reviews governance and documentation
  3. Release Manager: Approves final release metadata
  4. Publication: Release published to designated channels

Release Channels

  • GitHub Releases: Primary channel
  • NPM/Packagist: Language-specific registries
  • Plugin Directory: WordPress.org (if applicable)
  • Changelog: Update in repository

Rollback Procedure

If critical issues discovered post-release:

  1. Assess severity and impact
  2. Create hotfix branch
  3. Fix issue and test thoroughly
  4. Create new release (patch version)
  5. Document issue and resolution
  6. Notify users

Continuous Monitoring

After release:

  • Monitor error reporting systems
  • Track user feedback
  • Monitor security advisories
  • Plan next iteration based on feedback