Skip to main content

Release Process

Authoritative reference: ADR-013 — release cadence and retention.

Per-repo flow for noxys-doc: see Operations → noxys-doc Release Flow.

Branches​

  • main — production. Protected. Tagged for every release.
  • staging — integration. All feature work merges here first.
  • feat/<short-name>, fix/<short-name>, refactor/<short-name> — feature branches.

Hard rule (per Memory: staging-first): never merge directly from a feature branch to main. Pipeline is always feat → staging → main.

Pipeline​

[ feat/foo ] ─PR─► [ staging ] ─PR─► [ main ] ─tag─► production
                       │
                       └─ E2E on staging-* env
  1. Open a PR against staging. CI runs lint + unit + integration tests.
  2. After review, merge with --squash. The squashed commit becomes the audit record.
  3. Auto-deploy to staging environment (*-staging.noxys.cloud).
  4. Manual smoke test on staging — validate the user-facing flow.
  5. PR staging → main (release PR) when staging is healthy.
  6. Merge main → tag → deploy to production.
  7. Post-release smoke test on production.

Commit conventions (Conventional Commits)​

<type>(<scope>): <description>

<optional body>

<optional footer: refs/closes>

Types: feat, fix, refactor, docs, test, chore, perf, ci, build, revert.

Scopes are repo-relative (coaching, policy, extension/mv3, console/billing).

Versioning​

  • noxys-extension — semver, published to Chrome Web Store, Edge Add-ons, Firefox AMO.
  • noxys-api — semver of the OpenAPI contract; breaking changes require a major bump and a v2 path prefix.
  • noxys-console — semver, internal — no public version commitments.
  • noxys-doc — calendar-versioned (YYYY-MM), continuous deploy.

OpenAPI specs are versioned in noxys-api/openapi/ and published to api.noxys.cloud/openapi/v<N>.json.

Hotfix process​

  1. Branch fix/<short-name> from main.
  2. Make the minimum change.
  3. PR against main directly only with explicit approval from CEO or CTO.
  4. After hotfix lands, immediately back-port to staging so the histories converge.
  5. Document the incident in the project issue tracker.

Do not abuse the hotfix path. The default flow is feat → staging → main even for urgent fixes — staging exists exactly to catch regressions before prod.

Retention​

Per ADR-013, all release artifacts (build outputs, signed extensions, container images) are retained:

  • Production artifacts: 24 months minimum
  • Staging artifacts: 90 days
  • Tagged commits: forever (git)
  • Audit logs: 24 months (RGPD article 30)

CI/CD​

  • GitHub Actions for noxys-doc, noxys-website, noxys-extension.
  • Self-hosted runners on the production VPS for noxys-api and noxys-console (closer to staging DB, faster feedback).
  • OpenAPI contract checks — every API PR runs schema-diff vs. the deployed OpenAPI spec; breaking changes fail CI.

See per-repo .github/workflows/ and the noxys-infra/ci/ shared workflows.

Release checklist​

Before merging staging → main:

  • All tests green on staging (CI)
  • Manual smoke test on *-staging.noxys.cloud
  • Changelog entry in CHANGELOG.md (if the repo has one)
  • No open BLOCKER issues against the milestone
  • Sub-processor list updated (if the release adds one)
  • Documentation update PR landed in noxys-doc (if user-facing)