Les outils DevOps ne sont pas uniquement destinés aux DevOps. Le processus de construction d'une infrastructure d'automatisation de test à partir de zéro

Partie 1: Web / Android


Remarque : cet article est une traduction en russe de l'article original  «Les outils DevOps ne sont pas seulement pour DevOps. Construire une infrastructure d'automatisation des tests à partir de zéro. " Cependant, toutes les illustrations, liens, citations et termes sont stockés dans la langue d'origine pour éviter toute distorsion de sens lorsqu'ils sont traduits en russe. Je vous souhaite une agréable étude!



Actuellement, la spécialité DevOps est l'une des plus populaires de l'industrie informatique. Si vous ouvrez des sites de recherche d'emploi populaires et définissez un filtre de salaire, vous verrez que les emplois liés à DevOps sont en haut de la liste. Cependant, il est important de comprendre que cela se réfère principalement au poste de «senior», ce qui implique que le candidat possède un haut niveau de compétences, une connaissance des technologies et des outils. Il s'accompagne également d'un degré élevé de responsabilité associé au bon fonctionnement de la production. Cependant, nous avons commencé à oublier ce qu'est DevOps. Au départ, ce n'était pas une personne ou un service spécifique. Si nous recherchons les 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 QA, mais je pense que cela ne devrait pas être uniquement lié à l'écriture d'autotests ou au développement d'une architecture pour un framework de test. En 2020, la connaissance des infrastructures d'automatisation est également nécessaire. Cela vous permet d'organiser vous-même le processus d'automatisation, du lancement des tests à la fourniture des résultats à toutes les parties intéressées conformément aux objectifs. En conséquence, les compétences DevOps sont un must pour ce travail. Et tout cela est bien, mais, malheureusement, il y a un problème ( spoiler: cet article tente de simplifier ce problème) Cela réside dans le fait que DevOps est compliqué. Et cela est évident, car les entreprises ne paieront pas cher pour ce qui est facile à faire ... Dans le monde de DevOps, il existe un grand nombre d'outils, de termes, de pratiques qui doivent être maîtrisés. Ceci est particulièrement difficile en début de carrière et dépend de l'expérience technique accumulée.


Source: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

Ici, nous compléterons probablement la partie introductive et nous concentrerons sur l'objectif de cet article. 

De quoi parle l'article


Dans cet article, je vais partager mon expérience dans la construction d'une infrastructure d'automatisation des tests. Sur Internet, vous pouvez trouver de nombreuses sources d'informations sur divers outils et comment les utiliser, mais je voudrais les considérer exclusivement dans le contexte de l'automatisation. Je pense que de nombreux ingénieurs en automatisation connaissent une situation dans laquelle personne n'exécute les tests développés, à part vous-même, et ne se soucie pas de leur assistance. 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 être une tâche assez difficile: décider correctement quels outils devraient aider à résoudre ce problème, comment les choisir, les configurer et les entretenir. Certains testeurs demandent l'aide de DevOps (personnes) et, pour être honnête, cette approche fonctionne.Dans de nombreux cas, cela peut être la seule option, car nous n'avons pas la visibilité de toutes les dépendances. Mais, comme nous le savons, les DevOps sont des gens très occupés, car ils devraient penser à l'infrastructure de toute l'entreprise, au déploiement, à la surveillance, aux microservices et à d'autres tâches similaires selon l'organisation / l'équipe. Comme cela arrive généralement, l'automatisation n'est pas une priorité. Dans ce cas, nous devons essayer de faire de notre mieux 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 image plus large de ce qui se passe.microservices et autres tâches similaires selon l'organisation / l'équipe. Comme cela arrive généralement, l'automatisation n'est pas une priorité. Dans ce cas, nous devons essayer de faire de notre mieux 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 image plus large de ce qui se passe.microservices et autres tâches similaires selon l'organisation / l'équipe. Comme cela arrive généralement, l'automatisation n'est pas une priorité. Dans ce cas, nous devons essayer de faire de notre mieux 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 image plus large de ce qui se passe.

L'article présente les outils les plus populaires et les plus populaires et montre comment les utiliser pour la construction étape par étape de l'infrastructure d'automatisation. Chaque groupe est représenté par des outils testés sur l'expérience personnelle. Mais cela ne signifie pas 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 avons-nous besoin de ce groupe d'outils et quelles tâches de travail pouvons-nous résoudre avec leur aide. Par conséquent, à 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


Encore une fois, l'article ne traite pas d'outils spécifiques, il n'y aura donc pas d'insertions de code dans la documentation et les descriptions de commandes spécifiques. Mais à la fin de chaque section, je laisse des liens pour une étude détaillée.

Cela est dû au fait 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 2-3);
  • Je ne veux tout simplement pas perdre votre temps, car vous voudrez peut-être utiliser d'autres outils pour atteindre les mêmes objectifs.

Entraine toi


J'aimerais vraiment que ce matériel soit utile à tous les lecteurs, et pas seulement lu et oublié. Dans toute étude, la pratique est une composante très importante. Pour ce faire, j'ai préparé un référentiel GitHub avec un guide étape par étape sur la façon de tout faire à partir de zéro . Vous attendez également les devoirs pour vous assurer que vous n'avez pas copié les lignes de commandes exécutées sans réfléchir.

