Partie 1 : Web/Android
Noter: cet article est une traduction en russe de l'article original Cependant, toutes les illustrations, liens, citations et termes sont conservés dans la langue originale afin d'éviter toute distorsion du sens lorsqu'ils sont traduits en russe. Je vous souhaite de bonnes études !
Actuellement, la spécialité DevOps est l'une des plus demandées dans le secteur informatique. Si vous ouvrez des sites de recherche d'emploi populaires et filtrez par salaire, vous verrez que les emplois liés au DevOps figurent en haut de la liste. Cependant, il est important de comprendre qu'il s'agit principalement d'un poste « Senior », ce qui implique que le candidat possède un haut niveau de compétences, de connaissances en technologie et en outils. Cela s’accompagne également d’un haut degré de responsabilité lié au fonctionnement ininterrompu de la production. Cependant, nous avons commencé à oublier ce qu’est le DevOps. Au départ, il ne s’agissait pas d’une personne ou d’un département en particulier. Si nous cherchons des définitions de ce terme, nous trouverons de nombreux noms beaux et corrects, tels que méthodologie, pratiques, philosophie culturelle, groupe de concepts, etc.
Ma spécialisation est ingénieur en automatisation des tests (ingénieur en automatisation QA), mais je pense qu'elle ne doit pas être associée uniquement à l'écriture de tests automatiques ou au développement d'une architecture de cadre de test. En 2020, la connaissance de l’infrastructure d’automatisation est également essentielle. Cela vous permet d'organiser vous-même le processus d'automatisation, de l'exécution des tests à la fourniture de résultats à toutes les parties prenantes conformément à vos objectifs. Par conséquent, les compétences DevOps sont indispensables pour accomplir le travail. Et tout cela est bien, mais malheureusement, il y a un problème (spoiler : cet article tente de simplifier ce problème). Le fait est que DevOps est difficile. Et c’est une évidence, car les entreprises ne paieront pas cher pour quelque chose de facile à faire… Dans le monde DevOps, il existe un grand nombre d’outils, de termes et de pratiques qu’il faut maîtriser. Ceci est particulièrement difficile en début de carrière et dépend de l'expérience technique accumulée.
Source:
Ici, nous terminerons probablement par la partie introductive et nous concentrerons sur l’objet de cet article.
De quoi parle l'article?
Dans cet article, je vais partager mon expérience dans la création d'une infrastructure d'automatisation des tests. Il existe de nombreuses sources d'informations sur Internet sur divers outils et comment les utiliser, mais j'aimerais les examiner uniquement dans le contexte de l'automatisation. Je pense que de nombreux ingénieurs en automatisation connaissent la situation dans laquelle personne, à part vous, n'exécute les tests développés ou ne se soucie de leur maintenance. En conséquence, les tests deviennent obsolètes et vous devez passer du temps à les mettre à jour. Encore une fois, au début d'une carrière, cela peut s'avérer une tâche assez difficile : décider judicieusement quels outils devraient aider à éliminer un problème donné, comment les sélectionner, les configurer et les entretenir. Certains testeurs se tournent vers DevOps (humains) pour obtenir de l'aide et, soyons honnêtes, cette approche fonctionne. Dans de nombreux cas, cela peut être la seule option puisque nous n'avons pas de visibilité sur toutes les dépendances. Mais comme nous le savons, les DevOps sont des gars très occupés, car ils doivent penser à l'infrastructure, au déploiement, à la surveillance, aux microservices et à d'autres tâches similaires de l'ensemble de l'entreprise en fonction de l'organisation/de l'équipe. Comme c’est généralement le cas, l’automatisation n’est pas une priorité. Dans un tel cas, nous devons essayer de faire tout notre possible de notre part, du début à la fin. Cela réduira les dépendances, accélérera le flux de travail, améliorera nos compétences et nous permettra d’avoir une vue d’ensemble de ce qui se passe.
L'article présente les outils les plus populaires et montre comment les utiliser pour créer une infrastructure d'automatisation étape par étape. Chaque groupe est représenté par des outils qui ont été testés par expérience personnelle. Mais cela ne veut pas dire que vous devez utiliser la même chose. Les outils eux-mêmes ne sont pas importants, ils apparaissent et deviennent obsolètes. Notre tâche d'ingénierie est de comprendre les principes de base : pourquoi nous avons besoin de ce groupe d'outils et quels problèmes de travail nous pouvons résoudre avec leur aide. C'est pourquoi, à la fin de chaque section, je laisse des liens vers des outils similaires qui peuvent être utilisés dans votre organisation.
Ce qui n'est pas dans cet article
Je répète encore une fois que l'article ne concerne pas des outils spécifiques, il n'y aura donc pas d'insertions de code provenant de la documentation ni de descriptions de commandes spécifiques. Mais à la fin de chaque section, je laisse des liens pour une étude détaillée.
Ceci est fait parce que :
- ce matériel est très facile à trouver dans diverses sources (documentation, livres, cours vidéo) ;
- si nous commençons à approfondir, nous devrons écrire 10, 20, 30 parties de cet article (alors que les plans sont 2-3) ;
- Je ne veux tout simplement pas vous faire perdre du temps, car vous souhaiterez peut-être utiliser d'autres outils pour atteindre les mêmes objectifs.
Pratique
J'aimerais vraiment que ce matériel soit utile à chaque lecteur, et pas seulement lu et oublié. Dans toute étude, la pratique est un élément très important. Pour cela j'ai préparé. Il y a aussi des devoirs qui vous attendent pour vous assurer que vous ne copiez pas sans réfléchir les lignes des commandes que vous exécutez.
Plan
étapes
Technologie
Outils
1
Exécution locale (préparer des tests de démonstration Web/Android et les exécuter localement)
Node.js, Sélénium, Appium
2
Systèmes de contrôle de version
Git
3
Conteneurisation
Docker, grille Selenium, Selenoid (Web, Android)
4
CI/CD
CI Gitlab
5
Plateformes cloud
Google Cloud Platform
6
Orchestration
Kubernetes
7
Infrastructure en tant que code (IaC)
Terraforme, Ansible
Structure de chaque section
Pour que le récit reste clair, chaque section est décrite selon le schéma suivant :
- brève description de la technologie,
- valeur pour l'infrastructure d'automatisation,
- illustration de l'état actuel de l'infrastructure,
- des liens pour étudier,
- outils similaires.
1. Exécutez des tests localement
Brève description de la technologie
Il s'agit simplement d'une étape préparatoire pour exécuter les tests de démonstration localement et vérifier qu'ils réussissent. Dans la partie pratique, Node.js est utilisé, mais le langage de programmation et la plateforme ne sont pas non plus importants et vous pouvez utiliser ceux qui sont utilisés dans votre entreprise.
Cependant, en tant qu'outils d'automatisation, je recommande d'utiliser respectivement Selenium WebDriver pour les plates-formes Web et Appium pour la plate-forme Android, car dans les prochaines étapes, nous utiliserons des images Docker conçues pour fonctionner spécifiquement avec ces outils. De plus, en ce qui concerne les exigences du poste, ces outils sont les plus demandés sur le marché.
Comme vous l’avez peut-être remarqué, nous ne considérons que les tests web et Android. Malheureusement, iOS est une histoire complètement différente (merci Apple). Je prévois de présenter les solutions et pratiques liées à IOS dans les prochaines parties.
Valeur pour l'infrastructure d'automatisation
Du point de vue de l'infrastructure, l'exécution locale n'apporte aucune valeur. Vous vérifiez uniquement que les tests s'exécutent sur la machine locale dans les navigateurs et simulateurs locaux. Mais c’est en tout cas un point de départ nécessaire.
Illustration de l’état actuel des infrastructures
Liens à découvrir
Outils similaires
- n'importe quel langage de programmation que vous aimez en conjonction avec les tests Selenium/Appium ;
- tous les tests ;
- n'importe quel testeur.
2. Systèmes de contrôle de version (Git)
Brève description de la technologie
Ce ne sera une grande révélation pour personne si je dis que le contrôle de version est une partie extrêmement importante du développement, tant en équipe qu'individuellement. Sur la base de diverses sources, on peut affirmer avec certitude que Git est le représentant le plus populaire. Un système de contrôle de version offre de nombreux avantages, tels que le partage de code, le stockage des versions, la restauration vers les branches précédentes, la surveillance de l'historique du projet et les sauvegardes. Nous ne discuterons pas de chaque point en détail, car je suis sûr que vous le connaissez très bien et que vous l'utilisez dans votre travail quotidien. Mais si ce n’est soudainement pas le cas, je vous recommande de suspendre la lecture de cet article et de combler cette lacune dès que possible.
Valeur pour l'infrastructure d'automatisation
Et ici, vous pouvez poser une question raisonnable : « Pourquoi nous parle-t-il de Git ? Tout le monde le sait et l’utilise à la fois pour le code de développement et pour le code de test automatique. Vous aurez tout à fait raison, mais dans cet article nous parlons d’infrastructure et cette section fait office d’aperçu pour la section 7 : « Infrastructure as Code (IaC) ». Pour nous, cela signifie que l'ensemble de l'infrastructure, y compris les tests, est décrit sous forme de code, ce qui nous permet également d'y appliquer des systèmes de gestion de versions et d'obtenir des avantages similaires à ceux du code de développement et d'automatisation.
Nous examinerons IaC plus en détail à l'étape 7, mais même maintenant, vous pouvez commencer à utiliser Git localement en créant un référentiel local. La vue d’ensemble sera élargie lorsque nous ajouterons un référentiel distant à l’infrastructure.
Illustration de l’état actuel des infrastructures
Liens à découvrir
Outils similaires
3. Conteneurisation (Docker)
Brève description de la technologie
Pour démontrer comment la conteneurisation a changé les règles du jeu, remontons le temps de quelques décennies. À l’époque, les gens achetaient et utilisaient des serveurs pour exécuter des applications. Mais dans la plupart des cas, les ressources nécessaires au démarrage n’étaient pas connues à l’avance. En conséquence, les entreprises ont dépensé de l’argent pour acheter des serveurs coûteux et puissants, mais une partie de cette capacité n’a pas été pleinement utilisée.
L'étape suivante de l'évolution a été celle des machines virtuelles (VM), qui ont résolu le problème du gaspillage d'argent sur des ressources inutilisées. Cette technologie permettait d'exécuter des applications indépendamment les unes des autres au sein d'un même serveur, en allouant un espace complètement isolé. Mais malheureusement, toute technologie a ses inconvénients. Faire fonctionner une VM nécessite un système d’exploitation complet, qui consomme du CPU, de la RAM, du stockage et, selon le système d’exploitation, les coûts de licence doivent être pris en compte. Ces facteurs affectent la vitesse de chargement et rendent la portabilité difficile.
Et maintenant nous arrivons à la conteneurisation. Une fois de plus, cette technologie résout le problème précédent, car les conteneurs n'utilisent pas de système d'exploitation complet, ce qui libère une grande quantité de ressources et offre une solution rapide et flexible pour la portabilité.
Bien entendu, la technologie de conteneurisation n’est pas nouvelle et a été introduite pour la première fois à la fin des années 70. À cette époque, de nombreuses recherches, développements et tentatives ont été réalisés. Mais c’est Docker qui a adapté cette technologie et l’a rendue facilement accessible au grand public. De nos jours, lorsque nous parlons de conteneurs, nous parlons dans la plupart des cas de Docker. Lorsque nous parlons de conteneurs Docker, nous entendons les conteneurs Linux. Nous pouvons utiliser les systèmes Windows et macOS pour exécuter des conteneurs, mais il est important de comprendre que dans ce cas, une couche supplémentaire apparaît. Par exemple, Docker sur Mac exécute silencieusement des conteneurs dans une machine virtuelle Linux légère. Nous reviendrons sur ce sujet lorsque nous discuterons de l'exécution d'émulateurs Android dans des conteneurs. Il y a donc ici une nuance très importante qui doit être discutée plus en détail.
Valeur pour l'infrastructure d'automatisation
Nous avons découvert que la conteneurisation et Docker sont cool. Regardons cela dans le contexte de l'automatisation, car chaque outil ou technologie doit résoudre un problème. Décrivons les problèmes évidents de l'automatisation des tests dans le contexte des tests d'interface utilisateur :
- un grand nombre de dépendances lors de l'installation de Selenium et surtout d'Appium ;
- problèmes de compatibilité entre les versions des navigateurs, des simulateurs et des pilotes ;
- manque d'espace isolé pour les navigateurs/simulateurs, ce qui est particulièrement critique pour l'exécution en parallèle ;
- difficile à gérer et à maintenir si vous devez exécuter 10, 50, 100 ou même 1000 XNUMX navigateurs en même temps.
Mais comme Selenium est l'outil d'automatisation le plus populaire et Docker est l'outil de conteneurisation le plus populaire, il n'est pas surprenant que quelqu'un ait essayé de les combiner pour créer un outil puissant permettant de résoudre les problèmes mentionnés ci-dessus. Examinons ces solutions plus en détail.
Grille de sélénium dans Docker
Cet outil est le plus populaire dans le monde Selenium pour exécuter plusieurs navigateurs sur plusieurs machines et les gérer à partir d'un hub central. Pour commencer, vous devez enregistrer au moins 2 parties : Hub et Node(s). Hub est un nœud central qui reçoit toutes les requêtes des tests et les distribue aux nœuds appropriés. Pour chaque Node nous pouvons configurer une configuration spécifique, par exemple en précisant le navigateur souhaité et sa version. Cependant, nous devons toujours nous occuper nous-mêmes des pilotes de navigateur compatibles et les installer sur les nœuds souhaités. Pour cette raison, la grille Selenium n'est pas utilisée sous sa forme pure, sauf lorsque nous devons travailler avec des navigateurs qui ne peuvent pas être installés sur le système d'exploitation Linux. Pour tous les autres cas, une solution très flexible et correcte consisterait à utiliser des images Docker pour exécuter Selenium Grid Hub et Nodes. Cette approche simplifie grandement la gestion des nœuds, puisque nous pouvons sélectionner l'image dont nous avons besoin avec les versions compatibles des navigateurs et des pilotes déjà installés.
Malgré les critiques négatives sur la stabilité, en particulier lors de l'exécution d'un grand nombre de nœuds en parallèle, la grille Selenium reste l'outil le plus populaire pour exécuter des tests Selenium en parallèle. Il est important de noter que diverses améliorations et modifications de cet outil apparaissent constamment en open source, qui combattent divers goulots d'étranglement.
Sélénoïde pour le Web
Cet outil constitue une avancée majeure dans le monde de Selenium car il fonctionne immédiatement et a rendu la vie de nombreux ingénieurs en automatisation beaucoup plus facile. Tout d’abord, il ne s’agit pas d’une autre modification de la grille Selenium. Au lieu de cela, les développeurs ont créé une toute nouvelle version de Selenium Hub dans Golang, qui, combinée à des images Docker légères pour divers navigateurs, a donné une impulsion au développement de l'automatisation des tests. De plus, dans le cas de Selenium Grid, nous devons déterminer à l'avance tous les navigateurs requis et leurs versions, ce qui ne pose pas de problème lorsque l'on travaille avec un seul navigateur. Mais lorsqu'il s'agit de plusieurs navigateurs pris en charge, Selenoid est la solution numéro un grâce à sa fonctionnalité « navigateur à la demande ». Il nous suffit de télécharger au préalable les images nécessaires avec les navigateurs et de mettre à jour le fichier de configuration avec lequel Selenoid interagit. Une fois que Selenoid aura reçu une requête des tests, il lancera automatiquement le conteneur souhaité avec le navigateur souhaité. Une fois le test terminé, Selenoid retirera le conteneur, libérant ainsi des ressources pour les demandes futures. Cette approche élimine complètement le problème bien connu de « dégradation des nœuds » que nous rencontrons souvent dans la grille Selenium.
Mais, hélas, Selenoid n’est toujours pas une solution miracle. Nous avons la fonctionnalité « navigateur à la demande », mais la fonctionnalité « ressources à la demande » n'est toujours pas disponible. Pour utiliser Selenoid, il faut le déployer sur du matériel physique ou sur une VM, ce qui signifie qu'il faut savoir à l'avance combien de ressources doivent être allouées. Je suppose que ce n'est pas un problème pour les petits projets qui exécutent 10, 20 ou même 30 navigateurs en parallèle. Mais que se passe-t-il si nous avons besoin de 100, 500, 1000 5 et plus ? Cela n’a aucun sens d’entretenir et de payer autant de ressources en permanence. Dans les sections 6 et XNUMX de cet article, nous aborderons les solutions qui vous permettent d'évoluer, réduisant ainsi considérablement les coûts de l'entreprise.
Sélénoïde pour Android
Après le succès de Selenoid en tant qu'outil d'automatisation Web, les gens voulaient quelque chose de similaire pour Android. Et c'est arrivé : Selenoid est sorti avec le support Android. Du point de vue d'un utilisateur de haut niveau, le principe de fonctionnement est similaire à l'automatisation du Web. La seule différence est qu'au lieu de conteneurs de navigateur, Selenoid exécute des conteneurs d'émulateur Android. À mon avis, il s’agit actuellement de l’outil gratuit le plus puissant pour exécuter des tests Android en parallèle.
Je n'aimerais vraiment pas parler des aspects négatifs de cet outil, car je l'aime vraiment beaucoup. Mais il existe néanmoins les mêmes inconvénients qui s’appliquent à l’automatisation du Web et sont associés à la mise à l’échelle. En plus de cela, nous devons parler d'une autre limitation qui peut surprendre si nous configurons l'outil pour la première fois. Pour exécuter des images Android, nous avons besoin d'une machine physique ou d'une VM avec prise en charge de la virtualisation imbriquée. Dans le guide pratique, je montre comment activer cela sur une machine virtuelle Linux. Cependant, si vous êtes un utilisateur macOS et que vous souhaitez déployer Selenoid localement, il ne sera pas possible d'exécuter des tests Android. Mais vous pouvez toujours exécuter une machine virtuelle Linux localement avec une « virtualisation imbriquée » configurée et déployer Selenoid à l'intérieur.
Illustration de l’état actuel des infrastructures
Dans le cadre de cet article, nous ajouterons 2 outils pour illustrer l’infrastructure. Il s'agit de la grille Selenium pour les tests Web et de Selenoid pour les tests Android. Dans le didacticiel GitHub, je vais également vous montrer comment utiliser Selenoid pour exécuter des tests Web.
Liens à découvrir
Outils similaires
- Il existe d'autres outils de conteneurisation, mais Docker est le plus populaire. Si vous souhaitez essayer autre chose, gardez à l'esprit que les outils que nous avons abordés pour exécuter des tests Selenium en parallèle ne fonctionneront pas immédiatement.
- Comme déjà dit, il existe de nombreuses modifications de la grille Selenium, par exemple :.
4.CI/CD
Brève description de la technologie
La pratique de l'intégration continue est très populaire dans le développement et est comparable aux systèmes de contrôle de version. Malgré cela, j’ai l’impression qu’il y a une confusion dans la terminologie. Dans ce paragraphe, je voudrais décrire 3 modifications de cette technologie de mon point de vue. Sur Internet, vous trouverez de nombreux articles avec des interprétations différentes, et il est tout à fait normal que votre opinion diffère. Le plus important est que vous soyez sur la même longueur d’onde avec vos collègues.
Il existe donc 3 termes : CI - Intégration Continue, CD - Livraison Continue et encore CD - Déploiement Continu. (Ci-dessous, j'utiliserai ces termes en anglais). Chaque modification ajoute plusieurs étapes supplémentaires à votre pipeline de développement. Mais le mot continu (continu) est la chose la plus importante. Dans ce contexte, nous entendons quelque chose qui se passe du début à la fin, sans interruption ni intervention manuelle. Regardons CI & CD et CD dans ce contexte.
- Intégration continue c'est la première étape de l'évolution. Après avoir soumis le nouveau code au serveur, nous nous attendons à recevoir un retour rapide indiquant que nos modifications sont correctes. Généralement, CI inclut l’exécution d’outils d’analyse de code statique et de tests API unitaires/internes. Cela nous permet d’obtenir des informations sur notre code en quelques secondes/minutes.
- Livraison continu est une étape plus avancée où nous exécutons des tests d'intégration/interface utilisateur. Cependant, à ce stade, nous n’obtenons pas de résultats aussi rapidement qu’avec l’IC. Premièrement, ces types de tests prennent plus de temps à être réalisés. Deuxièmement, avant le lancement, nous devons déployer nos modifications dans l'environnement de test/staging. De plus, si nous parlons de développement mobile, alors une étape supplémentaire apparaît pour créer une build de notre application.
- Déploiement continu suppose que nous publions automatiquement nos modifications en production si tous les tests d'acceptation ont été réussis lors des étapes précédentes. De plus, après la phase de publication, vous pouvez configurer différentes étapes, telles que l'exécution de tests de fumée en production et la collecte de métriques intéressantes. Le déploiement continu n'est possible qu'avec une bonne couverture par des tests automatisés. Si des interventions manuelles sont nécessaires, y compris des tests, cela n'est plus le cas. Cyber reconnaissance (continu). Nous pouvons alors dire que notre pipeline est conforme uniquement à la pratique de la Livraison Continue.
Valeur pour l'infrastructure d'automatisation
Dans cette section, je dois préciser que lorsque nous parlons de tests d'interface utilisateur de bout en bout, cela signifie que nous devons déployer nos modifications et les services associés pour tester les environnements. Intégration continue - le processus n'est pas applicable à cette tâche et nous devons veiller à mettre en œuvre au moins des pratiques de livraison continue. Le déploiement continu a également du sens dans le contexte des tests d'interface utilisateur si nous voulons les exécuter en production.
Et avant d'examiner l'illustration du changement d'architecture, je voudrais dire quelques mots sur GitLab CI. Contrairement à d'autres outils CI/CD, GitLab fournit un référentiel distant et de nombreuses autres fonctionnalités supplémentaires. Ainsi, GitLab est plus que CI. Il comprend la gestion du code source, la gestion Agile, les pipelines CI/CD, les outils de journalisation et la collecte de métriques prêtes à l'emploi. L'architecture GitLab se compose de Gitlab CI/CD et GitLab Runner. Voici une brève description du site officiel :
Gitlab CI/CD est une application web avec une API qui stocke son état dans une base de données, gère les projets/builds et fournit une interface utilisateur. GitLab Runner est une application qui traite les builds. Il peut être déployé séparément et fonctionne avec GitLab CI/CD via une API. Pour les tests en cours d'exécution, vous avez besoin à la fois d'une instance Gitlab et de Runner.
Illustration de l’état actuel des infrastructures
Liens à découvrir
Outils similaires
- Et plein d'autres
5. Plateformes cloud
Brève description de la technologie
Dans cette section, nous parlerons d'une tendance populaire appelée « clouds publics ». Malgré les énormes avantages qu'offrent les technologies de virtualisation et de conteneurisation décrites ci-dessus, nous avons toujours besoin de ressources informatiques. Les entreprises achètent des serveurs coûteux ou louent des centres de données, mais dans ce cas, il est nécessaire de faire des calculs (parfois irréalistes) de la quantité de ressources dont nous aurons besoin, si nous les utiliserons 24h/7 et XNUMXj/XNUMX et à quelles fins. Par exemple, la production nécessite un serveur fonctionnant XNUMXh/XNUMX et XNUMXj/XNUMX, mais avons-nous besoin de ressources similaires pour les tests en dehors des heures de travail ? Cela dépend également du type de test effectué. Un exemple serait les tests de charge/stress que nous prévoyons d’effectuer en dehors des heures de travail afin d’obtenir des résultats le lendemain. Mais la disponibilité du serveur XNUMXh/XNUMX et XNUMXj/XNUMX n'est certainement pas requise pour les tests automatisés de bout en bout et surtout pas pour les environnements de tests manuels. Dans de telles situations, il serait bon d’obtenir autant de ressources que nécessaire sur demande, de les utiliser et d’arrêter de payer lorsqu’elles ne sont plus nécessaires. De plus, ce serait formidable de les recevoir instantanément en effectuant quelques clics de souris ou en exécutant quelques scripts. C’est à cela que servent les cloud publics. Regardons la définition :
« Le cloud public est défini comme des services informatiques proposés par des fournisseurs tiers sur l'Internet public, les mettant à la disposition de toute personne souhaitant les utiliser ou les acheter. Ils peuvent être gratuits ou vendus à la demande, permettant aux clients de payer uniquement par utilisation pour les cycles CPU, le stockage ou la bande passante qu'ils consomment. »
Il existe une opinion selon laquelle les nuages publics coûtent cher. Mais leur idée maîtresse est de réduire les coûts de l’entreprise. Comme mentionné précédemment, les cloud publics vous permettent d'obtenir des ressources à la demande et de ne payer que pour le temps que vous les utilisez. De plus, nous oublions parfois que les employés reçoivent des salaires et que les spécialistes constituent également une ressource coûteuse. Il faut tenir compte du fait que les cloud publics facilitent grandement le support des infrastructures, ce qui permet aux ingénieurs de se concentrer sur des tâches plus importantes.
Valeur pour l'infrastructure d'automatisation
De quelles ressources spécifiques avons-nous besoin pour les tests d’interface utilisateur de bout en bout ? Il s'agit essentiellement de machines virtuelles ou de clusters (nous parlerons de Kubernetes dans la section suivante) permettant d'exécuter des navigateurs et des émulateurs. Plus nous souhaitons exécuter simultanément de navigateurs et d’émulateurs, plus nous avons besoin de CPU et de mémoire et plus nous devons payer pour cela. Ainsi, les cloud publics dans le contexte de l'automatisation des tests nous permettent d'exécuter un grand nombre (100, 200, 1000...) de navigateurs/émulateurs à la demande, d'obtenir les résultats des tests le plus rapidement possible et de ne plus payer pour des applications incroyablement gourmandes en ressources. pouvoir.
Les fournisseurs de cloud les plus populaires sont Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP). Le guide pratique fournit des exemples d'utilisation de GCP, mais en général, peu importe ce que vous utilisez pour les tâches d'automatisation. Ils offrent tous à peu près les mêmes fonctionnalités. En règle générale, pour sélectionner un fournisseur, la direction se concentre sur l'ensemble de l'infrastructure et des exigences commerciales de l'entreprise, ce qui dépasse le cadre de cet article. Pour les ingénieurs automation, il sera plus intéressant de comparer l’utilisation de fournisseurs cloud avec l’utilisation de plateformes cloud spécifiquement à des fins de tests, comme Sauce Labs, BrowserStack, BitBar, etc. Alors faisons-le aussi ! À mon avis, Sauce Labs est la ferme de tests cloud la plus connue, c'est pourquoi je l'ai utilisée à titre de comparaison.
GCP vs Sauce Labs à des fins d'automatisation :
Imaginons que nous devions exécuter simultanément 8 tests Web et 8 tests Android. Pour cela, nous utiliserons GCP et exécuterons 2 machines virtuelles avec Selenoid. Sur le premier, nous élèverons 8 conteneurs avec des navigateurs. Sur le second il y a 8 conteneurs avec émulateurs. Jetons un coup d'œil aux prix :
Pour exécuter un conteneur avec Chrome, nous avons besoin n1-standard-1 voiture. Dans le cas d'Android, ce sera n1-standard-4 pour un émulateur. En fait, un moyen plus flexible et moins coûteux consiste à définir des valeurs utilisateur spécifiques pour le processeur/la mémoire, mais pour le moment, cela n'est pas important pour la comparaison avec Sauce Labs.
Et voici les tarifs d'utilisation de Sauce Labs :
Je pense que vous avez déjà remarqué la différence, mais je vais quand même vous fournir un tableau avec des calculs pour notre tâche :
Les ressources requises
Mensuel
Heure d'ouverture(8h - 8h)
Heure d'ouverture+ Préemptif
GCP pour le Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 jours * 12h * 0.38 = 104.88$
23 jours * 12h * 0.08 = 22.08$
Laboratoires de sauces pour le Web
Tests parallèles du Cloud8 virtuel
$1.559
-
-
GCP pour Android
n1-standard-4 x 8 : n1-standard-16
$776.72
23 jours * 12h * 1.52 = 419.52$
23 jours * 12h * 0.32 = 88.32$
Laboratoires de sauce pour Android
Tests parallèles Real Device Cloud 8
$1.999
-
-
Comme vous pouvez le constater, la différence de coût est énorme, surtout si vous effectuez des tests uniquement sur une période de travail de douze heures. Mais vous pouvez réduire encore davantage les coûts si vous utilisez des machines préemptives. Qu'est-ce que c'est?
Une VM préemptive est une instance que vous pouvez créer et exécuter à un prix bien inférieur à celui des instances normales. Toutefois, Compute Engine peut mettre fin (préempter) à ces instances s'il a besoin d'accéder à ces ressources pour d'autres tâches. Les instances préemptives représentent une capacité excédentaire de Compute Engine. Leur disponibilité varie donc en fonction de leur utilisation.
Si vos applications sont tolérantes aux pannes et peuvent résister à d'éventuelles préemptions d'instance, les instances préemptives peuvent réduire considérablement vos coûts Compute Engine. Par exemple, les tâches de traitement par lots peuvent s'exécuter sur des instances préemptives. Si certaines de ces instances se terminent pendant le traitement, la tâche ralentit mais ne s'arrête pas complètement. Les instances préemptives effectuent vos tâches de traitement par lots sans imposer de charge de travail supplémentaire à vos instances existantes et sans vous obliger à payer le prix fort pour des instances normales supplémentaires.
Et ce n'est toujours pas fini ! En réalité, je suis sûr que personne n'effectue des tests pendant 12 heures sans interruption. Et si tel est le cas, vous pouvez démarrer et arrêter automatiquement les machines virtuelles lorsqu’elles ne sont pas nécessaires. La durée d'utilisation réelle peut être réduite à 6 heures par jour. Ensuite, le paiement dans le cadre de notre tâche diminuera à 11$ par mois pour 8 navigateurs. N'est-ce pas merveilleux ? Mais avec les machines préemptives, nous devons être prudents et préparés aux interruptions et à l'instabilité, même si ces situations peuvent être prévues et gérées par logiciel. Ça en vaut la peine!
Mais je ne dis en aucun cas « ne jamais utiliser de fermes de test cloud ». Ils présentent de nombreux avantages. Tout d'abord, il ne s'agit pas simplement d'une machine virtuelle, mais d'une solution d'automatisation de tests à part entière avec un ensemble de fonctionnalités prêtes à l'emploi : accès à distance, journaux, captures d'écran, enregistrement vidéo, divers navigateurs et appareils mobiles physiques. Dans de nombreuses situations, cela peut être une alternative chic incontournable. Les plates-formes de test sont particulièrement utiles pour l'automatisation IOS, lorsque les cloud publics ne peuvent proposer que des systèmes Linux/Windows. Mais nous parlerons d'iOS dans les articles suivants. Je recommande de toujours regarder la situation et de partir des tâches : dans certains cas, il est moins cher et plus efficace d'utiliser les cloud publics, et dans d'autres, les plates-formes de test valent vraiment l'argent dépensé.
Illustration de l’état actuel des infrastructures
Liens à découvrir
Outils similaires :
6. Orchestration
Brève description de la technologie
J’ai une bonne nouvelle – nous sommes presque à la fin de l’article ! À l'heure actuelle, notre infrastructure d'automatisation se compose de tests Web et Android, que nous exécutons en parallèle via GitLab CI, à l'aide d'outils compatibles Docker : Selenium Grid et Selenoid. De plus, nous utilisons des machines virtuelles créées via GCP pour héberger des conteneurs avec des navigateurs et des émulateurs. Pour réduire les coûts, nous démarrons ces machines virtuelles uniquement à la demande et les arrêtons lorsque les tests ne sont pas effectués. Y a-t-il autre chose qui pourrait améliorer notre infrastructure ? La réponse est oui! Rencontrez Kubernetes (K8s) !
Voyons d’abord comment les mots orchestration, cluster et Kubernetes sont liés les uns aux autres. À un niveau élevé, l'orchestration est le système qui déploie et gère les applications. Pour l’automatisation des tests, ces applications conteneurisées sont Selenium Grid et Selenoid. Docker et K8 se complètent. Le premier est utilisé pour le déploiement d’applications, le second pour l’orchestration. À son tour, K8s est un cluster. La tâche du cluster est d'utiliser les machines virtuelles comme nœuds, ce qui vous permet d'installer diverses fonctionnalités, programmes et services au sein d'un seul serveur (cluster). Si l'un des nœuds tombe en panne, d'autres nœuds reprendront, ce qui garantit un fonctionnement ininterrompu de notre application. En plus de cela, K8s possède des fonctionnalités importantes liées à la mise à l'échelle, grâce auxquelles nous obtenons automatiquement la quantité optimale de ressources en fonction de la charge et des limites fixées.
En vérité, déployer manuellement Kubernetes à partir de zéro n’est pas du tout une tâche triviale. Je vous laisse un lien vers le fameux guide pratique "Kubernetes The Hard Way" et si vous êtes intéressé, vous pouvez le pratiquer. Mais heureusement, il existe des méthodes et des outils alternatifs. Le moyen le plus simple est d'utiliser Google Kubernetes Engine (GKE) dans GCP, ce qui vous permettra d'obtenir un cluster prêt à l'emploi en quelques clics. Je recommande d'utiliser cette approche pour commencer l'apprentissage, car elle vous permettra de vous concentrer sur l'apprentissage de l'utilisation des K8 pour vos tâches au lieu d'apprendre comment les composants internes doivent être intégrés les uns aux autres.
Valeur pour l'infrastructure d'automatisation
Jetons un coup d'œil à quelques fonctionnalités importantes fournies par le K8 :
- déploiement d'applications : utilisation d'un cluster multi-nœuds au lieu de VM ;
- mise à l'échelle dynamique : réduit le coût des ressources utilisées uniquement à la demande ;
- auto-guérison : récupération automatique des pods (à la suite de laquelle les conteneurs sont également restaurés) ;
- déploiement des mises à jour et annulation des modifications sans temps d'arrêt : la mise à jour des outils, des navigateurs et des émulateurs n'interrompt pas le travail des utilisateurs actuels
Mais le K8 n’est toujours pas une solution miracle. Pour comprendre tous les avantages et limites dans le contexte des outils que nous envisageons (Selenium grid, Selenoid), nous aborderons brièvement la structure des K8. Le cluster contient deux types de nœuds : les nœuds principaux et les nœuds de travail. Les nœuds maîtres sont responsables des décisions de gestion, de déploiement et de planification. Les nœuds de travail sont l'endroit où les applications sont exécutées. Les nœuds contiennent également un environnement d'exécution de conteneur. Dans notre cas, il s'agit de Docker, qui est responsable des opérations liées aux conteneurs. Mais il existe aussi des solutions alternatives, par exemple. Il est important de comprendre que la mise à l’échelle ou l’auto-réparation ne s’applique pas directement aux conteneurs. Ceci est mis en œuvre en ajoutant/diminuant le nombre de pods, qui à leur tour contiennent des conteneurs (généralement un conteneur par pod, mais selon la tâche, il peut y en avoir plus). La hiérarchie de haut niveau se compose de nœuds de travail, à l'intérieur desquels se trouvent des pods, à l'intérieur desquels des conteneurs sont élevés.
La fonctionnalité de mise à l'échelle est essentielle et peut être appliquée à la fois aux nœuds d'un pool de nœuds de cluster et aux pods d'un nœud. Il existe 2 types de mise à l'échelle qui s'appliquent à la fois aux nœuds et aux pods. Le premier type est horizontal : la mise à l’échelle se produit en augmentant le nombre de nœuds/pods. Ce type est plus préférable. Le deuxième type est donc vertical. La mise à l'échelle s'effectue en augmentant la taille des nœuds/pods, et non leur nombre.
Examinons maintenant nos outils dans le contexte des termes ci-dessus.
Grille de sélénium
Comme mentionné précédemment, Selenium Grid est un outil très populaire et il n’est pas surprenant qu’il ait été conteneurisé. Il n’est donc pas surprenant que la grille Selenium puisse être déployée dans les K8. Un exemple de la façon de procéder peut être trouvé dans le référentiel officiel K8s. Comme d'habitude, je joins des liens à la fin de la section. De plus, le guide pratique montre comment procéder dans Terraform. Il existe également des instructions sur la manière d'augmenter le nombre de pods contenant des conteneurs de navigateur. Mais la fonction de mise à l'échelle automatique dans le contexte des K8 n'est pas encore une tâche tout à fait évidente. Lorsque j’ai commencé mes études, je n’ai trouvé aucune orientation ou recommandation pratique. Après plusieurs études et expériences avec le soutien de l'équipe DevOps, nous avons choisi l'approche consistant à créer des conteneurs avec les navigateurs nécessaires dans un seul pod, situé à l'intérieur d'un nœud de travail. Cette méthode nous permet d'appliquer la stratégie de mise à l'échelle horizontale des nœuds en augmentant leur nombre. J'espère que cela changera à l'avenir et que nous verrons de plus en plus de descriptions de meilleures approches et de solutions toutes faites, surtout après la sortie de Selenium Grid 4 avec une architecture interne modifiée.
Sélénoïde:
Le déploiement de Selenoid dans les K8 est actuellement la plus grande déception. Ils ne sont pas compatibles. En théorie, nous pouvons créer un conteneur Selenoid à l'intérieur d'un pod, mais lorsque Selenoid commencera à lancer des conteneurs avec des navigateurs, ils seront toujours dans le même pod. Cela rend la mise à l'échelle impossible et, par conséquent, le travail de Selenoid à l'intérieur d'un cluster ne différera pas du travail à l'intérieur d'une machine virtuelle. Fin de l'histoire.
Lune:
Connaissant ce goulot d'étranglement lorsqu'ils travaillent avec Selenoid, les développeurs ont publié un outil plus puissant appelé Moon. Cet outil a été initialement conçu pour fonctionner avec Kubernetes et, par conséquent, la fonction de mise à l'échelle automatique peut et doit être utilisée. D'ailleurs, je dirais qu'en ce moment c'est seulement un outil dans le monde Selenium, qui prend en charge le cluster K8 natif dès le départ (n'est plus disponible, voir l'outil suivant ). Les principales fonctionnalités de Moon qui fournissent ce support sont :
Complètement apatride. Selenoid stocke en mémoire des informations sur les sessions de navigateur en cours d'exécution. Si, pour une raison quelconque, son processus plante, toutes les sessions en cours sont perdues. Au contraire, Moon n’a pas d’état interne et peut être répliqué dans les centres de données. Les sessions du navigateur restent actives même si une ou plusieurs répliques tombent en panne.
Moon est donc une excellente solution, mais il y a un problème : ce n’est pas gratuit. Le prix dépend du nombre de séances. Vous ne pouvez exécuter que 0 à 4 sessions gratuitement, ce qui n'est pas particulièrement utile. Mais, à partir de la cinquième séance, vous devrez débourser 5$ chacune. La situation peut différer d’une entreprise à l’autre, mais dans notre cas, utiliser Moon est inutile. Comme je l'ai décrit ci-dessus, nous pouvons exécuter des machines virtuelles avec Selenium Grid à la demande ou augmenter le nombre de nœuds dans le cluster. Pour environ un pipeline, nous lançons 500 navigateurs et arrêtons toutes les ressources une fois les tests terminés. Si nous utilisions Moon, nous devrions payer 500 x 5 = 2500 XNUMX $ supplémentaires par mois, quelle que soit la fréquence à laquelle nous effectuons des tests. Encore une fois, je ne dis pas de ne pas utiliser Moon. Pour vos tâches, cela peut être une solution indispensable, par exemple si vous avez de nombreux projets/équipes dans votre organisation et que vous avez besoin d'un énorme cluster commun pour tout le monde. Comme toujours, je laisse un lien à la fin et vous recommande de faire tous les calculs nécessaires dans le cadre de votre tâche.
Callisto: (Attention! Ceci ne figure pas dans l'article original et n'est contenu que dans la traduction russe.)
Comme je l'ai dit, Selenium est un outil très populaire et le domaine informatique se développe très rapidement. Pendant que je travaillais sur la traduction, un nouvel outil prometteur appelé Callisto est apparu sur le web (bonjour Cypress et autres tueurs de Selenium). Il fonctionne nativement avec les K8 et vous permet d'exécuter des conteneurs Selenoid dans des pods, répartis sur plusieurs nœuds. Tout fonctionne immédiatement, y compris la mise à l'échelle automatique. Fantastique, mais doit être testé. J'ai déjà réussi à déployer cet outil et à mener plusieurs expériences. Mais il est trop tôt pour tirer des conclusions, après avoir reçu des résultats sur une longue distance, j'en ferai peut-être une revue dans de prochains articles. Pour l’instant, je ne laisse que des liens pour des recherches indépendantes.
Illustration de l’état actuel des infrastructures
Liens à découvrir
Outils similaires
7. Infrastructure en tant que code (IaC)
Brève description de la technologie
Et maintenant nous arrivons à la dernière section. En règle générale, cette technologie et les tâches associées ne relèvent pas de la responsabilité des ingénieurs en automatisation. Et il y a des raisons à cela. Premièrement, dans de nombreuses organisations, les problèmes d'infrastructure sont sous le contrôle du département DevOps et les équipes de développement ne se soucient pas vraiment de ce qui fait fonctionner le pipeline et de la manière dont tout ce qui y est lié doit être pris en charge. Deuxièmement, soyons honnêtes, la pratique de l'Infrastructure as Code (IaC) n'est toujours pas adoptée dans de nombreuses entreprises. Mais c’est définitivement devenu une tendance populaire et il est important d’essayer de s’impliquer dans les processus, approches et outils qui y sont associés. Ou du moins restez à jour.
Commençons par la motivation pour utiliser cette approche. Nous avons déjà expliqué que pour exécuter des tests dans GitlabCI, nous aurons besoin au minimum des ressources nécessaires pour exécuter Gitlab Runner. Et pour exécuter des conteneurs avec des navigateurs/émulateurs, nous devons réserver une VM ou un cluster. En plus des ressources de test, nous avons besoin d'une capacité importante pour prendre en charge les environnements de développement, de préparation et de production, qui comprennent également des bases de données, des planifications automatiques, des configurations réseau, des équilibreurs de charge, des droits d'utilisateur, etc. La question clé est l’effort requis pour soutenir tout cela. Il existe plusieurs façons d'apporter des modifications et de déployer des mises à jour. Par exemple, dans le contexte de GCP, nous pouvons utiliser la console UI dans le navigateur et effectuer toutes les actions en cliquant sur des boutons. Une alternative serait d'utiliser des appels API pour interagir avec les entités cloud, ou d'utiliser l'utilitaire de ligne de commande gcloud pour effectuer les manipulations souhaitées. Mais avec un très grand nombre d’entités et d’éléments d’infrastructure différents, il devient difficile, voire impossible, d’effectuer toutes les opérations manuellement. De plus, toutes ces actions manuelles sont incontrôlables. Nous ne pouvons pas les soumettre pour examen avant exécution, utiliser un système de contrôle de version et annuler rapidement les modifications qui ont conduit à l'incident. Pour résoudre de tels problèmes, les ingénieurs ont créé et créé des scripts bash/shell automatiques, qui ne sont guère meilleurs que les méthodes précédentes, car ils ne sont pas si faciles à lire, comprendre, maintenir et modifier rapidement dans un style procédural.
Dans cet article et ce guide pratique, j'utilise 2 outils liés à la pratique IaC. Ce sont Terraform et Ansible. Certaines personnes pensent que cela n’a aucun sens de les utiliser en même temps, car leurs fonctionnalités sont similaires et interchangeables. Mais le fait est qu’au départ, on leur confie des tâches complètement différentes. Et le fait que ces outils doivent se compléter a été confirmé lors d'une présentation conjointe des développeurs représentant HashiCorp et RedHat. La différence conceptuelle est que Terraform est un outil de provisionnement permettant de gérer les serveurs eux-mêmes. Tandis qu'Ansible est un outil de gestion de configuration dont la tâche est d'installer, de configurer et de gérer des logiciels sur ces serveurs.
Une autre caractéristique distinctive de ces outils est le style de codage. Contrairement à bash et Ansible, Terraform utilise un style déclaratif basé sur une description de l'état final souhaité à atteindre à la suite de l'exécution. Par exemple, si nous allons créer 10 VM et appliquer les modifications via Terraform, nous obtiendrons 10 VM. Si nous exécutons à nouveau le script, rien ne se passera puisque nous avons déjà 10 VM, et Terraform le sait car il stocke l'état actuel de l'infrastructure dans un fichier d'état. Mais Ansible utilise une approche procédurale et, si vous lui demandez de créer 10 VM, alors au premier lancement, nous obtiendrons 10 VM, similaires à Terraform. Mais après le redémarrage, nous aurons déjà 20 VM. C'est la différence importante. Dans le style procédural, nous ne stockons pas l'état actuel et décrivons simplement une séquence d'étapes qui doivent être effectuées. Bien sûr, nous pouvons gérer diverses situations, ajouter plusieurs contrôles sur l'existence des ressources et l'état actuel, mais cela ne sert à rien de perdre notre temps et de faire des efforts pour contrôler cette logique. De plus, cela augmente le risque de commettre des erreurs.
En résumant tout ce qui précède, nous pouvons conclure que Terraform et la notation déclarative sont un outil plus approprié pour l'approvisionnement des serveurs. Mais il vaut mieux déléguer le travail de gestion de la configuration à Ansible. Cela étant dit, examinons les cas d'utilisation dans le contexte de l'automatisation.
Valeur pour l'infrastructure d'automatisation
La seule chose importante à comprendre ici est que l’infrastructure d’automatisation des tests doit être considérée comme faisant partie de l’ensemble de l’infrastructure de l’entreprise. Cela signifie que toutes les pratiques IaC doivent être appliquées globalement aux ressources de l’ensemble de l’organisation. La responsabilité de cela dépend de vos processus. L'équipe DevOps est plus expérimentée sur ces questions, elle a une vue d'ensemble de ce qui se passe. Cependant, les ingénieurs QA sont davantage impliqués dans le processus d’automatisation du bâtiment et dans la structure du pipeline, ce qui leur permet de mieux voir tous les changements requis et les opportunités d’amélioration. La meilleure option est de travailler ensemble, d’échanger des connaissances et des idées pour atteindre le résultat escompté.
Voici quelques exemples d'utilisation de Terraform et Ansible dans le contexte de l'automatisation des tests et des outils dont nous avons parlé précédemment :
1. Décrivez les caractéristiques et les paramètres nécessaires des VM et des clusters à l'aide de Terraform.
2. A l'aide d'Ansible, installez les outils nécessaires aux tests : docker, Selenoid, Selenium Grid et téléchargez les versions requises des navigateurs/émulateurs.
3. À l'aide de Terraform, décrivez les caractéristiques de la VM dans laquelle GitLab Runner sera lancé.
4. Installez GitLab Runner et les outils d'accompagnement nécessaires à l'aide d'Ansible, définissez les paramètres et les configurations.
Illustration de l’état actuel des infrastructures
Liens à découvrir :
Outils similaires
Résumons-le !
étapes
Technologie
Outils
Valeur pour l'infrastructure d'automatisation
1
Fonctionnement local
Node.js, Sélénium, Appium
- Les outils les plus populaires pour le Web et le mobile
- Prend en charge de nombreux langages et plateformes (y compris Node.js)
2
Systèmes de contrôle de version
Git
- Avantages similaires avec le code de développement
3
Conteneurisation
Docker, grille Selenium, Selenoid (Web, Android)
- Exécuter des tests en parallèle
- Environnements isolés
- Mises à niveau de version simples et flexibles
- Arrêter dynamiquement les ressources inutilisées
- Facile à installer
4
CI/CD
CI Gitlab
- Teste une partie du pipeline
- Commentaires rapides
- Visibilité pour toute l'entreprise/l'équipe
5
Plateformes cloud
Google Cloud Platform
- Ressources sur demande (nous payons uniquement en cas de besoin)
- Facile à gérer et à mettre à jour
- Visibilité et contrôle de toutes les ressources
6
Orchestration
Kubernetes
Dans le cadre de conteneurs avec navigateurs/émulateurs à l'intérieur de pods :
- Mise à l'échelle/mise à l'échelle automatique
- Auto-guérison
- Mises à jour et restaurations sans interruption
7
Infrastructure en tant que code (IaC)
Terraforme, Ansible
- Avantages similaires avec l’infrastructure de développement
- Tous les avantages du versioning de code
- Facile à apporter des modifications et à entretenir
- Entièrement automatisé
Diagrammes de cartes mentales : évolution de l'infrastructure
étape 1 : locale
étape 2 : VCS
étape 3 : conteneurisation
étape 4 : CI/CD
étape 5 : Plateformes cloud
étape 6 : Orchestration
étape 7 : IaC
Quelle est la prochaine?
Voilà, c'est la fin de l'article. Mais en conclusion, je voudrais établir quelques accords avec vous.
De ton côté
Comme je l'ai dit au début, j'aimerais que l'article soit d'une utilité pratique et vous aide à appliquer les connaissances acquises dans un travail réel. j'ajoute encore.
Mais même après cela, ne vous arrêtez pas, entraînez-vous, étudiez les liens et les livres pertinents, découvrez comment cela fonctionne dans votre entreprise, trouvez les endroits qui peuvent être améliorés et participez-y. Bonne chance!
De mon côté
D'après le titre, vous pouvez voir que ce n'était que la première partie. Malgré le fait qu'il s'est avéré assez vaste, des sujets importants ne sont toujours pas abordés ici. Dans la deuxième partie, je prévois d'examiner l'infrastructure d'automatisation dans le contexte d'IOS. En raison des restrictions d'Apple concernant l'exécution de simulateurs iOS uniquement sur les systèmes macOS, notre gamme de solutions est restreinte. Par exemple, nous ne pouvons pas utiliser Docker pour exécuter le simulateur ou des cloud publics pour exécuter des machines virtuelles. Mais cela ne veut pas dire qu’il n’existe pas d’autres alternatives. J'essaierai de vous tenir au courant des solutions avancées et des outils modernes !
De plus, je n'ai pas mentionné de sujets assez importants liés à la surveillance. Dans la troisième partie, je vais examiner les outils de surveillance des infrastructures les plus populaires et les données et mesures à prendre en compte.
Et enfin. À l'avenir, je prévois de publier un cours vidéo sur la création d'une infrastructure de test et d'outils populaires. Actuellement, il existe de nombreux cours et conférences sur DevOps sur Internet, mais tous les documents sont présentés dans le contexte du développement et non de l'automatisation des tests. Sur cette question, j'ai vraiment besoin de retours pour savoir si un tel cours sera intéressant et utile pour la communauté des testeurs et des automatistes. Merci d'avance!
Source: habr.com