DORA-dashbord

DORA-dashbordet viser de fire målingene fra rapporten State of DevOps fra DevOps Research and Assessment (DORA), beregnet fortløpende per kunde fra utrullingshendelser som fremforge registrerer. Synlig under Organisasjonsadministrasjon → DORA.

Ingen ekstern tjeneste. Ingen data sendes til et dashbord hos en tredjeparts SaaS-leverandør. Tallene beregnes i fremforge ved siden av repositoryene, revisjonsloggen og funnene dine, og de har de samme garantiene for datalokalisering i EU og isolasjon mellom kunder som alt annet under /<slug>/_admin/*.

De fire målingene

Vinduet er som standard 30 dager glidende. Kan endres under Organisasjonsadministrasjon → DORA → Innstillinger mellom 7, 30 og 90 dager.

Hvordan utrullinger havner i tabellen

To innlesingsveier kjører side om side. Bruk den som passer måten du gir ut på; mange kunder bruker begge.

1. Forgejos release-webhook (automatisk)

Når et repository oppretter en Forgejo-utgivelse (en annotert tag v* eller et utgivelsesobjekt publisert gjennom grensesnittet eller POST /api/v1/repos/{owner}/{repo}/releases), registrerer fremforge én utrullingshendelse med:

• environment = production (standard)
• deployed_at = utgivelsens created_at
• commit_sha = utgivelsens target_commitish løst opp til en SHA
• committed_at = commitens author.date
• success = true
• external_ref = release:{release_id} (idempotent; webhooken kan trygt spilles av på nytt)

Kunden trenger ikke koble opp noe. Målet for webhooken er konfigurert på plattformnivå, og den slås automatisk på for hver organisasjon.

2. POST /_app/api/v1/dora/deployments (egendefinert, anbefales for rikere telemetri)

For kunder som ikke tagger utgivelser (kontinuerlig utrulling, GitOps med push ved merge, blue/green-bytter), går den automatiske innlesingen glipp av hver utrulling. Send én post per utrulling med POST fra CI-workflowen din:

curl -X POST https://frem.sh/_app/api/v1/dora/deployments \
  -H "Authorization: Bearer ffp_<your-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "repo_full_name": "acme/web",
    "environment": "production",
    "deployed_at": "2026-05-14T10:00:00Z",
    "commit_sha": "abc1234...",
    "committed_at": "2026-05-14T09:30:00Z",
    "success": true,
    "external_ref": "deploy-12345"
  }'

Påkrevd: repo_full_name, environment, deployed_at.

Valgfritt, men anbefalt:

• commit_sha + committed_at: uten disse faller raden helt ut av beregningen av ledetid. De tre andre målingene teller den fortsatt.
• success (standard true): sett false ved tilbakerulling eller mislykket utrulling. Driver feilraten for endringer og MTTR.
• external_ref: nøkkel for å fjerne duplikater, avgrenset per kunde. Endepunktet er idempotent på (tenant_id, repo_full_name, environment, external_ref): spill av kallet på nytt fra en CI-jobb som prøves igjen, og du får 200 med id-en til den eksisterende raden i stedet for en duplikat. Utelat den hvis du ikke vil fjerne duplikater.
• is_rework (standard false): merk dette som en hurtigrettelse, en revert eller en oppfølging. Teller mot feilraten for endringer selv når success=true. Driver den femte målingen (Rework Rate) etter DORA-rapporten for 2025.

Påkrevd scope på tokenet: findings:write, det samme scopet CI-workflower bruker for avhengighetsskanning og innlesing av SBOM-er. Opprett det under Organisasjonsadministrasjon → API-tokener (eller bruk bytte av token fra IdP-en til kunden for et kortlivet token).

Svarets form (201 ved første innsetting, 200 når det er en duplikat):

{
  "id": "0191e3b6-0000-7000-0000-000000000001",
  "tenant_id": "0191e3b6-0000-7000-0000-000000000000",
  "repo_full_name": "acme/web",
  "environment": "production",
  "deployed_at": "2026-05-14T10:00:00Z",
  "deduped": false
}

Eksempler på integrasjon i workflower

Actions-workflow i GitHub-stil på fremforge

# .forgejo/workflows/dora-ingest.yaml
name: Report deploy to DORA
on:
  workflow_run:
    workflows: [Deploy to production]
    types: [completed]

jobs:
  report:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - name: POST dora deployment
        run: |
          curl -X POST https://frem.sh/_app/api/v1/dora/deployments \
            -H "Authorization: Bearer ${{ secrets.FREMFORGE_API_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{
              "repo_full_name": "${{ github.repository }}",
              "environment": "production",
              "deployed_at": "'"$(date -u +%FT%TZ)"'",
              "commit_sha": "${{ github.sha }}",
              "committed_at": "'"$(git show -s --format=%cI HEAD)"'",
              "success": true,
              "external_ref": "actions-run:${{ github.run_id }}"
            }'

PostSync-hook i Argo CD

# argocd-postsync-dora.yaml
apiVersion: batch/v1
kind: Job
metadata:
  generateName: argocd-dora-
  annotations:
    argocd.argoproj.io/hook: PostSync
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: dora-report
          image: curlimages/curl:8.5.0
          envFrom:
            - secretRef: { name: fremforge-dora-token }
          args:
            - sh
            - -c
            - |
              curl -sS -X POST https://frem.sh/_app/api/v1/dora/deployments \
                -H "Authorization: Bearer $FREMFORGE_API_TOKEN" \
                -H "Content-Type: application/json" \
                -d "{
                  \"repo_full_name\": \"$REPO\",
                  \"environment\": \"$ENV\",
                  \"deployed_at\": \"$(date -u +%FT%TZ)\",
                  \"commit_sha\": \"$ARGOCD_APP_REVISION\",
                  \"success\": true,
                  \"external_ref\": \"argocd:$ARGOCD_APP_NAME:$ARGOCD_APP_REVISION\"
                }"

Merke en utrulling som tilbakerulling

curl -X POST https://frem.sh/_app/api/v1/dora/deployments \
  -H "Authorization: Bearer ffp_..." \
  -H "Content-Type: application/json" \
  -d '{
    "repo_full_name": "acme/web",
    "environment": "production",
    "deployed_at": "2026-05-14T10:30:00Z",
    "success": false,
    "is_rework": true,
    "external_ref": "rollback-from-deploy-12345"
  }'

Denne raden påvirker feilraten for endringer OG starter MTTR-klokken. Neste utrulling med success=true til (acme/web, production) stopper den.

Lese dashbordet

Adminsiden viser de sist beregnede verdiene for det gjeldende vinduet pluss en sparkline for 30 dager per måling. Hold markøren over et datapunkt for å se listen over utrullingene bak. Klikk på en måling for å se fordelingen per repository.

DORA-kategoriene (Elite / High / Medium / Low) for hver måling beregnes fortløpende mot tersklene fra Accelerate, de samme intervallene som DORA-rapporten fra Google Cloud bruker.

Hva vi bevisst ikke gjør

• Ingen sammenstilling per team. DORAs «Team»-akse krever at hver utrulling knyttes til et team, og det lar seg ikke utlede pålitelig fra repo_full_name alene ved utrullinger fra monorepoer og til flere kunder. Tilgjengelig via fordelingen per repository i dag; fullverdig sammenstilling per team er planlagt.
• Ingen sammenligning utenfor kunden. Bransjetall vises ikke: en sammenligning ville krevd at tallene dine sendes til en tredjeparts aggregator, og det strider mot avtalen om datalokalisering i EU. Bruk den offentlige DORA-rapporten for å se «hvor står vi sammenlignet med bransjen».
• Ingen automatisk kobling til «hendelser». MTTR beregnes fra paret success=false → neste success=true. Vi prøver ikke å utlede hendelsesvinduer fra PagerDuty, Statuspage eller aktivitet i Forgejo-issues; kundens eget signal om vellykket eller mislykket utrulling er den autoritative kilden.

Relatert

• Hva som kjører i hvert miljø: gjeldende og forrige utrulling per miljø, lest fra deploy-sperren, også som GET /_app/api/v1/orgs/<org>/deployments/live.
• Revisjonslogg: hver DORA-innlesing sender en revisjonshendelse (api.dora.deployments.ingested), så en administrator kan bekrefte opphavet til hvert tall som vises.
• Agentvennlig autentisering: bytt en JWT fra kundens IdP mot et kortlivet findings:write-token hvis du ikke vil vedlikeholde et langlivet PAT.
• API-tokener: opprett langlivede findings:write-PAT-er for CI-workflower under Brukerinnstillinger → API-tokener; se Autentiseringspolicy for maksimal levetid og rotasjonspolicy for hele organisasjonen.