Plan


ÉtapeLa technologieOutils
1Exécution locale (préparez des tests de démonstration Web / Android et exécutez-les localement) Node.js, sélénium, appium
2Systèmes de contrôle de version Git
3ConteneurisationDocker, grille de sélénium, sélénoïde (Web, Android)
4CI / CDGitlab ci
5Plateformes cloudPlateforme cloud Google
6OrchestrationKubernetes
7Infrastructure en tant que code (IaC)Terraform, ansible

La structure de chaque section


Pour maintenir le récit sous une forme visuelle, chaque section est décrite comme suit:

  • ,
  • ,
  • ,
  • ,
  • .

1.



Il s'agit simplement d'une étape préparatoire pour exécuter les tests de démonstration localement et pour vérifier qu'ils réussissent. Dans la partie pratique, Node.js est utilisé, mais le langage de programmation et la plate-forme ne sont pas non plus importants et vous pouvez utiliser ceux qui sont utilisés dans votre entreprise. 

Cependant, en tant qu'outil d'automatisation, je recommande d'utiliser Selenium WebDriver pour les plates-formes Web et Appium pour la plate-forme Android, respectivement, car dans les prochaines étapes, nous utiliserons des images Docker spécifiquement conçues pour fonctionner spécifiquement avec ces outils. De plus, en référence aux exigences des postes vacants, 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 (grâce à Apple). J'ai l'intention de démontrer les solutions et les pratiques liées à iOS dans les parties suivantes.

Valeur pour l'infrastructure d'automatisation


D'un point de vue infrastructure, un lancement local n'a aucune valeur. Vous vérifiez uniquement que les tests s'exécutent sur la machine locale dans les navigateurs et simulateurs locaux. Mais en tout cas, c'est un point de départ nécessaire.

Illustration de l'état actuel des infrastructures




Liens d'apprentissage



Outils similaires


  • tout langage de programmation que vous aimez en conjonction avec Selenium / Appium - tests;
  • tous les tests;
  • tout coureur de test.

2. Systèmes de contrôle de version (Git)


Dossier technologique


Ce ne sera une grande découverte pour personne si je dis que le système de contrôle de version est une partie extrêmement importante du développement à la fois en équipe et individuellement. Sur la base de diverses sources, nous pouvons affirmer avec confiance que Git est le représentant le plus populaire. Le système de contrôle de version offre de nombreux avantages, tels que l'échange de code, le stockage de version, la restauration des branches précédentes, la surveillance de l'historique du projet, les sauvegardes. Nous ne discuterons pas chaque élément en détail, car je suis sûr que vous le connaissez et l'utilisez dans le travail quotidien. Mais si ce n'est pas le cas, je 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 pour le code de développement et le code de test automatique. » Vous aurez parfaitement raison, mais dans cet article, nous parlons d'infrastructure et cette section joue le rôle d'un aperçu de la section 7: «Infrastructure en tant que code (IaC)». Pour nous, cela signifie que toute l'infrastructure, y compris celle de test, est décrite sous forme de code, nous pouvons donc également lui appliquer des systèmes de version et obtenir des avantages similaires pour le 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'apprentissage



Outils similaires



3. Conteneurisation (Docker)


Dossier technologique


Pour montrer comment la conteneurisation a changé les règles du jeu, revenons plusieurs décennies en arrière. À cette époque, les gens achetaient et utilisaient des machines serveurs pour exécuter des applications. Mais dans la plupart des cas, les ressources requises pour le lancement n'étaient pas connues à l'avance. En conséquence, les entreprises ont dépensé de l'argent pour l'achat de serveurs puissants et chers, mais certaines de ces capacités n'ont pas été complètement utilisées.

L'étape suivante de l'évolution a été les machines virtuelles (VM), qui ont résolu le problème de dépenser de l'argent sur des ressources inutilisées. Cette technologie a permis d'exécuter des applications indépendamment les unes des autres sur le même serveur, en allouant un espace complètement isolé. Mais, malheureusement, toute technologie a ses inconvénients. Le démarrage d'une machine virtuelle nécessite un système d'exploitation à part entière qui consomme du processeur, de la RAM, du stockage et, selon le système d'exploitation, vous devez considérer le coût d'une licence. Ces facteurs affectent la vitesse de téléchargement et compliquent la portabilité.

Et nous sommes donc arrivés à la conteneurisation. Et encore une fois, cette technologie a résolu le problème précédent, car les conteneurs n'utilisent pas un système d'exploitation à part entière, ce qui vous permet de libérer un grand nombre de ressources et fournit une solution rapide et flexible pour la portabilité.

Bien sûr, 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, il y avait beaucoup de recherches, de travaux préparatoires et de tentatives. Mais c'est Docker qui a adapté cette technologie et l'a rendue facilement accessible aux masses. De nos jours, lorsque nous parlons de conteneurs, nous entendons dans la plupart des cas Docker. Lorsque nous parlons de conteneurs Docker, nous entendons des 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 un Mac lance silencieusement des conteneurs dans une machine virtuelle Linux légère. Nous reviendrons sur ce sujet lorsque nous discuterons du lancement des émulateurs Android à l'intérieur des conteneurs, et c'est là qu'une nuance très importante apparaît, qui doit être analysée plus en détail.

