Deploy
Planned: safe fix deployment with canary releases and A/B testing.
Built and running, but never exercised — and there is no dashboard control
Fix deployment is wired end to end, and the worker-deployment service
runs in production. What has never happened is anyone using it: the
deployments table has never held a row, so no fix has ever actually been
deployed, and none of the behaviour below has been observed on real traffic.
The path that exists today is API-only:
| Step | Status |
|---|---|
POST /api/v1/fixes/{fix_id}/promote | Real. Creates a deployments row (canary) and moves the fix out of draft. |
GET / POST / DELETE /api/v1/deployments | Real. Full CRUD. |
| Deployment worker (activate → ramp → graduate / roll back) | Real, and running in production. |
GET /api/v1/fixes/active | Real. Serves promoted fixes to the SDK fix runtime. |
| A button in the dashboard to promote a fix | Does not exist. Promotion is API-only. |
So treat this page as untested software, not a design document. The mechanism is there and will run if you call it; the specific numbers — rollback latency, ramp timings, safety thresholds — are design targets that have never been measured against a running deployment. Do not plan against the numbers, and do not deploy a fix to production traffic without watching it yourself.
Risicare generates fix recommendations, and — if you promote one through the API — will deploy it progressively and roll it back automatically on regression. Because no fix has ever been promoted, that second half is unproven in practice. For the parts with production mileage, see Diagnose and Heal.
Overview
Canary
Initial 5% rollout
A/B Testing
Statistical validation
Rollback
Instant rollback
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
| State | Description |
|---|---|
pending | Fix created, deployment not yet started |
active | Deployment is live and serving traffic |
ramping | Traffic percentage increasing through ramp stages |
graduated | Fix reached 100% and held for 24 hours |
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 — the rollback code exists and runs, but no rollback has ever executed against real traffic, so nothing has ever been timed.
The mechanism is that a rollback updates Redis routing, with the SDK polling for changes every 60 seconds and critical rollbacks triggering immediate cache invalidation. Note the polling interval: whatever the routing update costs, a given SDK process can keep sending traffic to the old fix until its next poll.
Dashboard
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
Four endpoints manage deployments:
# List deployments
curl -X GET "https://app.risicare.ai/api/v1/deployments" \
-H "Authorization: Bearer rsk-..."
# Get deployment detail
curl -X GET "https://app.risicare.ai/api/v1/deployments/{id}" \
-H "Authorization: Bearer rsk-..."
# Create deployment
curl -X POST "https://app.risicare.ai/api/v1/deployments" \
-H "Authorization: Bearer rsk-..." \
-d '{"fix_id": "fix-xyz789"}'
# Rollback deployment
curl -X DELETE "https://app.risicare.ai/api/v1/deployments/{id}" \
-H "Authorization: Bearer rsk-..."