Environnements
Là où un projet s'exécute, avec une cible par plateforme et les valeurs qu'utilisent ses cas de test.
Un environnement est un endroit où un projet s'exécute : Production, Staging, QA ou un déploiement de prévisualisation. Les cas de test ne changent pas d'un environnement à l'autre. Une exécution choisit un environnement, et c'est lui qui fournit l'URL, le build de l'application et les valeurs.
Ouvrez un projet et cliquez sur Environments. Les propriétaires et les administrateurs ajoutent et modifient les environnements ; les membres peuvent les consulter.
Cibles de plateforme
Un environnement possède une cible pour chaque plateforme qu'il peut tester. Un projet teste toutes les plateformes pour lesquelles ses environnements ont une cible.
| Plateforme | Cible |
|---|---|
| Web | Une URL, comme https://qa.example.com. L'agent utilise Chrome. |
| API | Une URL de base. L'agent envoie directement des requêtes HTTP, sans navigateur ni appareil. |
| Android | Un fichier .apk ou .aab que vous téléversez, ou un lien de téléchargement direct vers ce fichier. |
| iOS | Bientôt disponible. Tant que les tests iOS ne sont pas disponibles, une cible iOS ne peut pas être enregistrée. |
Autonomy lit le nom de package ou le bundle ID de l'application, ainsi que sa version, dans le build : vous n'avez rien à saisir. Les exécutions utilisent le build enregistré sur l'environnement. Pour tester un nouveau build, téléversez-le ou enregistrez à nouveau le lien de téléchargement dans l'environnement. Les fichiers téléversés font l'objet d'un contrôle de sécurité avant qu'une exécution puisse les utiliser. Pour envoyer un build depuis la CI, voir Builds mobiles.
Valeurs d'environnement
Les valeurs d'environnement sont des valeurs nommées que vos étapes utilisent sous la forme {{env.NAME}}, comme {{env.TEST_USER_EMAIL}} ou {{env.COUPON_CODE}}. Chaque exécution les renseigne à partir de l'environnement dans lequel elle s'exécute : le même cas de test fonctionne ainsi sur tous les environnements.
- Les noms s'écrivent en majuscules, avec des underscores :
TEST_USER_EMAIL. - Cochez Secret pour les mots de passe, les jetons et les clés. Les secrets sont en écriture seule : personne ne peut plus consulter un secret enregistré, et seules les exécutions le reçoivent. L'agent renseigne un secret par référence sans jamais voir sa valeur, et celle-ci n'apparaît jamais dans les preuves.
- Une valeur peut être remplacée pour une plateforme : Override a value for Android remplace la valeur du même nom sur Android uniquement.
- Si une étape utilise un nom que l'environnement ne définit pas, le cas de test le signale comme manquant avant que vous ne l'exécutiez.
Les valeurs sont lues au moment où un runner prend en charge une exécution. Si vous modifiez une valeur, les exécutions en file d'attente utilisent la nouvelle. Si vous supprimez une valeur dont a besoin une exécution en file d'attente, celle-ci se termine en Couldn't start.
Pour les comptes, utilisez des connexions plutôt que des valeurs : l'agent choisit le bon compte pour une étape et renseigne son mot de passe et son code d'authentification par référence.
Responsables
Ajoutez des responsables (maintainers) à un environnement pour leur envoyer ses échecs, ses problèmes de connexion et son digest hebdomadaire.
Archiver un environnement
L'archivage d'un environnement conserve ses exécutions et ses problèmes. Les nouvelles exécutions ne peuvent plus le choisir. Les administrateurs archivent les environnements depuis la page de l'environnement.
Production
Quand vous exécutez sur un environnement nommé Production, l'agent se comporte comme un utilisateur prudent : il ne dépense pas d'argent réel et ne supprime pas de données existantes, sauf si une étape le demande. Utilisez un environnement de test pour tout ce qui est destructif.
Vous n’avez pas trouvé ?