DORA-instrumentpanel

DORA-instrumentpanelen visar de fyra måtten från DevOps Research and Assessments (DORA) rapport State of DevOps, beräknade löpande per organisation från de driftsättningshändelser som fremforge registrerar. Du hittar den under Organisationens administration → DORA.

Ingen extern tjänst. Inga data skickas till en instrumentpanel hos en tredjeparts-SaaS. Siffrorna beräknas inom fremforge tillsammans med dina repon, din granskningslogg och dina fynd, och de omfattas av samma garantier för datalagring inom EU och isolering mellan organisationer som allt annat under /<slug>/_admin/*.

De fyra måtten

Fönstret är som standard 30 dagar rullande. Du kan ändra det till 7, 30 eller 90 dagar under Organisationens administration → DORA → Inställningar.

Så kommer driftsättningar in i tabellen

Två inläsningsvägar körs parallellt. Använd den som passar hur du släpper versioner; många organisationer använder båda.

1. Forgejos release-webhook (automatisk)

När ett repo skapar en Forgejo-release (en annoterad tagg v* eller ett releaseobjekt som publiceras via gränssnittet eller POST /api/v1/repos/{owner}/{repo}/releases) registrerar fremforge en driftsättningshändelse med:

• environment = production (standard)
• deployed_at = releasens created_at
• commit_sha = releasens target_commitish omvandlad till en SHA
• committed_at = commitens author.date
• success = true
• external_ref = release:{release_id} (idempotent, så webhooken kan spelas upp igen utan risk)

Du behöver inte koppla upp något själv. Webhookens mål är konfigurerat på plattformsnivå, och den slås på automatiskt för varje organisation.

2. POST /_app/api/v1/dora/deployments (egen, rekommenderas för rikare telemetri)

För organisationer som inte taggar releaser (kontinuerlig driftsättning, GitOps med push vid merge, blue/green-växlingar) missar den automatiska inläsningen varje driftsättning. Skicka då en post per driftsättning med POST från ditt CI-arbetsflöde:

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

Obligatoriska: repo_full_name, environment, deployed_at.

Valfria men rekommenderade:

• commit_sha + committed_at: utan dem faller raden helt bort ur beräkningen av ledtid. De tre andra måtten räknar den fortfarande.
• success (standard true): sätt false vid rollback eller misslyckad driftsättning. Styr felfrekvens vid ändringar och MTTR.
• external_ref: nyckel för dubblettkontroll, avgränsad per organisation. Slutpunkten är idempotent på (tenant_id, repo_full_name, environment, external_ref): spelar ett omkört CI-jobb upp anropet igen får du 200 med id:t för den befintliga raden i stället för en dubblett. Utelämna den om du inte vill ha dubblettkontroll.
• is_rework (standard false): markerar driftsättningen som en hotfix, en återställning eller en uppföljning. Räknas in i felfrekvensen vid ändringar även när success=true. Styr det femte måttet (Rework Rate) enligt DORA-rapporten 2025.

Scope som tokenen behöver: findings:write, samma scope som CI-arbetsflöden använder för beroendeskanning och SBOM-inläsning. Skapa den under Organisationens administration → API-token (eller använd tokenutbyte från din egen IdP för att få en kortlivad token).

Svarets form (201 vid första inskrivningen, 200 när dubblettkontrollen slår till):

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

Exempel på integrationer i arbetsflöden

Actions-arbetsflöde 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\"
                }"

Markera en driftsättning 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"
  }'

Den här raden påverkar felfrekvensen vid ändringar OCH startar MTTR-klockan. Nästa driftsättning med success=true till (acme/web, production) stoppar den.

Läsa instrumentpanelen

Administrationssidan visar de senast beräknade värdena för det aktuella fönstret och en minigraf över 30 dagar per mått. Håll pekaren över en datapunkt för att se de underliggande driftsättningarna. Klicka på ett mått för att se fördelningen per repo.

DORA-kategorierna (Elite / High / Medium / Low) för varje mått beräknas löpande mot gränsvärdena i Accelerate, samma intervall som Google Clouds DORA-rapport använder.

Det här gör vi medvetet inte

• Ingen sammanställning per team. DORA:s dimension “Team” kräver att varje driftsättning kan knytas till ett team, och det går inte att härleda tillförlitligt enbart från repo_full_name vid driftsättningar från monorepon och med flera organisationer. Fördelningen per repo finns redan i dag; fullvärdig sammanställning per team är planerad.
• Ingen jämförelse utanför organisationen. Branschjämförelser visas inte: en jämförelse skulle kräva att dina siffror skickas till en tredjepartsaggregator, vilket strider mot avtalet om datalagring inom EU. Använd den publika DORA-rapporten när du vill se var du står jämfört med branschen.
• Ingen automatisk koppling till incidenter. MTTR beräknas från paret success=false → nästa success=true. Vi försöker inte härleda incidentfönster från PagerDuty, Statuspage eller aktivitet i Forgejo-issues. Det är kundens egen signal om lyckad eller misslyckad driftsättning som gäller.

Relaterat

• Vad som körs i varje miljö: den aktuella och den föregående driftsättningen per miljö, läst från driftsättningsgrinden, även som GET /_app/api/v1/orgs/<org>/deployments/live.
• Granskningslogg: varje DORA-inläsning ger en granskningshändelse (api.dora.deployments.ingested), så att en operatör kan spåra ursprunget till varje siffra som visas.
• Agentnativ autentisering: byt en JWT från kundens IdP mot en kortlivad token med findings:write om du inte vill underhålla en långlivad PAT.
• API-tokens: skapa långlivade PAT:ar med findings:write för CI-arbetsflöden under Användarinställningar → API-token; se Autentiseringspolicy för organisationens policy för maximal livslängd och rotation.