Lancer des tests E2E nocturnes sur la préproduction
Planifiez Devin pour exécuter votre suite de tests E2E sur l'environnement de préproduction chaque nuit et créer des tickets pour chaque échec.Ce guide explique comment gérer les planifications via l’API v3, ce qui est utile pour les workflows d’automatisation et d’infrastructure-as-code. Vous pouvez également créer et gérer des planifications directement dans l’interface utilisateur de Devin sans aucune configuration d’API.
Configurer un compte de service pour l’accès à l’API
Les sessions planifiées 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.Exportez les deux valeurs afin que les commandes de ce guide fonctionnent telles quelles :Consultez la documentation sur l’authentification de l’API pour plus d’informations sur les comptes de service et leurs autorisations.
- Accédez à app.devin.ai > Settings > Service Users et cliquez sur Create Service User
- Attribuez un rôle qui inclut l’autorisation
ManageOrgSchedules - Enregistrez l’API key affichée après la création — elle n’est affichée qu’une seule fois et vous l’utiliserez comme jeton
Bearer
Rédigez un playbook pour le test
Avant de créer le planning, 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 utilisez Advanced Devin pour 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 en aurez besoin pour l’appel à l’API. Vous pouvez le trouver dans l’URL lorsque vous affichez le playbook (
app.devin.ai/.../playbooks/{playbook_id}).Créer la planification nocturne via l’API
Utilisez maintenant l’endpoint La réponse contient un Le champ
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 schedule » pour voir tous les champs disponibles.
POST /v3/organizations/{org_id}/schedules pour enregistrer la planification. Cet exemple s’exécute chaque nuit à 2 h UTC :schedule_id que vous utiliserez pour gérer ce planning par la suite. Enregistrez-le :frequency utilise la syntaxe cron standard. Quelques alternatives utiles :| Pattern | When it runs |
|---|---|
0 2 * * * | Tous les jours à 2 h (UTC) |
0 2 * * 1-5 | Du lundi au vendredi à 2 h (UTC) |
0 6 * * 1 | Tous les lundis à 6 h (UTC) |
Vérifier la première exécution et affiner le prompt
Après la première exécution de la planification, 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 le tableau de bord Devin et trouvez la session sous Past Sessions — elle sera étiquetée avec le nom de la planification.
- 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-resultspour le message récapitulatif.
- Devin ne peut pas accéder au staging : ajoutez vos variables d’environnement de staging (comme
STAGING_API_KEYouDATABASE_URL) en tant que organization secrets afin qu’elles soient disponibles dans chaque session planifiée. - 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/ettests/smoke/» — ou augmentez le délai d’expiration de la session.
Gérez les plannings 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 planifications — 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 planification pour un environnement différent.Mettez la planification en pause pendant un gel de déploiement ou une fenêtre de maintenance :Réactivez-la une fois le gel terminé :Répertoriez toutes les planifications pour vérifier ce qui est en cours d’exécution :Pour les équipes qui gèrent plusieurs plannings, demandez à Devin de créer un CLI qui synchronise les définitions de plannings à partir d’un fichier de configuration YAML, afin que vous puissiez placer vos plannings sous gestion de versions en même temps que votre configuration de test :
