Passer au contenu principal
Gardez votre environnement de staging sous surveillance constante. Cette automatisation planifiée exécute chaque nuit l’ensemble de votre suite de tests E2E ou smoke sur le staging, capture les échecs avec tout le contexte nécessaire à leur reproduction, crée des tickets dans Linear pour les véritables régressions et publie un récapitulatif dans votre canal Slack QA — pour que vous sachiez exactement où en est le staging dès le début de chaque journée.

Utiliser ce modèle

Ouvrez QA nocturne et tests de fumée dans Devin et créez l’automatisation avec la configuration par défaut. Vous pouvez la personnaliser avant de l’enregistrer.
Vous cherchez un guide pratique ? Consultez le tutoriel étape par étape pour QA nocturne et tests de fumée.

​
Ce que fait cette automatisation

Le modèle Nightly QA est une automatisation de base pour toute équipe qui livre via un workflow de CI/staging. Devin exécute votre suite de tests (Playwright, Cypress, scripts personnalisés — tout ce que vous avez déjà en place), classe chaque échec comme un aléa de test ou une véritable régression, et crée des tickets avec suffisamment de contexte pour qu’une personne puisse le corriger sans avoir à le reproduire à nouveau.

​
Comment cela fonctionne

Déclencheur : Événement de planification — recurring
  • Événement : schedule:recurring
    • Conditions :
      • rrule correspond à FREQ=DAILY;BYHOUR=2;BYMINUTE=0
Ce que fait Devin : démarre une session avec l’ensemble du contexte de l’événement, exécute le prompt ci-dessous et, éventuellement, vous avertit en cas d’échec.

​
Prérequis

  • Intégrations : Aucune n’est requise. Cette automatisation fonctionne uniquement comme session planifiée.

​
Exemple de prompt

Ce modèle inclut ce prompt. Vous pouvez le modifier après avoir cliqué sur Utiliser le modèle, ou le laisser tel quel.

​
Mise en place

  1. Ouvrez Automations → Templates dans Devin.
  2. Cliquez sur QA nocturne et tests de fumée. La page de création s’ouvre avec ce modèle prérempli.
  3. Connectez toutes les intégrations requises et installez des serveurs MCP si ce n’est pas déjà fait.
  4. Remplacez les valeurs fictives dans les conditions de déclenchement (par exemple, remplacez your-org/your-repo par le nom réel de votre dépôt).
  5. Passez en revue le prompt et adaptez-le au langage, aux conventions et aux garde-fous de votre équipe.
  6. Cliquez sur Create automation.
La plupart des modèles d’automatisation incluent des limites d’ACU et d’invocation suggérées pour maîtriser les coûts pendant le déploiement progressif. Conservez-les telles quelles jusqu’à ce que vous soyez sûr du comportement de l’automatisation, puis augmentez-les en fonction de votre charge de travail.

​
Quand utiliser ce modèle

  • Détecter les régressions qui n’apparaissent que dans les environnements de staging
  • Préserver la confiance dans les suites de tests longues qui ne peuvent pas s’exécuter à chaque commit
  • Créer automatiquement des tickets pour les véritables flakes afin qu’ils ne tombent pas dans l’oubli
  • Maintenir votre cycle de retour QA en fonctionnement pendant la nuit et tout au long du week-end

​
Idées de personnalisation

  • Modifiez la planification (toutes les heures, à chaque déploiement, à la demande via webhook)
  • Utilisez n’importe quel framework de test — Playwright, Cypress, Jest, pytest, Go test
  • Envoyez les résultats vers Linear, Jira, les problèmes GitHub ou Slack
  • Ajoutez des secrets pour les identifiants de la base de données de staging afin que Devin puisse interroger les données de validation

​
Voir aussi