Gå til hovedindhold

DORA-dashboard

DORA-dashboardet viser de fire målinger fra DevOps Research and Assessments (DORA) State of DevOps-rapport, beregnet live pr. tenant ud fra de udrulningshændelser, fremforge registrerer. Du finder det under Administration → DORA.

Ingen ekstern tjeneste. Ingen data sendt til et SaaS-dashboard hos en tredjepart. Tallene beregnes i fremforge side om side med dine repositories, din revisionslog og dine fund — og de har de samme garantier for opbevaring i EU og adskillelse af tenants som alt andet under /<slug>/_admin/*.

De fire målinger

MålingHvad den målerSådan beregner fremforge den
UdrulningsfrekvensHvor ofte du leverer til produktionAntallet af vellykkede udrulningshændelser i produktion divideret med det rullende vindue. Rapporteres som udrulninger pr. dag og placeres derefter i DORA-kategorierne (Elite: ≥1/dag, High: 1/dag–1/uge, Medium: 1/uge–1/måned, Low: <1/måned).
Gennemløbstid for ændringerTiden fra commit til udrulningdeployed_at − committed_at, p50 + p95 over vinduet. Tæller kun udrulninger, der har angivet commit_sha + committed_at. Rapporteres i timer/dage.
Fejlrate for ændringerAndelen af udrulninger, der fejler eller kræver en rettelsecount(success=false OR is_rework=true) / count(*) over vinduet. Udtrykt i procent.
Gennemsnitlig tid til genopretning (MTTR)Tiden til at komme sig efter en fejlet udrulningFor hver hændelse med success=false den faktiske tid fra deployed_at til næste vellykkede udrulning til samme (repo, environment). Rapporteres som median.

Vinduet er som standard 30 dage, rullende. Kan sættes under Administration → DORA → Indstillinger til 7d / 30d / 90d.

Sådan kommer udrulninger ind i tabellen

To indlæsningsveje kører side om side. Brug den, der passer til den måde, du udgiver på; mange tenants bruger begge.

1. Forgejos release-webhook (automatisk)

Når et repository opretter en Forgejo-release (et annoteret tag v* eller et hvilket som helst release-objekt udgivet via brugerfladen / POST /api/v1/repos/{owner}/{repo}/releases), registrerer fremforge én udrulningshændelse med:

  • environment = production (standard)
  • deployed_at = releasens created_at
  • commit_sha = releasens target_commitish opløst til en SHA
  • committed_at = commit’ens author.date
  • success = true
  • external_ref = release:{release_id} (idempotent — webhooken kan sikkert afspilles igen)

Kunden skal ikke sætte noget op. Webhookens mål er konfigureret på platformsniveau; den slås automatisk til for hver organisation.

2. POST /_app/api/v1/dora/deployments (tilpasset — anbefales for rigere telemetri)

For tenants, der ikke tagger releases (continuous deployment, GitOps med push ved merge, blue/green-skift), går den automatiske indlæsning glip af hver eneste udrulning. Send én post pr. udrulning med POST fra dit CI-workflow:

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åkrævet: repo_full_name, environment, deployed_at.

Valgfrit, men anbefalet:

  • commit_sha + committed_at — uden dem falder rækken helt ud af beregningen af gennemløbstid. De tre andre målinger tæller den stadig med.
  • success (standard true) — sæt false ved rollback / fejlet udrulning. Styrer fejlrate for ændringer + MTTR.
  • external_ref — nøgle til dubletfjernelse, afgrænset til tenanten. Endpointet er idempotent på (tenant_id, repo_full_name, environment, external_ref): afspil kaldet igen fra et CI-job, der prøves igen, og du får 200 med den eksisterende rækkes id i stedet for en dobbelt indsættelse. Udelad den, hvis du ikke vil have dubletfjernelse.
  • is_rework (standard false) — markér udrulningen som en hotfix / revert / opfølgning. Tæller med i fejlraten for ændringer, selv når success=true. Styrer den 5. måling (Rework Rate) i DORA-rapporten fra 2025.

Påkrævet omfang på tokenet: findings:write — det samme omfang, som CI-workflows bruger til indlæsning af afhængighedsscanninger og SBOM’er. Opret det under Administration → API-tokens (eller brug token exchange fra din egen IdP for at få et kortlivet token).

Svarets form (201 ved første indsættelse, 200 ved dublet):

{
  "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å integration i workflows

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 }}"
            }'

Post-sync-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\"
                }"

Markér en udrulning som rollback

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 række påvirker fejlraten for ændringer OG starter MTTR-uret. Den næste udrulning med success=true til (acme/web, production) stopper det.

Sådan læser du dashboardet

Administrationssiden viser de senest beregnede værdier for det aktuelle vindue plus en sparkline over 30 dage for hver måling. Hold markøren over et datapunkt for at se de underliggende udrulninger. Klik på en måling for at se opdelingen pr. repository.

DORA-kategorierne (Elite / High / Medium / Low) for hver måling beregnes live ud fra tærsklerne i Accelerate — de samme intervaller, som Google Clouds DORA-rapport bruger.

Hvad vi bevidst ikke gør

  • Ingen sammentælling pr. team. DORA’s “Team”-akse kræver, at hver udrulning tilskrives et team, og det kan ikke udledes pålideligt af repo_full_name alene ved udrulninger fra monorepoer og flere tenants. Det er tilgængeligt via opdelingen pr. repository i dag; egentlig sammentælling pr. team er planlagt.
  • Ingen sammenligning uden for tenanten. Branchebenchmarks vises ikke — en sammenligning ville kræve, at dine tal sendes til en tredjepart, der samler dem, og det strider mod aftalen om opbevaring i EU. Brug den offentlige DORA-rapport, hvis du vil se, hvor du står i forhold til branchen.
  • Ingen automatisk kobling til “hændelser”. MTTR beregnes ud fra parret success=false → næste success=true. Vi forsøger ikke at udlede hændelsesvinduer fra PagerDuty, Statuspage eller aktivitet i Forgejo-issues — kundens eget signal om, at en udrulning lykkedes eller fejlede, er det autoritative input.

Relateret

  • Hvad der kører i hvert miljø: den aktuelle og den forrige udrulning pr. miljø, læst fra deploy-gaten, også som GET /_app/api/v1/orgs/<org>/deployments/live.
  • Revisionslog — hver DORA-indlæsning udsender en revisionshændelse (api.dora.deployments.ingested), så en administrator kan efterprøve oprindelsen af ethvert vist tal.
  • Agent-native godkendelse — byt en JWT fra din egen IdP til et kortlivet findings:write-token, hvis du ikke vil vedligeholde et langlivet PAT.
  • API-tokens — opret langlivede findings:write-PAT’er til CI-workflows under Brugerindstillinger → API-tokens; se Godkendelsespolitik for maksimal levetid og rotationspolitik for hele organisationen.