Valeur pour l'infrastructure d'automatisation


Nous avons découvert que la conteneurisation et Docker sont cool. Examinons cela dans le contexte de l'automatisation, car chaque outil ou technologie devrait résoudre un problème. Notons les problèmes évidents des tests d'automatisation 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 le lancement parallèle;
  • Il est difficile à gérer et à gérer si vous devez exécuter 10, 50, 100 ou même 1 000 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 ne devrait être surprenant pour personne que quelqu'un essaie de les combiner pour obtenir un outil puissant pour résoudre les problèmes 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 de Selenium pour lancer et gérer plusieurs navigateurs sur plusieurs machines à partir d'un site central. Pour commencer, vous devez enregistrer au moins 2 parties: Hub et Node (s). Un hub est un site central qui reçoit toutes les demandes des tests et les distribue aux nœuds appropriés. Pour chaque nœud, nous pouvons configurer une configuration spécifique, par exemple, en spécifiant le navigateur souhaité et sa version. Cependant, nous devons toujours nous occuper des pilotes de navigateur compatibles et les installer sur les nœuds nécessaires. Pour cette raison, la grille Selenium n'est pas utilisée dans sa forme pure, sauf lorsque nous devons travailler avec des navigateurs qui ne peuvent pas être installés sur Linux OS.Dans tous les autres cas, l'utilisation d'une image Docker pour exécuter le hub et les nœuds de la grille Selenium est une solution beaucoup plus flexible et correcte. Cette approche simplifie considérablement la gestion des nœuds, car nous pouvons choisir l'image dont nous avons besoin avec des versions compatibles déjà installées de navigateurs et de pilotes.

Malgré les commentaires négatifs sur la stabilité, en particulier lors de l'exécution d'un grand nombre de nœuds en parallèle, la grille de sélénium est toujours l'outil le plus populaire pour exécuter des tests de sélénium en parallèle. Il est important de noter qu'en open-source, diverses améliorations et modifications de cet outil apparaissent constamment et sont confrontées à divers goulots d'étranglement.

Selenoid pour le web

Cet outil est une percée dans le monde du sélénium, car il fonctionne dès la sortie de l'emballage et a facilité la vie de nombreux ingénieurs en automatisation. Tout d'abord, ce n'est pas une autre modification de la grille de sélénium. Au lieu de cela, les développeurs ont créé une toute nouvelle version de Selenium Hub dans le langage Golang, qui, en conjonction avec 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 n'est pas un problème lorsque vous travaillez avec un seul navigateur. Mais en ce qui concerne plusieurs navigateurs pris en charge, Selenoid est la solution numéro un, grâce à la fonction «navigateur à la demande». Tout ce qui nous est demandé est de précharger les images nécessaires avec les navigateurs et de mettre à jour le fichier de configuration,avec lequel Selenoid interagit. Une fois que Selenoid a reçu une demande des tests, il lancera automatiquement le bon conteneur avec le bon navigateur. Une fois le test terminé, Selenoid supprimera le conteneur, libérant ainsi des ressources pour les requêtes suivantes. Cette approche élimine complètement le problème bien connu de la «dégradation des nœuds», que nous voyons souvent dans la grille de sélénium.

Mais hélas, Selenoid n'est toujours pas une solution miracle. Nous avons la fonctionnalité de navigateur à la demande, mais la fonctionnalité de ressources à la demande n'est toujours pas disponible. Pour utiliser Selenoid, nous devons le déployer sur un matériel physique ou une machine virtuelle, ce qui signifie que nous devons savoir à l'avance combien de ressources doivent être allouées. Je pense 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 faire si nous avons besoin de 100, 500, 1000 et plus? Cela n'a aucun sens de maintenir et de payer autant de ressources tout le temps. Dans les sections 5 et 6 de cet article, nous discuterons des solutions qui vous permettent d'évoluer, réduisant ainsi considérablement les coûts de l'entreprise.

Selenoid pour Android

Après le succès de Selenoid en tant qu'outil d'automatisation Web, les gens voulaient obtenir quelque chose de similaire pour Android. Et c'est arrivé - Selenoid a été publié avec le support Android. Du point de vue de l'utilisateur de haut niveau, le principe de fonctionnement est similaire à l'automatisation Web. La seule différence est qu'au lieu de conteneurs avec des navigateurs, Selenoid lance des conteneurs avec des émulateurs Android. À mon avis, c'est aujourd'hui l'outil gratuit le plus puissant pour exécuter des tests Android en parallèle.

Je ne voudrais vraiment pas parler des aspects négatifs de cet outil, car je l'aime beaucoup. Mais il y a toujours les mêmes inconvénients liés à l'automatisation Web liés à la mise à l'échelle. En plus de cela, nous devons parler d'une autre limitation, qui peut surprendre si nous accordons l'instrument pour la première fois. Pour exécuter des images Android, nous avons besoin d'une machine physique ou d'une machine virtuelle avec prise en charge de la virtualisation imbriquée. Dans le guide pratique, je montre comment l'activer 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 démarrer la machine virtuelle Linux localement avec la «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. Ce sont la grille Selenium pour les tests Web et Selenoid pour les tests Android. Dans le manuel GitHub, je montrerai également comment utiliser Selenoid pour exécuter des tests Web. 



Liens d'apprentissage



