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

AxisSourceSetup needed
ScopeYour release's issues (done vs. total)None — automatic
QualityBug-type issues in the releaseNone — automatic
OpsThe launch checklist (docs / feature flag / rollback)Toggle + link evidence in the app
VerificationRecorded test runs"Record test run" button, or POST from CI
StabilityTracked 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 id and its projects. (Stability doesn't need this — it keys on the project name via app_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.