Exécuter des tests E2E nocturnes en préproduction

Vous ne souhaitez pas effectuer cette configuration manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous.

Ce guide explique comment gérer les automatisations planifiées via l’API v3, ce qui est utile pour les workflows d’infrastructure-as-code. Vous pouvez également les créer et les gérer directement depuis la page Automations sans aucune configuration d’API.

Configurer un compte de service pour l’accès à l’API

Les automatisations créées via l’API nécessitent un utilisateur de service avec les autorisations appropriées. Vous en configurerez un une seule fois, puis utiliserez son API key dans tous les appels ci-dessous.

Accédez à app.devin.ai > Settings > Devin API, ouvrez l’onglet Service users et cliquez sur Provision service user
Attribuez un rôle qui inclut l’autorisation ManageOrgAutomations
Enregistrez l’API key affichée après le provisioning — elle n’est affichée qu’une seule fois et vous l’utiliserez comme jeton Bearer

Votre ID d’organisation est affiché en haut de la page Settings > Devin API. Les utilisateurs de service Enterprise dont le rôle inclut ViewOrganizations peuvent également appeler l’endpoint List Organizations avec leur jeton :

curl "https://api.devin.ai/v3/enterprise/organizations" \
  -H "Authorization: Bearer $DEVIN_API_KEY"

Exportez les deux valeurs afin que les commandes de ce guide fonctionnent telles quelles :

export DEVIN_API_KEY="sk-your-service-user-key"
export ORG_ID="your-org-id"

Consultez la documentation sur l’authentification de l’API pour plus d’informations sur les comptes de service et leurs autorisations.

Rédigez un playbook pour l’exécution du test

Avant de créer l’automatisation, rédigez un playbook qui indique à Devin exactement comment exécuter votre suite E2E et quoi faire des résultats. Allez dans Settings > Playbooks et créez un nouveau playbook — ou demandez à Devin d’en générer un à partir d’une description de votre workflow de test. Voici un exemple pour une suite Playwright :Notez l’ID du playbook après l’avoir enregistré — vous le référencerez dans le prompt de l’automatisation. Vous pouvez le trouver dans l’URL lorsque vous affichez le playbook (app.devin.ai/.../playbooks/{playbook_id}).

Installez l’intégration Linear afin que Devin puisse créer des tickets dans le cadre du playbook. Lors de la modification de l’automatisation sur la page Automations, vous pouvez également ajouter une notification Post to Slack (par exemple, #qa-results) pour que votre équipe reçoive automatiquement des notifications. Donnez à Devin un accès en lecture seule aux secrets de votre environnement de staging (URL de base de données, API keys) via les secrets d’organisation si vos tests en ont besoin.

Créer l’automatisation nocturne via l’API

Utilisez maintenant l’endpoint POST /v3/organizations/{org_id}/automations pour enregistrer une automatisation avec un trigger schedule:recurring et une action start_session. Référencez le playbook dans le prompt à l’aide d’un token @playbook:{id}. Les sessions démarrées par une automatisation ne disposent que des outils que vous leur accordez : le bloc tools active donc les outils Linear et permet à Devin de publier dans votre canal #qa-results (remplacez les ID du workspace et du canal Slack par les vôtres). Cet exemple s’exécute chaque nuit à 2 h UTC :

curl -X POST "https://api.devin.ai/v3/organizations/$ORG_ID/automations" \
  -H "Authorization: Bearer $DEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Nightly E2E — staging",
    "run_as": {"type": "organization"},
    "triggers": [{
      "event_type": "schedule:recurring",
      "conditions": {"any": [{"all": [{
        "field": "rrule",
        "operator": "recurrence",
        "value": "FREQ=DAILY;BYHOUR=2;BYMINUTE=0"
      }]}]}
    }],
    "actions": [{
      "type": "start_session",
      "prompt": "Run the nightly E2E test suite against staging. Follow @playbook:your-playbook-id exactly."
    }],
    "tools": {
      "linear_enabled": true,
      "slack_channels": [{"team_id": "T0123456789", "channel_id": "C0123456789"}]
    }
  }'

