Search the site
OPERATIONS
Turn a feature on for a slice of users, try a branch on its own deployment, and keep old app versions working after the backend changes.
ON THIS PAGE
Roll a feature out with typed flags
Give every branch its own deployment
Release a backend behind health gates
Keep old app versions working
dartvel flags list
dartvel flags pruneCopy code to clipboard
Declare a flag with an owner and an expiry. The build refuses one without them, and reads become typed members of Flags.
Target by percentage, platform, tenant, role, locale or app version. The same user lands in the same bucket on the web and on a phone.
context.flag(Flags.x) is a signal, so a page redraws when rules change. prune lists expired flags with the code still reading them.
Partial
Spec section: Feature Flags and Staged Rollout
Planned work and implementation limits
Rules are not published per environment yet, and Studio has no Flags section.
On the backend, a flag is not yet evaluated with the request's user and client version.
Planned
The branch lifecycle and checks are built, but no hosting adapter ships yet. Creating a preview reports that there is nowhere to host it.
dartvel deploy --preview
dartvel deploy --preview --from-pr 412
dartvel deploy --preview --list
dartvel deploy --preview --open
dartvel deploy --preview --destroy
dartvel deploy --preview --sweepCopy code to clipboard
Each branch gets its own host, database, bucket and queues. A branch copy of production data must declare how sensitive columns are cleaned, or it is refused.
Production secrets are never deployed to a branch, and a branch secret equal to production's stops the create.
Branch deployments send no real mail, skip undeclared schedules, are hidden from search engines, and are swept when the branch is gone.
Partial
Spec section: Branch deployments
Planned work and implementation limits
No hosting adapter ships yet, so create reports that there is nowhere to host a branch deployment.
--logs [--follow] reports that log retrieval is not supported yet. No captured-mail view.
Planned
Health-gate primitives are built. Automated deploy integration and hosting adapters are not yet implemented.
Every release records where it came from. A canary becomes blue-green when the host cannot split traffic.
The health gate compares errors and p95 latency with the release being replaced, and rolls back on a regression. Error budgets, crash health and client compatibility are gates too.
An override needs a reason and a person, and both are recorded with the evidence it overrode.
Partial
Spec section: Backend Release Management
Planned work and implementation limits
dartvel deploy does not run these gates yet, and there is no rollback command.
No hosting adapters for Cloud Run, Lambda, Fly.io or Kubernetes, and no source of per-release traffic numbers.
Planned
Compatibility checks accept an explicit contract. Reading it from the project, generating the protocol lock and the client handshake are not yet implemented.
dartvel compatibility-check
dartvel compatibility-check --against production --histogram sessions.jsonCopy code to clipboard
dartvel.protocol.lock records the shape of your models and functions for each version you still serve.
A change an old client cannot read needs an adapter. Without one, that version is refused, so it is never served broken.
Against an environment, the check refuses a deploy that would strand too many live sessions, unless you give a reason.
Partial
Spec section: Protocol Versioning and Client Compatibility
Planned work and implementation limits
The contract is not yet read from your project, no command writes dartvel.protocol.lock, and no build step runs the lock check.
The generated client and backend do not do the version handshake yet, so there is no upgrade prompt.
FSL-1.1-MIT licensed. Built with Dartvel.
Dartvel is made by
To the bottom