Skip to main content

Feature Release Process (Conception → Production)

This is the standard workflow for releasing new functionality using AttuneLogic’s Feature Flags + Tiers system.

It is designed to be:

  • Safe (defaults off, tenant isolation, kill-switches)
  • Backwards compatible (existing tenants don’t break)
  • Operationally controllable (superAdmins can roll out and roll back without redeploys)

Roles & responsibilities​

  • Engineering
    • implements the feature behind a feature flag
    • enforces gating server-side (API)
    • adds tests
    • promotes lifecycle from dev → beta → ga
  • SuperAdmin (Ops/Support/Leadership)
    • manages tier defaults
    • turns on/off for specific tenants
    • runs pilot programs and staged rollouts

Key mechanisms (what you can control)​

1) Lifecycle (in the code registry)​

  • dev: internal-only, never tenant-visible
  • beta: previewable, tenant-visible only if allowed
  • ga: generally available

2) Tier defaults (global)​

Defines what is enabled by default for tier1/tier2/tier3.

Managed via superAdmin UI (Tier Defaults tab) and stored in system config.

3) Tenant overrides (per tenant)​

Force on/off for a specific tenant regardless of their tier.

Managed via superAdmin UI (Tenant Flags tab).

4) Beta access (latest channel + allowlist)​

For beta lifecycle flags in production:

  • tenant must have releaseChannel = latest
  • and feature key must be in betaAllowlist

This allows you to run pilots without exposing beta features broadly.

Step-by-step release workflow​

Phase 0: Conception & design​

Define:

  • Feature scope (what is included/excluded)
  • Backward compatibility strategy (what happens if disabled)
  • Security considerations (authorization, data visibility, tenant isolation)
  • Migration needs (schema/indexes; prefer additive migrations)
  • Telemetry (how you’ll detect problems: logs, metrics, Sentry context)

Output:

  • a short spec + acceptance criteria
  • the feature key name and lifecycle plan (dev/beta/ga)

Phase 1: Implement behind a flag (DEV lifecycle)​

  1. Add a new feature key to the registry.
  2. Mark it dev, defaultEnabled: false.
  3. Implement the new code path behind the flag.

Rules:

  • API must enforce the flag (don’t rely only on the UI).
  • When disabled, either:
    • use the existing behavior (preferred), or
    • return a clear error for brand new endpoints

Deliverable:

  • Code merged and deployed safely, with the feature still dark to tenants.

Phase 2: Promote to BETA (pilot ready)​

When the feature is ready for real users:

  1. Change lifecycle from dev → beta in the registry.
  2. Keep defaultEnabled: false (recommended).
  3. Identify pilot tenants.

Pilot enablement (superAdmin):

  • For each pilot tenant:
    • set releaseChannel = latest
    • add feature key to betaAllowlist
    • optionally set a tenant override to force on (useful if tier defaults remain off)

Rollback plan:

  • remove from allowlist (beta off instantly)
  • or set tenant override to force off

Phase 3: Tier packaging (pre-GA)​

Once you’re confident:

  • Decide which tiers should get the feature by default.
  • Update Tier Defaults (global) for tier1/tier2/tier3.

Notes:

  • For beta features in prod, tier defaults alone is not enough: tenants still need latest + allowlist.
  • Many teams switch lifecycle to ga before enabling widely by tier.

Phase 4: GA release (general availability)​

  1. Promote lifecycle beta → ga.
  2. Enable it by default via Tier Defaults for the intended tiers.
  3. Keep tenant overrides available for:
    • break-fix rollbacks
    • tenant-specific issues

Communicate:

  • release notes
  • “what changed” and “how to use it”

Phase 5: Cleanup / migration completion​

After GA stabilizes:

  • remove or deprecate old code paths (carefully)
  • consider migrating old data if needed
  • document the “final” behavior

When removing a flag:

  • remove usage points first (so it’s no longer referenced)
  • then remove the registry entry later (optional)

Practical templates​

Choosing a feature key​

  • Use domain prefixes: dispatch.*, jobs.*, reports.*, mobile.*
  • Use version suffixes for replacements: dispatch.v2Board, jobs.smartSchedulingV2
  • New features start as:
    • lifecycle: dev
    • defaultEnabled: false

What “done” means before GA​

  • Pilot tenants used it in production successfully
  • No cross-tenant data leakage risks
  • Backwards compatible behavior verified
  • Support can toggle it on/off confidently