Feeding Launch Readiness (Deploys & Tests)
Launch Readiness rolls up a single 0–100% score from five checks. Three of them populate themselves from data already in iKanban; two are fed by your own pipeline. This page explains how to feed them — the same way iKanban tracks its own delivery (DORA) metrics.
Use Releases to create releases and assign issues. For progress charts and scope change, see Release Analysis; that view is separate from this readiness score.
What feeds each axis
| Axis | Source | Setup needed |
|---|---|---|
| Scope | Your release's issues (done vs. total) | None — automatic |
| Quality | Bug-type issues in the release | None — automatic |
| Ops | The launch checklist (docs / feature flag / rollback) | Toggle + link evidence in the app |
| Verification | Recorded test runs | "Record test run" button, or POST from CI |
| Stability | Tracked deployments (change-failure rate) | POST from your deploy pipeline |
Scope, Quality and Ops need nothing — keep your issues and checklist up to date. Verification and Stability are the two you wire up.
Step 1 — Create an API key
Go to Settings → API Keys and create a key. Store it in your CI secret manager and send it as a bearer token. The deployment and test-run routes shown here are agent-facing routes that accept API-key authentication; this does not make every /api route available to API keys. See Setup and Access for browser-session-only operations.
Authorization: Bearer vk_your_key_here
Step 2 — Stability: report each deploy
Every time you deploy, POST a record. Start it when the deploy begins, then mark success/failure when it finishes.
Start a deploy
curl -s -X POST "https://api.i-kanban.com/api/deployments" \
-H "Authorization: Bearer $IKANBAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"app_name": "frontend",
"environment": "prod",
"commit_sha": "'"$GIT_SHA"'",
"deployed_by": "ci",
"status": "started"
}'
# → returns { "data": { "id": "<deployment-id>", ... } }
Finish it (set the outcome + duration):
curl -s -X PUT "https://api.i-kanban.com/api/deployments/<deployment-id>" \
-H "Authorization: Bearer $IKANBAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "status": "success", "duration_seconds": 92 }'
Fields: app_name (must match your project name so the release can attribute it), environment (dev / prod / …), commit_sha, optional version / deployed_by, and status (started → success | failure). Stability = the change-failure rate over these records in the release window.
GitHub Actions example
- name: Report deploy to iKanban
if: always()
run: |
STATUS=${{ job.status == 'success' && 'success' || 'failure' }}
curl -s -X POST "https://api.i-kanban.com/api/deployments" \
-H "Authorization: Bearer ${{ secrets.IKANBAN_API_KEY }}" \
-H "Content-Type: application/json" \
-d "{\"app_name\":\"frontend\",\"environment\":\"prod\",\"deployed_by\":\"github-actions\",\"commit_sha\":\"${{ github.sha }}\",\"status\":\"$STATUS\"}"
That is exactly how iKanban records its own deploys — each row you see under the Stability drill-down is one of these calls (commit · environment · status · time).
Step 3 — Verification: report test runs
Easiest — no setup: on the Verification row, click Record test run and enter passed / total. No IDs or API key needed — use this if you don't have CI wired up.
From CI (after your suite runs):
curl -s -X POST \
"https://api.i-kanban.com/api/teams/{TEAM_ID}/projects/{PROJECT_ID}/test-runs" \
-H "Authorization: Bearer $IKANBAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "total": 22, "passed": 18, "failed": 4, "suite": "e2e" }'
Fields: total, passed, failed, optional suite, and optional release_id (omit it and the run auto-attributes to the project's active release). Verification = the latest run's pass rate.
Getting
{TEAM_ID}/{PROJECT_ID}— these are UUIDs, not the slugs (e.g.IKA/frontend) shown in the browser URL. Fetch them with your API key:curl -s "https://api.i-kanban.com/api/teams" \ -H "Authorization: Bearer $IKANBAN_API_KEY"The response lists each team's
idand its projects. (Stability doesn't need this — it keys on the project name viaapp_name.)
How the score updates
Once deploys and test runs are flowing, Stability and Verification light up automatically and the composite score (and the ship gate) reflect real delivery data — no manual upkeep. Open any axis on the scorecard to drill into the underlying issues, deploys, test runs or checklist items.