La réponse contient un automation_id que vous utiliserez pour gérer cette automation par la suite. Enregistrez-le :

export AUTOMATION_ID="a1b2c3d4e5f6789012345678"  # automation_id extrait de la réponse

La condition rrule prend une RRULE iCalendar évaluée en UTC. Quelques alternatives utiles :

Pattern	When it runs
`FREQ=DAILY;BYHOUR=2;BYMINUTE=0`	Tous les jours à 2 h (UTC)
`FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=2;BYMINUTE=0`	Du lundi au vendredi à 2 h (UTC)
`FREQ=WEEKLY;BYDAY=MO;BYHOUR=6;BYMINUTE=0`	Tous les lundis à 6 h (UTC)

Pourquoi 2 h ? Vous voulez que les tests s’exécutent une fois que le dernier déploiement de la journée s’est stabilisé sur l’environnement de staging, mais suffisamment tôt pour que les échecs soient visibles lorsque les ingénieurs commencent à travailler. Adaptez ce réglage au fuseau horaire de votre équipe et à votre cadence de déploiement.Consultez la documentation de l’endpoint « Create automation » pour voir tous les champs disponibles.

Vérifier la première exécution et affiner le prompt

Après le premier déclenchement de l’automatisation, vérifiez la session pour vous assurer que Devin a lancé les tests correctement et que les résultats correspondent à ce que vous attendez.

Ouvrez l’automatisation sur la page Automations et suivez le lien de session dans son onglet Activity
La suite Playwright s’est‑elle exécutée ? Des tickets Linear ont‑ils été créés pour des échecs réels (et non pour des tests instables) ?
Vérifiez le canal Slack #qa-results pour le message récapitulatif

Problèmes fréquents lors de la première exécution et comment les corriger :

Devin ne peut pas accéder au staging : ajoutez vos variables d’environnement de staging (comme STAGING_API_KEY ou DATABASE_URL) en tant que organization secrets afin qu’elles soient disponibles dans chaque session lancée par l’automatisation
Trop de tickets dus à des tests instables : ajoutez une nouvelle tentative à votre playbook : « Relancez tout test en échec une fois avant de créer un ticket. Ne créez des tickets que pour les tests qui échouent deux fois. »
Les tests prennent trop de temps : restreignez la portée de la suite — par exemple : « N’exécutez que les tests dans tests/critical/ et tests/smoke/ » — ou augmentez le délai d’expiration de la session

Gérez les automatisations sous forme de code

Une fois que votre exécution nocturne est stable, vous voudrez la gérer au même titre que vos autres automatisations — la mettre en pause pendant les gels de déploiement, mettre à jour le prompt lorsque votre suite de tests évolue, ou configurer une deuxième automatisation pour un environnement différent.Mettez l’automatisation en pause pendant un gel de déploiement ou une fenêtre de maintenance :

curl -X PATCH "https://api.devin.ai/v3/organizations/$ORG_ID/automations/$AUTOMATION_ID" \
  -H "Authorization: Bearer $DEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

Réactivez-la une fois le gel terminé :

curl -X PATCH "https://api.devin.ai/v3/organizations/$ORG_ID/automations/$AUTOMATION_ID" \
  -H "Authorization: Bearer $DEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Répertoriez toutes les automatisations pour vérifier ce qui est en cours d’exécution :

curl "https://api.devin.ai/v3/organizations/$ORG_ID/automations" \
  -H "Authorization: Bearer $DEVIN_API_KEY"

Pour les équipes qui gèrent plusieurs automatisations, demandez à Devin de créer un CLI qui synchronise les définitions d’automatisations à partir d’un fichier de configuration YAML, afin que vous puissiez placer vos automatisations sous gestion de versions en même temps que votre configuration de test :