Skip to content

Release Checklist (Production WooCommerce)

Use this checklist before each production release of the plugin.

1) Planning and scope

  • [ ] Confirm release scope (features, fixes, breaking changes).
  • [ ] Confirm target plugin version and update hft71-plugin.php + CHANGELOG.md.
  • [ ] Identify required WooCommerce/WordPress/PHP minimum versions.
  • [ ] Define rollout window and owner(s) for deployment and monitoring.

2) Code and quality gates

  • [ ] All intended changes merged and reviewed.
  • [ ] No debug code, temporary credentials, or hardcoded secrets in repository.
  • [ ] PHP syntax checks pass for changed files.
  • [ ] Manual sanity test completed in local/staging environment.

3) Staging environment validation

  • [ ] Staging stack matches production as closely as possible (WP, WooCommerce, PHP, theme/plugins).
  • [ ] Plugin activation works without fatal errors.
  • [ ] Admin pages load:
  • [ ] HFT71 > Ustawienia
  • [ ] HFT71 > Logi
  • [ ] HFT71 > Modele
  • [ ] HFT71 > Kolory
  • [ ] API settings save correctly (api_base_url, username, password).
  • [ ] Token retrieval works with valid credentials.

4) Functional test matrix (staging)

  • [ ] Order export: order reaching processing triggers POST /order.
  • [ ] External ID persistence: _hft71_order_id is saved on successful send.
  • [ ] Status polling: scheduled sync updates WooCommerce order status per mapping.
  • [ ] Webhook update: POST /wp-json/hft71/v1/order-status updates order status.
  • [ ] Webhook secret (if enabled): invalid secret rejected, valid secret accepted.
  • [ ] Stock sync: products with matching SKU receive updated stock quantity/status.
  • [ ] Manual stock sync button executes and logs result.
  • [ ] Bidirectional sync (if enabled): status/address changes trigger PUT /order/{orderId}.
  • [ ] Logging: expected entries appear in HFT71 > Logi.
  • [ ] Model config: seeder ran on fresh install; models/colors/SKUs visible in HFT71 > Modele and match expected catalog.
  • [ ] Model read API: hft71_get_model() returns expected SKU map for a sample model code.

5) WooCommerce production readiness checks

  • [ ] Store has recent full backup (files + database) and restore procedure verified.
  • [ ] WP-Cron is operating reliably in production (or real cron triggers wp-cron.php).
  • [ ] HTTPS is enabled and valid for webhook endpoint URL.
  • [ ] Product SKUs are present and normalized for stock sync expectations.
  • [ ] Order statuses used by store are confirmed in mapping table.
  • [ ] Third-party plugins affecting checkout/orders are checked for conflicts.

6) Security and compliance checks

  • [ ] Production API credentials are stored only in site settings/secret manager.
  • [ ] Webhook secret is set for production (recommended).
  • [ ] Principle of least privilege applied to admin accounts performing deployment.
  • [ ] No sensitive data is copied from logs into public channels.

7) Deployment execution

  • [ ] Put store in maintenance mode only if required by your release policy.
  • [ ] Deploy plugin package to production.
  • [ ] Confirm plugin is active and version is correct.
  • [ ] Re-save plugin settings if migration/option refresh is needed.
  • [ ] Confirm database tables exist:
  • <wp_prefix>hft71_api_log
  • <wp_prefix>hft71_stock_cache
  • <wp_prefix>hft71_models, <wp_prefix>hft71_colors, <wp_prefix>hft71_model_colors, <wp_prefix>hft71_model_skus

8) Smoke tests in production

  • [ ] Place controlled test order and move to processing.
  • [ ] Verify order sent to HFT71 and external ID stored.
  • [ ] Trigger webhook test payload from trusted source.
  • [ ] Run manual stock sync and verify at least one known SKU update.
  • [ ] Confirm logs are being written for each tested flow.

9) Monitoring (first 24 hours)

  • [ ] Watch WooCommerce order processing for stuck/error states.
  • [ ] Watch plugin logs for repeated API failures (401/403/5xx/timeouts).
  • [ ] Verify stock synchronization cadence and expected product updates.
  • [ ] Track support incidents tied to checkout, order statuses, or fulfillment handoff.

10) Rollback plan (must be ready before deploy)

  • [ ] Document rollback owner and decision threshold.
  • [ ] Keep previous plugin build artifact available.
  • [ ] Verify steps to revert plugin files/version quickly.
  • [ ] Verify restore plan for settings/db from backup if needed.
  • [ ] Record incident notes and root cause if rollback is executed.

11) Release sign-off

  • [ ] Technical sign-off (developer/maintainer).
  • [ ] Operations sign-off (deployment owner).
  • [ ] Business/support sign-off (if customer-facing impact).
  • [ ] Release notes shared with stakeholders.