Tableau de bord DORA

Le tableau de bord DORA présente les quatre métriques du rapport State of DevOps de DevOps Research and Assessment (DORA), calculées en direct pour chaque tenant à partir des événements de déploiement enregistrés par fremforge. Il est accessible sous Administration de l’organisation → DORA.

Aucun service externe. Aucune donnée envoyée à un tableau de bord SaaS tiers. Les chiffres sont calculés dans fremforge, à côté de vos dépôts, de votre journal d’audit et de vos résultats d’analyse, et bénéficient des mêmes garanties de résidence dans l’UE et d’isolation entre tenants que tout ce qui se trouve sous /<slug>/_admin/*.

Les quatre métriques

La fenêtre est par défaut glissante sur 30 jours. Elle se règle sous Administration de l’organisation → DORA → Paramètres, entre 7 j, 30 j et 90 j.

Comment les déploiements arrivent dans la table

Deux chemins d’ingestion fonctionnent en parallèle. Utilisez celui qui correspond à votre façon de livrer ; de nombreux tenants utilisent les deux.

1. Webhook release de Forgejo (automatique)

Lorsqu’un dépôt crée une version Forgejo (tag annoté v* ou tout objet de version publié via l’interface ou POST /api/v1/repos/{owner}/{repo}/releases), fremforge enregistre un événement de déploiement avec :

• environment = production (par défaut)
• deployed_at = created_at de la version
• commit_sha = target_commitish de la version, résolu en SHA
• committed_at = author.date du commit
• success = true
• external_ref = release:{release_id} (idempotent : vous pouvez rejouer le webhook sans risque)

Aucun câblage n’est requis côté client. La cible du webhook est configurée au niveau de la plateforme ; l’activation par organisation est automatique.

2. POST /_app/api/v1/dora/deployments (personnalisé : recommandé pour une télémétrie plus riche)

Pour les tenants qui ne taguent pas leurs versions (déploiement continu, GitOps avec push à la fusion, bascules blue/green), l’ingestion automatique manque chaque déploiement. Envoyez un enregistrement par déploiement depuis votre workflow de CI :

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

Obligatoires : repo_full_name, environment, deployed_at.

Facultatifs mais recommandés :

• commit_sha + committed_at : sans eux, la ligne est entièrement exclue du calcul du délai de mise en production. Les trois autres métriques la prennent toujours en compte.
• success (true par défaut) : mettez false pour un retour arrière ou un déploiement en échec. Alimente le taux d’échec des changements et le MTTR.
• external_ref : clé de déduplication, propre au tenant. Le point d’accès est idempotent sur (tenant_id, repo_full_name, environment, external_ref) : rejouez l’appel depuis un job de CI relancé et vous obtenez un 200 avec l’identifiant de la ligne existante plutôt qu’une insertion en double. Omettez-la si vous ne voulez pas de déduplication.
• is_rework (false par défaut) : signale un correctif urgent, un revert ou un suivi. Compte dans le taux d’échec des changements même lorsque success=true. Alimente la 5e métrique (Rework Rate) du rapport DORA 2025.

Portée requise sur le jeton : findings:write, la même portée que celle utilisée par les workflows de CI pour l’ingestion des analyses de dépendances et des SBOM. Créez-le sous Administration de l’organisation → Jetons d’API (ou utilisez l’échange de jetons depuis l’IdP de votre entreprise pour obtenir un jeton de courte durée).

Forme de la réponse (201 à la première insertion, 200 en cas de doublon détecté) :

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

Exemples d’intégration dans des workflows

Workflow Actions de style GitHub sur 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 }}"
            }'

Hook post-sync d’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\"
                }"

Signaler un déploiement comme retour arrière

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

Cette ligne pèse sur le taux d’échec des changements ET démarre le chronomètre du MTTR. Le déploiement success=true suivant vers (acme/web, production) l’arrête.

Lire le tableau de bord

La page d’administration affiche les dernières valeurs calculées pour la fenêtre en cours, ainsi qu’une mini-courbe sur 30 jours pour chaque métrique. Survolez un point pour voir la liste des déploiements correspondants. Cliquez sur une métrique pour afficher la ventilation par dépôt.

Les catégories DORA (Elite / High / Medium / Low) de chaque métrique sont calculées en direct par rapport aux seuils d’Accelerate, les mêmes tranches que celles du rapport DORA de Google Cloud.

Ce que nous ne faisons volontairement pas

• Pas d’agrégation par équipe. L’axe « Team » de DORA exige d’attribuer chaque déploiement à une équipe, ce qui ne se déduit pas de façon fiable du seul repo_full_name dans les déploiements en monorepo et multi-tenants. C’est disponible aujourd’hui via la ventilation par dépôt ; une véritable agrégation par équipe est prévue.
• Pas de comparaison hors du tenant. Les références sectorielles ne sont pas affichées : une comparaison exigerait d’envoyer vos chiffres à un agrégateur tiers, ce qui contredit l’engagement contractuel de résidence dans l’UE. Utilisez le rapport DORA public pour vous situer par rapport au secteur.
• Pas de rattachement automatique aux « incidents ». Le MTTR est calculé à partir de la paire success=false → success=true suivant. Nous ne cherchons pas à déduire des fenêtres d’incident depuis PagerDuty, Statuspage ou l’activité des tickets Forgejo : le signal de réussite ou d’échec de déploiement du client fait foi.

Voir aussi

• Ce qui est déployé dans chaque environnement : le déploiement actuel et le précédent par environnement, lus depuis le contrôle de déploiement, aussi via GET /_app/api/v1/orgs/<org>/deployments/live.
• Journal d’audit : chaque ingestion DORA émet un événement d’audit (api.dora.deployments.ingested), afin qu’un administrateur puisse vérifier l’origine de tout chiffre affiché.
• Authentification native pour les agents : échangez un JWT de l’IdP de votre entreprise contre un jeton findings:write de courte durée si vous ne voulez pas gérer un PAT de longue durée.
• Jetons d’API : créez des PAT findings:write de longue durée pour les workflows de CI sous Paramètres utilisateur → Jetons d’API ; voir Politique d’authentification pour la politique de durée de vie maximale et de rotation à l’échelle de l’organisation.