Outils similaires


  • Il existe d'autres outils de conteneurisation, mais Docker est le plus populaire. Si vous voulez essayer autre chose, gardez à l'esprit que les outils que nous avons examinés pour exécuter des tests Selenium en parallèle ne fonctionneront pas immédiatement.  
  • Comme déjà mentionné, il existe de nombreuses modifications de la grille de sélénium, par exemple le zalénium .

4. CI / CD


Dossier technologique


La pratique de l'intégration continue est très populaire en développement et est comparable aux systèmes de contrôle de version. Malgré cela, je pense qu'il y a confusion dans la terminologie. Dans cette section, je voudrais décrire 3 modifications de cette technologie de mon point de vue. Sur Internet, vous pouvez trouver de nombreux articles avec des interprétations différentes, et il est tout à fait normal que votre opinion soit différente. La chose la plus importante est que vous êtes sur la même longueur d'onde que vos collègues.

Donc, il y a 3 termes: CI - Intégration Continue (CD), CD - Livraison Continue (CD) et encore CD - Déploiement Continu (CD). ( De plus, j'utiliserai ces termes en anglais) Chaque modification ajoute quelques étapes supplémentaires à votre pipeline de développement. Mais le mot continu est le plus important. Dans ce contexte, nous entendons quelque chose qui se produit du début à la fin, sans interruption ni exposition manuelle. Jetons un œil à CI & CD et CD dans ce contexte.

  • L'intégration continue est la première étape de l'évolution. Après avoir envoyé le nouveau code au serveur, nous nous attendons à obtenir un retour rapide que tout est en ordre avec nos modifications. En règle générale, CI inclut le lancement d'outils d'analyse de code statique et de tests unitaires / API internes, ce qui vous permet d'obtenir des informations sur notre code quelques secondes / minutes plus tard.
  • Continuous Delivery , /UI-. , CI. -, . -, test/staging — . , , .
  • Continuous Deployment , (release) production, . release , smoke — production . Continuous Deployment . - , , Continuous (). , Continuous Delivery.


Dans cette section, je dois préciser que lorsque nous parlons de tests d'interface utilisateur de bout en bout, cela implique que nous devons déployer nos modifications et nos services associés dans des environnements de test. 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 un sens dans le contexte des tests d'interface utilisateur si nous voulons les exécuter en production.

Et avant de regarder 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 avancées. GitLab est donc plus que CI. Il comprend le contrôle des sources prêt à l'emploi, la gestion Agile, les pipelines CI / CD, les outils de journalisation et la collecte de métriques. L'architecture GitLab comprend Gitlab CI / CD et GitLab Runner. Je donne une brève description sur le 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 de Gitlab et de Runner.








5.



Dans cette section, nous parlerons d'une tendance populaire appelée «nuages ​​publics». Malgré les énormes avantages que procurent 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) du nombre de ressources dont nous aurons besoin, si nous les utiliserons 24/7 et à quelles fins. Par exemple, la production nécessite un serveur fonctionnant 24h / 24, mais avons-nous besoin de ressources similaires pour les tests après les heures? Cela dépend également du type de test effectué. Un exemple serait les tests de stress / stress, que nous prévoyons d'exécuter après les heures pour obtenir des résultats le lendemain. Mais certainementLa disponibilité du serveur 24h / 24 n'est pas requise pour les tests automatiques de bout en bout, et en particulier pour les environnements de test manuel. Dans de telles situations, il serait bon de recevoir autant de ressources que nécessaire sur demande, de les utiliser et de cesser de payer lorsqu'elles ne sont plus nécessaires. De plus, il serait bien de les recevoir instantanément en faisant quelques clics de souris ou en exécutant quelques scripts. Pour cela, des clouds publics sont utilisés. Regardons la définition:Pour cela, des clouds publics sont utilisés. Regardons la définition:Pour cela, des clouds publics sont utilisés. Regardons la définition:
«Le cloud public est défini comme des services informatiques proposés par des fournisseurs tiers sur Internet public, les rendant accessibles à toute personne qui souhaite les utiliser ou les acheter. "Ils peuvent être gratuits ou vendus à la demande, ce qui permet aux clients de payer uniquement par utilisation pour les cycles de processeur, le stockage ou la bande passante qu'ils consomment."

Il y a une opinion que les clouds publics sont chers. Mais leur idée clé est de réduire les coûts de l'entreprise. Comme mentionné précédemment, les clouds publics vous permettent d'obtenir des ressources à la demande et de payer uniquement pour la durée d'utilisation. De plus, nous oublions parfois que les employés sont payés et que les spécialistes sont également une ressource coûteuse. Gardez à l'esprit que les clouds publics facilitent considérablement la prise en charge de l'infrastructure, 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 des tests d'interface utilisateur de bout en bout? Il s'agit principalement de machines virtuelles ou de clusters (nous parlerons de Kubernetes dans la section suivante) pour lancer des navigateurs et des émulateurs. Plus nous voulons exécuter de navigateurs et d'émulateurs en même temps, plus de CPU et de mémoire sont nécessaires et plus nous devrons payer pour cela. Ainsi, les clouds publics dans le cadre de l'automatisation des tests nous permettent de lancer un grand nombre (100, 200, 1000 ...) de navigateurs / émulateurs à la demande, d'obtenir les résultats des tests le plus rapidement possible et d'arrêter de payer pour des capacités aussi gourmandes en ressources. 

Les fournisseurs de cloud les plus populaires sont Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Le guide pratique fournit des exemples d'utilisation de GCP, mais en général, peu importe ce que vous utiliserez pour les tâches d'automatisation. Tous offrent approximativement les mêmes fonctionnalités. En règle générale, pour sélectionner un fournisseur, la gestion se concentre sur l'ensemble de l'infrastructure et des besoins de l'entreprise, qui dépassent le cadre de cet article. Il sera plus intéressant pour les ingénieurs d'automatisation de comparer l'utilisation de fournisseurs de cloud utilisant des plateformes cloud spécifiquement à des fins de test telles que Sauce Labs, BrowserStack, BitBar, etc. Alors faisons de même! À mon avis, Sauce Labs est la ferme de tests cloud la plus célèbre, donc je l'ai prise pour comparaison. 

GCP contre Sauce Labs pour l'automatisation:

imaginez que nous devons exécuter 8 tests Web et 8 tests Android en même temps. Pour ce faire, nous utiliserons GCP et exécuterons 2 machines virtuelles avec Selenoid. Le premier, nous lèverons 8 conteneurs avec des navigateurs. Sur le second - 8 conteneurs avec émulateurs. Jetons un coup d'œil aux prix:  


Pour exécuter un conteneur avec Chrome, nous avons besoin d'une machine n1-standard-1 . Dans le cas d'Android, ce sera n1-standard-4 pour un émulateur. En fait, un moyen plus flexible et moins cher consiste à définir des valeurs utilisateur spécifiques pour le CPU / mémoire, mais pour le moment ce n'est pas important pour la comparaison avec Sauce Labs.

Et voici les tarifs d'utilisation de Sauce Labs:


Je suppose que vous avez déjà remarqué la différence, mais je vais quand même donner un tableau avec les calculs pour notre tâche:

Ressources requisesMensuelHeures de travail (8 h - 20 h)Heures de travail + Préemptif
Gcp pour le webn1-standard-1 x 8 = n1-standard-8194,18 $23 jours * 12h * 0,38 = 104,88 $ 23 jours * 12h * 0,08 = 22,08 $
Sauce Labs pour le WebTests parallèles Virtual Cloud81,559 $--
GCP pour Androidn1-standard-4 x 8: n1-standard-16776,72 $23 jours * 12h * 1,52 = 419,52 $ 23 jours * 12h * 0,32 = 88,32 $
Sauce Labs pour AndroidTests parallèles de Real Device Cloud 81,999 $--

Comme vous pouvez le voir, la différence de coût est énorme, surtout si vous exécutez les tests uniquement pendant la période de douze heures de travail. Mais vous pouvez encore réduire les coûts en utilisant des machines préemptives. Qu'Est-ce que c'est?
A preemptible VM is an instance that you can create and run at a muchower price than normal instances. However, Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.

If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances terminate during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.

Et ce n'est pas encore la fin! En fait, je suis sûr que personne ne fait de tests pendant 12 heures sans interruption. Et si c'est le cas, vous pouvez alors démarrer et arrêter automatiquement les machines virtuelles lorsqu'elles ne sont pas nécessaires. Le temps d'utilisation réel peut chuter à 6 heures par jour. Ensuite, le paiement dans le cadre de notre tâche diminuera jusqu'à 11 $ par mois pour 8 navigateurs. N'est-ce pas parfait? Mais avec les machines préemptives, nous devons être prudents et préparés aux interruptions et au fonctionnement instable, bien que ces situations puissent être fournies et traitées par programme. Ça en vaut la peine!

Mais en aucun cas je ne dis «n'utilisez jamais de batteries de tests cloud». Ils ont plusieurs avantages. Tout d'abord, ce n'est pas seulement une machine virtuelle, mais une solution complète pour tester l'automatisation avec un ensemble de fonctionnalités prédéfinies: 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 indispensable. Les plates-formes de test sont particulièrement utiles pour l'automatisation IOS lorsque les clouds publics ne peuvent offrir que des systèmes Linux / Windows. Mais parler d'iOS sera dans les prochains articles. Je recommande de toujours regarder la situation et de commencer par les tâches: dans certains, il est moins cher et plus efficace d'utiliser les clouds publics, et dans certaines plates-formes de test, cela en vaut vraiment la peine.

Illustration de l'état actuel des infrastructures




Liens d'apprentissage



Outils similaires:



6. Orchestration


Dossier technologique


J'ai une bonne nouvelle - nous avons presque atteint la fin de l'article! À l'heure actuelle, notre infrastructure d'automatisation se compose de tests Web et Android, que nous exécutons via GitLab CI en parallèle, en utilisant des outils avec prise en charge Docker: grille Selenium et Selenoid. De plus, nous utilisons des machines virtuelles créées via GCP pour soulever des conteneurs contenant des navigateurs et des émulateurs. Pour réduire les coûts, nous démarrons ces machines virtuelles uniquement à la demande et nous nous arrêtons lorsque le test n'est pas effectué. Y a-t-il autre chose qui peut améliorer notre infrastructure? La réponse est oui! Rencontrez Kubernetes (K8s)!

Pour commencer, examinez comment les mots orchestration, cluster et Kubernetes sont liés. À un niveau élevé, l'orchestration est un système qui déploie et gère des applications. Pour automatiser les tests, ces applications conteneurisées sont la grille de sélénium et le sélénoïde. Docker et K8 se complètent. Le premier est utilisé pour déployer des applications, le second pour l'orchestration. À son tour, K8s est un cluster. La tâche du cluster consiste à utiliser des machines virtuelles en tant que nœuds, ce qui vous permet d'installer diverses fonctionnalités, programmes et services sur un seul serveur (cluster). Si l'un des nœuds se bloque, d'autres nœuds seront récupérés, ce qui garantit le bon fonctionnement de notre application. En plus de cela, K8s possède des fonctionnalités importantes liées à la mise à l'échelle,grâce à laquelle nous obtenons automatiquement la quantité optimale de ressources, en fonction de la charge et des restrictions établies.

En vérité, le déploiement manuel de Kubernetes à partir de zéro est une tâche complètement non triviale. Je vais laisser un lien vers Kubernetes The Hard Way, un guide pratique bien connu, et si vous êtes intéressé, vous pouvez pratiquer. Mais, heureusement, il existe d'autres moyens et outils. Le plus simple d'entre eux est d'utiliser le moteur Google Kubernetes (GKE) dans GCP, qui vous permettra d'obtenir un cluster prêt à l'emploi après quelques clics. Pour commencer l'étude, je vous recommande d'utiliser cette approche, car elle vous permettra de vous concentrer sur l'apprentissage de l'utilisation des K8 pour vos tâches, au lieu d'explorer comment les composants internes doivent être intégrés. 

Valeur pour l'infrastructure d'automatisation


Considérez certaines des fonctionnalités importantes fournies par K8:

  • : multi-nodes , VMs;
  • : , ;
  • (Self-healing): pods ( );
  • : ,

Mais les K8 ne sont toujours pas une solution miracle. Pour comprendre tous les avantages et les limites dans le contexte des outils que nous envisageons (grille de sélénium, sélénoïde), nous discutons brièvement de 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 principaux sont responsables de la gestion, du déploiement et de la planification des décisions. Les nœuds de travail sont l'endroit où les applications s'exécutent. Les nœuds contiennent également un environnement de lancement de conteneur. Dans notre cas, il s'agit de Docker, qui est responsable des opérations liées aux conteneurs. Mais il existe des solutions alternatives comme containerd. Il est important de comprendre que l'entartrage ou l'auto-guérison ne s'applique pas directement aux conteneurs. Cela se fait en ajoutant / diminuant le nombre de pods, qui à leur tour contiennent des conteneurs (généralement un conteneur par pod, mais il peut y en avoir plus selon la tâche). La hiérarchie de haut niveau est constituée de nœuds de travail, à l'intérieur desquels se trouvent des pods, à l'intérieur desquels les conteneurs sont élevés.

La fonction de mise à l'échelle est essentielle et peut être appliquée à la fois aux nœuds à l'intérieur d'un pool de nœuds de cluster et aux pods à l'intérieur d'un nœud. Il existe 2 types de mise à l'échelle qui s'appliquent aux nœuds et aux pods. Le premier type - horizontal - mise à l'échelle se produit en raison d'une augmentation du nombre de nœuds / pods. Ce type est plus préféré. Le deuxième type, respectivement, est vertical. La mise à l'échelle se fait en augmentant la taille des nœuds / pods, pas leur nombre.

Considérons maintenant nos outils dans le contexte des termes ci-dessus.

Grille de sélénium

Comme mentionné précédemment, la grille de sélénium est un outil très populaire, et il n'est pas surprenant qu'elle ait été conteneurisée. Par conséquent, il n'est pas surprenant que la grille de sélénium puisse être déployée dans les K8. Un exemple de la façon de procéder peut être trouvé dans le dépôt officiel de K8s. Comme d'habitude, je joins des liens à la fin de la section. En plus de cela, le guide pratique montre comment procéder dans la série Terraform. Il existe également une instruction sur la façon de mettre à l'échelle le nombre de modules contenant des conteneurs avec des navigateurs. Mais la fonction de mise à l'échelle automatique dans le contexte des K8 n'est toujours pas une tâche évidente. Lorsque j'ai commencé l'étude, 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 à élever des conteneurs avec les navigateurs souhaités dans un pod, qui est 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 qu'à l'avenir la situation changera, et nous verrons de plus en plus de descriptions des meilleures approches et solutions clé en main, surtout après la sortie de Selenium grid 4 avec une architecture interne modifiée.surtout après la sortie de Selenium grid 4 avec une architecture interne repensée.surtout après la sortie de Selenium grid 4 avec une architecture interne repensée.

Selenoid :

Actuellement, le déploiement de Selenoid dans les K8 est la plus grande déception. Ils ne sont pas compatibles. Théoriquement, nous pouvons soulever un conteneur Selenoid à l'intérieur d'un pod, mais lorsque Selenoid commence à lancer des conteneurs avec des navigateurs, ils seront toujours à l'intérieur du même pod. Cela rend la mise à l'échelle impossible et, par conséquent, le travail de Selenoid à l'intérieur du cluster ne sera pas différent du travail à l'intérieur de la machine virtuelle. La fin de l'histoire.

Moon :

Connaissant ce goulot d'étranglement tout en travaillant 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, vous pouvez et devez utiliser la fonction de mise à l'échelle automatique. De plus, je dirais que pour le moment c'est le seulun outil dans le monde Selenium, qui, dès la sortie de la boîte, prend en charge le cluster natif K8s ( n'est plus disponible, voir l'outil suivant ). Une caractéristique clé de Moon qui fournit ce support est: 
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 d'exécution sont perdues. Au contraire, la lune n'a pas d'état interne et peut être répliquée dans les centres de données. Les sessions du navigateur restent actives même si une ou plusieurs répliques tombent en panne.
Donc, Moon est une excellente solution, mais avec un problème, il n'est pas gratuit. Le prix dépend du nombre de séances. Seules les sessions 0-4 peuvent être lancées gratuitement, ce qui n'est pas particulièrement utile. Mais, à partir de la cinquième session, vous devrez payer 5 $ pour chacun. La situation peut différer d'une entreprise à l'autre, mais dans notre cas, l'utilisation de Moon est inutile. Comme je l'ai décrit ci-dessus, nous pouvons démarrer 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 $ par mois supplémentaires et peu importe la fréquence à laquelle nous exécutons les tests. Et encore une fois, je ne dis pas "n'utilisez pas la Lune". Pour vos tâches, cela peut être une solution indispensable, par exemple,si vous avez beaucoup de 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 je recommande de faire tous les calculs nécessaires dans le contexte de votre tâche.

Callisto : ( Attention! Ce n'est pas dans l'article original et n'est contenu que dans la traduction russe )

Comme je l'ai dit, le sélénium est un outil très populaire, et l'industrie informatique se développe très rapidement. Pendant que je travaillais sur la traduction, un nouvel outil Callisto prometteur est apparu sur le réseau (bonjour Cypress et autres tueurs au sélénium). Il fonctionne nativement avec les K8 et vous permet d'exécuter des conteneurs Selenoid dans des pods, distribués par des nœuds. Tout fonctionne dès la sortie de l'emballage, y compris la mise à l'échelle automatique. Fiction, mais il faut tester. J'ai déjà réussi à déployer cet outil et à faire quelques expériences. Mais il est trop tôt pour tirer des conclusions, après avoir reçu des résultats à longue distance, je reviendrai peut-être dans les articles suivants. Jusqu'à présent, je ne laisse que des liens pour des recherches indépendantes.  







7. (IaC)



Et nous sommes donc arrivés à la dernière section. Habituellement, cette technologie et les tâches connexes ne font pas partie du domaine de 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 avec quoi le pipeline fonctionne et de la manière de prendre en charge tout ce qui s'y rapporte. Deuxièmement, soyons honnêtes, la pratique de «l'infrastructure en tant que code (IaC)» n'est toujours pas appliqué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 associés. Ou du moins, restez au courant des développements.

Commençons par la motivation pour utiliser cette approche. Nous avons déjà expliqué que pour exécuter les tests dans GitlabCI, nous avons au moins besoin des ressources nécessaires pour exécuter Gitlab Runner. Et pour exécuter des conteneurs avec des navigateurs / émulateurs, nous devons réserver une machine virtuelle ou un cluster. Outre les ressources de test, nous avons besoin d'un nombre important de capacités pour prendre en charge les environnements de développement, le transfert, la production, ce qui inclut également les bases de données, les planifications automatiques, les configurations réseau, les équilibreurs de charge, les droits des utilisateurs, etc. Un problème 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 d'interface utilisateur dans le navigateur et effectuer toutes les actions en cliquant sur les boutons.Une autre façon serait d'utiliser des appels d'API pour interagir avec des entités cloud ou d'utiliser l'utilitaire de ligne de commande gcloud pour effectuer les manipulations nécessaires. 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 envoyer pour examen avant l'exécution, utiliser le système de contrôle de version et annuler rapidement les modifications qui ont conduit à l'incident. Pour résoudre ces problèmes, les ingénieurs ont créé et créent des scripts bash / shell automatiques, ce qui n'est pas beaucoup mieux que les méthodes précédentes, car ils ne sont pas si faciles à lire, à comprendre, à maintenir et à modifier dans un style procédural.

Dans cet article et comment, j'utilise 2 outils liés à la pratique IaC. Ce sont Terraform et Ansible. Certains pensent que cela n'a aucun sens de les utiliser simultanément, car leur fonctionnalité est similaire et ils sont interchangeables. Mais le fait est qu'au départ, ils sont confrontés à des tâches complètement différentes. Et le fait que ces outils devraient se compléter a été confirmé lors d'une présentation conjointe par les développeurs représentant HashiCorp et RedHat. La différence conceptuelle est que Terraform est un outil de provisioning pour gérer les serveurs eux-mêmes. 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 clé de ces outils est le style d'écriture du code. Contrairement à bash et Ansible, Terraform utilise un style déclaratif basé sur la description de l'état final souhaité, qui doit être atteint à la suite de l'exécution. Par exemple, si nous allons créer 10 machines virtuelles et appliquer les modifications via Terraform, nous obtenons 10 machines virtuelles. Si vous appliquez à nouveau le script, rien ne se passera, car nous avons déjà 10 machines virtuelles 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 lors de la première exécution, nous obtenons 10 VM, de même avec Terraform. Mais après le redémarrage, nous aurons déjà 20 machines virtuelles. C'est une différence importante.Dans le style procédural, nous ne stockons pas l'état actuel et décrivons simplement la séquence des étapes à effectuer. Bien sûr, nous pouvons gérer diverses situations, ajouter plusieurs vérifications de l'existence des ressources et de l'état actuel, mais il est inutile de perdre notre temps et de faire des efforts pour contrôler cette logique. De plus, cela augmente le risque de faire des erreurs. 

En résumant tout ce qui précède, nous pouvons conclure que pour l'approvisionnement des serveurs, Terraform et la notation déclarative sont un outil plus approprié. Mais le travail de gestion de la configuration est mieux délégué à Ansible. Après avoir traité cela, regardons des exemples d'utilisation dans le contexte de l'automatisation.

Valeur pour l'infrastructure d'automatisation


Il est important de comprendre seulement que l'infrastructure d'automatisation des tests doit être considérée comme faisant partie de l'infrastructure entière de l'entreprise. Cela signifie que toutes les pratiques IaC doivent être appliquées à l'échelle mondiale aux ressources de l'ensemble de l'organisation. Qui en est responsable dépend de vos processus. L'équipe DevOps est plus expérimentée dans ces domaines, elle voit tout ce qui se passe. Cependant, les ingénieurs QA sont davantage impliqués dans le processus d'automatisation des bâtiments et la structure du pipeline, ce qui leur permet de mieux voir tous les changements nécessaires et les opportunités d'amélioration. La meilleure option est de travailler ensemble, de partager les connaissances et les idées pour atteindre le résultat attendu. 

Voici quelques exemples d'utilisation de Terraform et Ansible dans le contexte des tests d'automatisation et des outils dont nous avons discuté auparavant:

1. Décrivez via Terraform les caractéristiques et paramètres nécessaires des VM et des clusters.

2. Installez avec Ansible les outils nécessaires aux tests: docker, Selenoid, Selenium Grid et téléchargez les versions nécessaires des navigateurs / émulateurs.

3. Décrivez via Terraform les caractéristiques de la VM dans laquelle GitLab Runner sera lancé.

4. Installez avec Ansible GitLab Runner et les outils connexes nécessaires, définissez les paramètres et les configurations.

Illustration de l'état actuel des infrastructures



Liens d'étude:



Outils similaires




Résumer!


ÉtapeLa technologieOutilsValeur pour l'infrastructure d'automatisation
1Local runningNode.js, Selenium, Appium
  • web mobile
  • ( Node.js)

2Version control systems Git

3ContainerisationDocker, Selenium grid, Selenoid (Web, Android)
  • ,

4CI / CDGitlab CI
  • /

5Cloud platformsGoogle Cloud Platform
  • ( )

6OrchestrationKubernetes/ pods:
  • /

7Infrastructure en tant que code (IaC)Terraform, ansible
  • Avantages similaires avec l'infrastructure de développement
  • Tous les avantages du versioning de code
  • Modifications et maintenance faciles
  • Entièrement automatisé



Diagrammes de cartes mentales: évolution des infrastructures


étape 1: local


étape 2: vcs


étape3: Conteneurisation 


étape 4: CI / CD 


étape 5: plates-formes cloud


étape 6: orchestration


étape 7: IaC


Et après?


C'est donc la fin de l'article. Mais en conclusion, je voudrais conclure quelques accords avec vous.

De votre part
Comme cela a été dit au début, je voudrais que l'article soit d'une utilité pratique et vous aide à appliquer les connaissances acquises dans le travail réel. J'ajoute à nouveau un lien vers un guide pratique .

Mais même après cela, ne vous arrêtez pas, pratiquez, étudiez les liens et les livres pertinents, découvrez comment cela fonctionne dans votre entreprise, trouvez des endroits qui peuvent être améliorés et participez-y. Bonne chance

De mon côté

De l'intitulé, il est clair que ce n'était que la première partie. Malgré le fait qu'il s'est avéré être assez important, des sujets importants ne sont toujours pas divulgués ici. Dans la deuxième partie, je prévois d'examiner l'infrastructure d'automatisation dans le contexte d'IOS. En raison des limites d'Apple concernant l'exécution de simulations iOS uniquement sur les systèmes macOS, notre ensemble de solutions a été réduit. Par exemple, nous ne pouvons pas utiliser Docker pour exécuter un simulateur ou des clouds publics pour exécuter des machines virtuelles. Mais cela ne signifie pas qu'il n'y a pas d'autres alternatives. Je vais essayer de vous tenir au courant avec 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 partie 3, je vais examiner les outils les plus populaires pour surveiller l'infrastructure, ainsi que les données et les mesures à prendre en compte.

Et enfin. À l'avenir, je prévois de publier un cours vidéo sur la construction d'une infrastructure de test et d'outils populaires. Actuellement, il y a beaucoup de cours et de conférences sur DevOps sur Internet, mais tous les matériaux sont présentés dans le contexte du développement, mais pas des tests d'automatisation. À cet égard, j'ai vraiment besoin de commentaires si ce cours sera intéressant et précieux pour la communauté des testeurs et des ingénieurs en automatisation. Merci d'avance!

All Articles