Deploy
Planned: safe fix deployment with canary releases and A/B testing — built, and gated off.
Built, and gated off — nothing can be deployed today
Fix deployment is built but not connected in this release. What each piece does today:
| Step | Status |
|---|---|
| Promote a fix | Gated off. Not available with an API key during the beta, and the dashboard has no control for it. |
| Create a deployment | Gated off. Not available with an API key during the beta. |
| List or roll back a deployment | Not available with an API key during the beta. With creation gated off there is nothing new to list or roll back. |
| Deployment worker (activate → ramp → graduate / roll back) | Built. It does not run in production. |
Active fixes for the SDK fix runtime (GET /v1/fixes/active on the API host) | Not reachable with an API key during the beta. The fix runtime is off by default. |
| Dashboard | No deployment pages and no control to promote a fix. |
The rest of this section describes the design. The numbers below — rollback latency, ramp timings, safety thresholds — are design targets that have never been measured against a running deployment.
Risicare is designed to deploy a fix recommendation progressively and roll it back automatically on regression. None of that runs today. For error classification, which does, see Diagnose.
Overview
Canary
Initial 5% rollout
A/B Testing
Statistical validation
Rollback
Rolling back a deployment
Deployment Pipeline
Fix Created
|
+-------------------+
| Canary (5%) | Minimum 100 samples
| | Monitor error rate
+-------------------+
| (if passing)
+-------------------+
| Ramp (25%) | Statistical A/B test
| | O'Brien-Fleming boundaries
+-------------------+
| (if winning)
+-------------------+
| Ramp (50%) | Continue testing
| |
+-------------------+
| (if winning)
+-------------------+
| Graduate (100%) | Hold for 24 hours
| | Mark as graduated
+-------------------+
Deployment States
A deployment row holds one of these statuses:
| State | Description |
|---|---|
pending | Deployment created, not yet started |
canary | Created at its initial traffic percentage but not yet routed; the worker's next check moves it to running |
running | Live: the fix is routed to its share of traffic |
ramping | Traffic percentage increasing through ramp stages |
testing | Statistical test in progress |
completed | Rollout finished at 100% |
rolled_back | Deployment reverted due to failure or manual action |
failed | Deployment encountered an unrecoverable error |
Deployment Safety
Automatic Rollback
Fixes are automatically rolled back if:
| Condition | Threshold |
|---|---|
| Error rate increase | >10% vs baseline |
| P99 latency increase | >2x baseline |
| Manual rollback | Triggered by user |
Rollback Speed
Design target: under 500ms. This is an unmeasured target, not an observed figure — nothing has ever been timed.
As designed, an SDK process with the fix runtime on learns about a rollback only by
polling GET /v1/fixes/active on the API host, every 60 seconds by default; there is
no push path. A given SDK
process can keep applying the old fix until its next successful poll.
Dashboard (planned)
There are no deployment pages in the dashboard in this release. As designed:
Deployment List
View all deployments:
| Column | Description |
|---|---|
| Fix | Fix ID and description |
| Status | Current deployment state |
| Traffic | Current traffic percentage |
| Error Rate | Treatment vs control |
| P-value | Statistical significance |
| Started | Deployment start time |
Deployment Detail
For each deployment:
- Metrics: Error rate, latency, cost over time
- A/B Results: Control vs treatment comparison
- Events: State transitions, rollbacks
- Configuration: Fix config and targeting
Deployment API
Not available with an API key during the beta. As designed, four operations manage deployments: list, get, create, and roll back (owner or admin).