Part 1: Web/Android
Nota: aquest article és una traducció al rus de l'article original Tanmateix, totes les il·lustracions, enllaços, cites i termes es conserven en l'idioma original per evitar la distorsió del significat quan es tradueixen al rus. Et desitjo feliç estudiant!
Actualment, l'especialitat DevOps és una de les més demandades en el sector informàtic. Si obriu llocs de cerca de feina populars i filtreu per salari, veureu que les feines relacionades amb DevOps es troben a la part superior de la llista. No obstant això, és important entendre que això es refereix principalment a una posició 'Senior', la qual cosa implica que el candidat té un alt nivell d'habilitats, coneixements de tecnologia i eines. Això també comporta un alt grau de responsabilitat associat al funcionament ininterromput de la producció. Tanmateix, vam començar a oblidar què és DevOps. Inicialment, no es tractava de cap persona o departament en concret. Si busquem definicions d'aquest terme, trobarem molts substantius bonics i correctes, com ara metodologia, pràctiques, filosofia cultural, grup de conceptes, etc.
La meva especialització és un enginyer d'automatització de proves (enginyer d'automatització de control de qualitat), però crec que no s'ha d'associar només amb l'escriptura de proves automàtiques o el desenvolupament de l'arquitectura del marc de proves. El 2020, el coneixement de la infraestructura d'automatització també és essencial. Això us permet organitzar vosaltres mateixos el procés d'automatització, des de la realització de proves fins a proporcionar resultats a totes les parts interessades d'acord amb els vostres objectius. Com a resultat, les habilitats de DevOps són imprescindibles per fer la feina. I tot això és bo, però, malauradament, hi ha un problema (spoiler: aquest article intenta simplificar aquest problema). La qüestió és que DevOps és difícil. I això és evident, perquè les empreses no pagaran gaire per una cosa que sigui fàcil de fer... Al món DevOps, hi ha un gran nombre d'eines, termes i pràctiques que cal dominar. Això és especialment difícil a l'inici d'una carrera i depèn de l'experiència tècnica acumulada.
Font:
Aquí probablement acabarem amb la part introductòria i ens centrarem en l'objectiu d'aquest article.
De què tracta aquest article?
En aquest article, compartiré la meva experiència en la construcció d'una infraestructura d'automatització de proves. Hi ha moltes fonts d'informació a Internet sobre diverses eines i com utilitzar-les, però m'agradaria mirar-les exclusivament en el context de l'automatització. Crec que molts enginyers d'automatització estan familiaritzats amb la situació en què ningú, excepte tu, executa les proves desenvolupades o es preocupa per mantenir-les. Com a resultat, les proves queden obsoletes i heu de dedicar temps a actualitzar-les. De nou, a l'inici d'una carrera, aquesta pot ser una tasca bastant difícil: decidir sàviament quines eines haurien d'ajudar a eliminar un problema determinat, com seleccionar-les, configurar-les i mantenir-les. Alguns provadors recorren a DevOps (humans) per demanar ajuda i, siguem sincers, aquest enfocament funciona. En molts casos aquesta pot ser l'única opció ja que no tenim visibilitat de totes les dependències. Però, com sabem, els DevOps són nois molt ocupats, perquè han de pensar en tota la infraestructura de l'empresa, el desplegament, el seguiment, els microserveis i altres tasques similars en funció de l'organització/equip. Com sol ser el cas, l'automatització no és una prioritat. En aquest cas, hem d'intentar fer tot el possible per part nostra des del principi fins al final. Això reduirà les dependències, accelerarà el flux de treball, millorarà les nostres habilitats i ens permetrà veure la imatge més gran del que està passant.
L'article presenta les eines més populars i populars i mostra com utilitzar-les per construir una infraestructura d'automatització pas a pas. Cada grup està representat per eines que han estat provades a través de l'experiència personal. Però això no vol dir que hagis d'utilitzar el mateix. Les eines en si no són importants, apareixen i queden obsoletes. La nostra tasca d'enginyeria és comprendre els principis bàsics: per què necessitem aquest grup d'eines i quins problemes de treball podem resoldre amb la seva ajuda. És per això que al final de cada apartat deixo enllaços a eines similars que es poden utilitzar a la vostra organització.
El que no està en aquest article
Repeteixo una vegada més que l'article no tracta d'eines específiques, de manera que no hi haurà insercions de codi de la documentació i descripcions d'ordres concretes. Però al final de cada apartat deixo enllaços per a un estudi detallat.
Això es fa perquè:
- aquest material és molt fàcil de trobar en diverses fonts (documentació, llibres, videocursos);
- si comencem a aprofundir, haurem d'escriure 10, 20, 30 parts d'aquest article (mentre els plans són 2-3);
- Simplement no vull perdre el vostre temps, ja que potser voldreu utilitzar altres eines per aconseguir els mateixos objectius.
Pràctica
M'agradaria molt que aquest material fos útil per a tots els lectors, i no només llegit i oblidat. En qualsevol estudi, la pràctica és un component molt important. Per això m'he preparat. També us esperen deures per assegurar-vos que no copieu sense pensar les línies de les ordres que esteu executant.
Pla
Pas
Tecnologia
instruments
1
Execució local (preparar proves de demostració web/android i executar-lo localment)
Node.js, Selenium, Appium
2
Sistemes de control de versions
anar
3
Contenidorització
Docker, quadrícula de seleni, selenoide (web, Android)
4
CI/CD
Gitlab CI
5
Plataformes al núvol
Google Cloud Platform
6
Orquestració
Kubernetes
7
La infraestructura com a codi (IaC)
Terraform, Ansible
Estructura de cada secció
Per mantenir la narració clara, cada secció es descriu segons el següent esquema:
- breu descripció de la tecnologia,
- valor per a la infraestructura d'automatització,
- il·lustració de l'estat actual de la infraestructura,
- enllaços per estudiar,
- eines semblants.
1. Executeu proves localment
Breu descripció de la tecnologia
Aquest és només un pas preparatori per executar les proves de demostració localment i verificar que passen. A la part pràctica s'utilitza Node.js, però el llenguatge de programació i la plataforma tampoc són importants i pots utilitzar els que s'utilitzen a la teva empresa.
No obstant això, com a eines d'automatització, recomano utilitzar Selenium WebDriver per a plataformes web i Appium per a la plataforma Android, respectivament, ja que en els propers passos utilitzarem imatges de Docker que estan adaptades per treballar específicament amb aquestes eines. A més, pel que fa a les exigències laborals, aquestes eines són les més demandades al mercat.
Com haureu notat, només considerem proves web i Android. Malauradament, iOS és una història completament diferent (gràcies Apple). Tinc la intenció de mostrar solucions i pràctiques relacionades amb iOS en les properes parts.
Valor per a la infraestructura d'automatització
Des d'una perspectiva d'infraestructura, l'execució local no aporta cap valor. Només comproveu que les proves s'executen a la màquina local en navegadors i simuladors locals. Però en qualsevol cas, aquest és un punt de partida necessari.
Il·lustració de l'estat actual de la infraestructura
Enllaços per explorar
Eines semblants
- qualsevol llenguatge de programació que us agradi juntament amb les proves de Selenium/Appium;
- qualsevol prova;
- qualsevol corredor de proves.
2. Sistemes de control de versions (Git)
Breu descripció de la tecnologia
No serà una gran revelació per a ningú si dic que el control de versions és una part extremadament important del desenvolupament, tant en equip com individualment. A partir de diverses fonts, es pot dir que Git és el representant més popular. Un sistema de control de versions ofereix molts avantatges, com ara compartir codi, emmagatzemar versions, restaurar a branques anteriors, supervisar l'historial del projecte i còpies de seguretat. No parlarem de cada punt en detall, ja que estic segur que el coneixeu molt i l'utilitzeu en el vostre treball diari. Però si de sobte no, us recomano que atureu la lectura d'aquest article i ompliu aquest buit tan aviat com sigui possible.
Valor per a la infraestructura d'automatització
I aquí podeu fer una pregunta raonable: "Per què ens parla de Git? Tothom ho sap i l'utilitza tant per al codi de desenvolupament com per al codi de prova automàtica". Tindràs tota la raó, però en aquest article estem parlant d'infraestructura i aquesta secció fa de vista prèvia de la secció 7: “Infraestructura com a codi (IaC)”. Per a nosaltres, això significa que tota la infraestructura, incloses les proves, es descriu en forma de codi, de manera que també podem aplicar-hi sistemes de versions i obtenir beneficis similars als del codi de desenvolupament i automatització.
Veurem IaC amb més detall al pas 7, però fins i tot ara podeu començar a utilitzar Git localment creant un dipòsit local. El panorama general s'ampliarà quan afegim un dipòsit remot a la infraestructura.
Il·lustració de l'estat actual de la infraestructura
Enllaços per explorar
Eines semblants
3. Contenidor (Docker)
Breu descripció de la tecnologia
Per demostrar com la contenidorització ha canviat les regles del joc, retrocedim en el temps unes dècades. Aleshores, la gent comprava i utilitzava màquines servidor per executar aplicacions. Però en la majoria dels casos, els recursos d'inici necessaris no es coneixien per endavant. Com a resultat, les empreses van gastar diners en la compra de servidors cars i potents, però part d'aquesta capacitat no es va utilitzar completament.
La següent etapa d'evolució van ser les màquines virtuals (VM), que van resoldre el problema de malgastar diners en recursos no utilitzats. Aquesta tecnologia va permetre executar aplicacions independentment les unes de les altres dins del mateix servidor, assignant espai completament aïllat. Però, malauradament, qualsevol tecnologia té els seus inconvenients. L'execució d'una màquina virtual requereix un sistema operatiu complet, que consumeix CPU, RAM, emmagatzematge i, depenent del sistema operatiu, cal tenir en compte els costos de llicència. Aquests factors afecten la velocitat de càrrega i dificulten la portabilitat.
I ara anem a la contenidorització. Una vegada més, aquesta tecnologia resol el problema anterior, ja que els contenidors no utilitzen un sistema operatiu complet, la qual cosa allibera una gran quantitat de recursos i proporciona una solució ràpida i flexible per a la portabilitat.
Per descomptat, la tecnologia de contenidorització no és cap novetat i es va introduir per primera vegada a finals dels anys 70. En aquells dies, es van dur a terme moltes investigacions, desenvolupaments i intents. Però va ser Docker qui va adaptar aquesta tecnologia i la va fer fàcilment accessible per a les masses. Actualment, quan parlem de contenidors, en la majoria dels casos ens referim a Docker. Quan parlem de contenidors Docker, ens referim als contenidors Linux. Podem utilitzar sistemes Windows i macOS per executar contenidors, però és important entendre que en aquest cas apareix una capa addicional. Per exemple, Docker a Mac executa contenidors en silenci dins d'una màquina virtual Linux lleugera. Tornarem a aquest tema quan parlem de l'execució d'emuladors d'Android dins dels contenidors, de manera que aquí hi ha un matís molt important que s'ha de parlar amb més detall.
Valor per a la infraestructura d'automatització
Hem descobert que la containerització i Docker són genials. Vegem-ho en el context de l'automatització, perquè cada eina o tecnologia ha de resoldre un problema. Descrivim els problemes evidents de l'automatització de proves en el context de les proves d'IU:
- un gran nombre de dependències a l'hora d'instal·lar Selenium i especialment Appium;
- problemes de compatibilitat entre versions de navegadors, simuladors i controladors;
- manca d'espai aïllat per a navegadors/simuladors, que és especialment crític per a l'execució paral·lela;
- difícil de gestionar i mantenir si necessiteu executar 10, 50, 100 o fins i tot 1000 navegadors al mateix temps.
Però com que Selenium és l'eina d'automatització més popular i Docker és l'eina de contenidorització més popular, no hauria de sorprendre que algú hagi intentat combinar-los per crear una eina potent per resoldre els problemes esmentats anteriorment. Considerem aquestes solucions amb més detall.
Quadrícula de seleni al docker
Aquesta eina és la més popular al món de Selenium per executar diversos navegadors en diverses màquines i gestionar-los des d'un concentrador central. Per començar, heu de registrar almenys 2 parts: Hub i Node(s). Hub és un node central que rep totes les sol·licituds de les proves i les distribueix als nodes adequats. Per a cada Node podem configurar una configuració específica, per exemple, especificant el navegador desitjat i la seva versió. Tanmateix, encara hem de tenir cura dels controladors de navegador compatibles nosaltres mateixos i instal·lar-los als nodes desitjats. Per aquest motiu, Selenium grid no s'utilitza en la seva forma pura, excepte quan necessitem treballar amb navegadors que no es poden instal·lar al sistema operatiu Linux. Per a tots els altres casos, una solució significativament flexible i correcta seria utilitzar imatges de Docker per executar Selenium grid Hub i Nodes. Aquest enfocament simplifica molt la gestió dels nodes, ja que podem seleccionar la imatge que necessitem amb versions compatibles dels navegadors i controladors ja instal·lats.
Malgrat les crítiques negatives sobre l'estabilitat, especialment quan s'executen un gran nombre de nodes en paral·lel, la graella de seleni segueix sent l'eina més popular per executar proves de seleni en paral·lel. És important tenir en compte que constantment apareixen diverses millores i modificacions d'aquesta eina en codi obert, que combaten diversos colls d'ampolla.
Selenoide per a la web
Aquesta eina és un avenç al món de Selenium, ja que funciona de seguida i ha facilitat la vida de molts enginyers d'automatització. En primer lloc, aquesta no és una altra modificació de la graella de seleni. En canvi, els desenvolupadors van crear una versió completament nova de Selenium Hub a Golang, que, combinada amb imatges lleugeres de Docker per a diversos navegadors, va impulsar el desenvolupament de l'automatització de proves. A més, en el cas de Selenium Grid, hem de determinar amb antelació tots els navegadors necessaris i les seves versions, la qual cosa no suposa cap problema quan es treballa amb un sol navegador. Però quan es tracta de diversos navegadors compatibles, Selenoid és la solució número u gràcies a la seva funció de "navegador a demanda". L'únic que ens requereix és descarregar les imatges necessàries amb els navegadors amb antelació i actualitzar el fitxer de configuració amb el qual interactua Selenoid. Després que Selenoid rebi una sol·licitud de les proves, llançarà automàticament el contenidor desitjat amb el navegador desitjat. Quan finalitzi la prova, Selenoid retirarà el contenidor, alliberant així recursos per a futures sol·licituds. Aquest enfocament elimina completament el conegut problema de la "degradació del node" que sovint ens trobem a la graella de seleni.
Però, per desgràcia, Selenoid encara no és una bala de plata. Tenim la funció "navegador a demanda", però la funció "recursos a demanda" encara no està disponible. Per utilitzar Selenoid, hem de desplegar-lo en maquinari físic o en una màquina virtual, la qual cosa vol dir que hem de saber per endavant quants recursos s'han d'assignar. Suposo que això no és un problema per a projectes petits que executen 10, 20 o fins i tot 30 navegadors en paral·lel. Però, què passa si necessitem 100, 500, 1000 i més? No té sentit mantenir i pagar tants recursos tot el temps. A les seccions 5 i 6 d'aquest article, parlarem de solucions que us permeten escalar, reduint així significativament els costos de l'empresa.
Selenoid per a Android
Després de l'èxit de Selenoid com a eina d'automatització web, la gent volia alguna cosa semblant per a Android. I va passar: Selenoid es va llançar amb suport d'Android. Des d'un punt de vista d'usuari d'alt nivell, el principi de funcionament és similar a l'automatització web. L'única diferència és que en lloc dels contenidors del navegador, Selenoid executa contenidors d'emulador d'Android. Al meu entendre, aquesta és actualment l'eina gratuïta més potent per executar proves d'Android en paral·lel.
Realment no m'agradaria parlar dels aspectes negatius d'aquesta eina, ja que m'agrada molt. Però tot i així, hi ha els mateixos desavantatges que s'apliquen a l'automatització web i que s'associen a l'escala. A més d'això, hem de parlar d'una limitació més que pot sorprendre si estem configurant l'eina per primera vegada. Per executar imatges d'Android, necessitem una màquina física o VM amb suport de virtualització imbricada. A la guia pràctica, demostro com activar-ho en una màquina virtual Linux. Tanmateix, si sou un usuari de macOS i voleu implementar Selenoid localment, no serà possible executar proves d'Android. Però sempre podeu executar una màquina virtual Linux localment amb la "virtualització imbricada" configurada i desplegar Selenoid a l'interior.
Il·lustració de l'estat actual de la infraestructura
En el context d'aquest article, afegirem 2 eines per il·lustrar la infraestructura. Es tracta de Selenium grid per a proves web i Selenoid per a proves d'Android. Al tutorial de GitHub, també us mostraré com utilitzar Selenoid per executar proves web.
Enllaços per explorar
Eines semblants
- Hi ha altres eines de contenidorització, però Docker és la més popular. Si voleu provar alguna cosa més, tingueu en compte que les eines que hem cobert per executar proves de Selenium en paral·lel no funcionaran de la caixa.
- Com ja s'ha dit, hi ha moltes modificacions de la graella de seleni, per exemple,.
4.CI/CD
Breu descripció de la tecnologia
La pràctica de la integració contínua és força popular en desenvolupament i està a l'alçada dels sistemes de control de versions. Malgrat això, crec que hi ha confusió en la terminologia. En aquest paràgraf m'agradaria descriure 3 modificacions d'aquesta tecnologia des del meu punt de vista. A internet hi trobareu molts articles amb diferents interpretacions, i és del tot normal que la vostra opinió difereix. El més important és que estiguis en la mateixa pàgina amb els teus companys.
Per tant, hi ha 3 termes: CI - Integració contínua, CD - Lliurament continu i de nou CD - Desplegament continu. (A continuació faré servir aquests termes en anglès). Cada modificació afegeix diversos passos addicionals al vostre canal de desenvolupament. Però la paraula continu (continu) és el més important. En aquest context, ens referim a quelcom que passa de principi a fi, sense interrupció ni intervenció manual. Vegem CI & CD i CD en aquest context.
- Integració contínua aquest és el pas inicial de l'evolució. Després d'enviar el codi nou al servidor, esperem rebre un comentari ràpid que els nostres canvis estan bé. Normalment, CI inclou l'execució d'eines d'anàlisi de codi estàtic i proves d'API internes/unitats. Això ens permet obtenir informació sobre el nostre codi en pocs segons/minuts.
- lliurament continu és un pas més avançat on fem proves d'integració/UI. Tanmateix, en aquesta etapa no obtenim resultats tan ràpidament com amb CI. En primer lloc, aquests tipus de proves triguen més a completar-se. En segon lloc, abans de llançar-nos, hem de desplegar els nostres canvis a l'entorn de prova/procediment. A més, si estem parlant de desenvolupament mòbil, apareix un pas addicional per crear una compilació de la nostra aplicació.
- Desplegament continu suposa que alliberem automàticament els nostres canvis a la producció si totes les proves d'acceptació s'han superat en les etapes anteriors. A més d'això, després de l'etapa de llançament, podeu configurar diverses etapes, com ara la realització de proves de fum a la producció i la recollida de mètriques d'interès. El desplegament continu només és possible amb una bona cobertura mitjançant proves automatitzades. Si es requereix alguna intervenció manual, incloses les proves, ja no ho és Continu (continu). Aleshores podem dir que el nostre pipeline només compleix la pràctica del lliurament continu.
Valor per a la infraestructura d'automatització
En aquesta secció, hauria d'aclarir que quan parlem de proves d'interfície d'usuari d'extrem a extrem, vol dir que hem de desplegar els nostres canvis i els serveis associats als entorns de prova. Integració contínua: el procés no és aplicable per a aquesta tasca i ens hem de preocupar d'implementar almenys pràctiques de lliurament continu. El desplegament continu també té sentit en el context de les proves d'IU si les executarem en producció.
I abans de mirar la il·lustració del canvi d'arquitectura, vull dir algunes paraules sobre GitLab CI. A diferència d'altres eines de CI/CD, GitLab ofereix un dipòsit remot i moltes altres funcions addicionals. Per tant, GitLab és més que CI. Inclou gestió de codi font, gestió àgil, canalitzacions CI/CD, eines de registre i recollida de mètriques de manera immediata. L'arquitectura de GitLab consta de Gitlab CI/CD i GitLab Runner. Aquí teniu una breu descripció del lloc web oficial:
Gitlab CI/CD és una aplicació web amb una API que emmagatzema el seu estat en una base de dades, gestiona projectes/builds i proporciona una interfície d'usuari. GitLab Runner és una aplicació que processa les compilacions. Es pot desplegar per separat i funciona amb GitLab CI/CD mitjançant una API. Per a proves en execució, necessiteu tant la instància de Gitlab com el Runner.
Il·lustració de l'estat actual de la infraestructura
Enllaços per explorar
Eines semblants
- I molts altres
5. Plataformes en núvol
Breu descripció de la tecnologia
En aquesta secció parlarem d'una tendència popular anomenada 'núvols públics'. Malgrat els enormes beneficis que proporcionen les tecnologies de virtualització i contenidorització descrites anteriorment, encara necessitem recursos informàtics. Les empreses compren servidors cars o lloguen centres de dades, però en aquest cas cal fer càlculs (de vegades poc realistes) de quants recursos necessitarem, si els farem servir les 24 hores del dia i amb quina finalitat. Per exemple, la producció requereix un servidor que funcioni les 7 hores del dia, els XNUMX dies de la setmana, però necessitem recursos similars per fer proves fora de l'horari laboral? També depèn del tipus de prova que es faci. Un exemple serien les proves de càrrega/esforç que tenim previst fer durant les hores no laborals per tal d'obtenir resultats l'endemà. Però, definitivament, la disponibilitat del servidor les XNUMX hores del dia, els XNUMX dies de la setmana, no és necessària per a proves automatitzades d'extrem a extrem i, sobretot, per als entorns de proves manuals. Per a aquestes situacions, seria bo obtenir tants recursos com calgui a demanda, utilitzar-los i deixar de pagar quan ja no siguin necessaris. A més, seria fantàstic rebre'ls a l'instant fent uns quants clics del ratolí o executant un parell d'scripts. Per això s'utilitzen els núvols públics. Vegem la definició:
“El núvol públic es defineix com els serveis informàtics que ofereixen proveïdors de tercers a través d'Internet pública, posant-los a disposició de qualsevol persona que els vulgui utilitzar o comprar. Poden ser gratuïts o venuts sota demanda, cosa que permet als clients pagar només per ús pels cicles de la CPU, l'emmagatzematge o l'ample de banda que consumeixen".
Hi ha l'opinió que els núvols públics són cars. Però la seva idea clau és reduir els costos de l'empresa. Com s'ha esmentat anteriorment, els núvols públics us permeten obtenir recursos sota demanda i pagar només pel temps que els feu servir. A més, de vegades oblidem que els empleats reben sous, i els especialistes també són un recurs car. Cal tenir en compte que els núvols públics faciliten molt el suport de la infraestructura, cosa que permet als enginyers centrar-se en tasques més importants.
Valor per a la infraestructura d'automatització
Quins recursos específics necessitem per a les proves d'IU d'extrem a extrem? Bàsicament es tracta de màquines virtuals o clústers (parlarem de Kubernetes a la següent secció) per executar navegadors i emuladors. Com més navegadors i emuladors vulguem executar simultàniament, més CPU i memòria necessitem i més diners haurem de pagar. Així, els núvols públics en el context de l'automatització de proves ens permeten executar un gran nombre (100, 200, 1000...) de navegadors/emuladors sota demanda, obtenir resultats de les proves el més aviat possible i deixar de pagar per un consum tan boig de recursos. poder.
Els proveïdors de núvol més populars són Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). La guia pràctica ofereix exemples de com utilitzar GCP, però en general no importa el que utilitzeu per a les tasques d'automatització. Tots ofereixen aproximadament la mateixa funcionalitat. Normalment, per seleccionar un proveïdor, la gestió se centra en tota la infraestructura i els requisits empresarials de l'empresa, cosa que està fora de l'abast d'aquest article. Per als enginyers d'automatització, serà més interessant comparar l'ús de proveïdors de núvol amb l'ús de plataformes de núvol específicament per a proves, com Sauce Labs, BrowserStack, BitBar, etc. Així que fem-ho també! Al meu entendre, Sauce Labs és la granja de proves al núvol més famosa, per això la vaig utilitzar per comparar.
GCP vs Sauce Labs amb finalitats d'automatització:
Imaginem que necessitem executar 8 proves web i 8 proves d'Android simultàniament. Per a això utilitzarem GCP i executarem 2 màquines virtuals amb Selenoid. En el primer plantejarem 8 contenidors amb navegadors. A la segona hi ha 8 contenidors amb emuladors. Fem una ullada als preus:
Per executar un contenidor amb Chrome, necessitem n1-estàndard-1 cotxe. En el cas d'Android serà així n1-estàndard-4 per a un emulador. De fet, una manera més flexible i econòmica és establir valors d'usuari específics per a CPU/Memòria, però de moment això no és important per comparar-lo amb Sauce Labs.
I aquí teniu les tarifes per utilitzar Sauce Labs:
Crec que ja heu notat la diferència, però encara us proporcionaré una taula amb càlculs per a la nostra tasca:
Recursos necessaris
Mensualment
Hores de feina(8 a.m. - 8 p.m.)
Hores de feina+ Preemptible
GCP per al web
n1-estàndard-1 x 8 = n1-estàndard-8
$194.18
23 dies * 12 h * 0.38 = 104.88 $
23 dies * 12 h * 0.08 = 22.08 $
Sauce Labs per a la web
Proves paral·leles Virtual Cloud8
$1.559
-
-
GCP per a Android
n1-estàndard-4 x 8: n1-estàndard-16
$776.72
23 dies * 12 h * 1.52 = 419.52 $
23 dies * 12 h * 0.32 = 88.32 $
Sauce Labs per a Android
Real Device Cloud 8 proves paral·leles
$1.999
-
-
Com podeu veure, la diferència de cost és enorme, sobretot si feu proves només durant un període de treball de dotze hores. Però podeu reduir els costos encara més si feu servir màquines preemptibles. Què es?
Una màquina virtual preemptible és una instància que podeu crear i executar a un preu molt més baix que les instàncies normals. Tanmateix, Compute Engine pot finalitzar (preemptar) aquestes instàncies si requereix accés a aquests recursos per a altres tasques. Les instàncies preventives són un excés de capacitat de Compute Engine, de manera que la seva disponibilitat varia segons l'ús.
Si les vostres aplicacions són tolerants a errors i poden suportar possibles preempcions d'instàncies, les instàncies preventives poden reduir significativament els vostres costos de Compute Engine. Per exemple, els treballs de processament per lots es poden executar en instàncies preemptibles. Si algunes d'aquestes instàncies finalitzen durant el processament, el treball s'alenteix però no s'atura completament. Les instàncies preventives completen les vostres tasques de processament per lots sense afegir càrrega de treball addicional a les instàncies existents i sense requerir que pagueu el preu total per a instàncies normals addicionals.
I encara no s'ha acabat! En realitat, estic segur que ningú fa proves durant 12 hores sense descans. I si és així, podeu iniciar i aturar automàticament les màquines virtuals quan no siguin necessàries. El temps d'ús real es pot reduir a 6 hores al dia. Aleshores, el pagament en el context de la nostra tasca disminuirà a 11 dòlars al mes per a 8 navegadors. No és meravellós? Però amb les màquines preemptibles hem d'anar amb compte i estar preparats per a les interrupcions i la inestabilitat, encara que aquestes situacions es poden preveure i gestionar en programari. Val la pena!
Però de cap manera estic dient "mai utilitzeu granges de proves al núvol". Tenen una sèrie d'avantatges. En primer lloc, no es tracta només d'una màquina virtual, sinó d'una solució d'automatització de proves completa amb un conjunt de funcionalitats fora de la caixa: accés remot, registres, captures de pantalla, gravació de vídeo, diversos navegadors i dispositius mòbils físics. En moltes situacions, aquesta pot ser una alternativa elegant essencial. Les plataformes de prova són especialment útils per a l'automatització d'IOS, quan els núvols públics només poden oferir sistemes Linux/Windows. Però parlarem d'iOS en els articles següents. Recomano mirar sempre la situació i partir de les tasques: en alguns casos és més barat i eficient utilitzar núvols públics, i en d'altres les plataformes de proves definitivament valen la pena els diners invertits.
Il·lustració de l'estat actual de la infraestructura
Enllaços per explorar
Eines semblants:
6. Orquestració
Breu descripció de la tecnologia
Tinc bones notícies: estem gairebé al final de l'article! De moment, la nostra infraestructura d'automatització consisteix en proves web i Android, que executem a través de GitLab CI en paral·lel, utilitzant eines habilitades per Docker: Selenium grid i Selenoid. A més, fem servir màquines virtuals creades mitjançant GCP per allotjar contenidors amb navegadors i emuladors. Per reduir costos, engeguem aquestes màquines virtuals només sota demanda i les aturem quan no s'estan realitzant proves. Hi ha alguna cosa més que pugui millorar la nostra infraestructura? La resposta és sí! Coneix Kubernetes (K8s)!
Primer, mirem com es relacionen les paraules orquestració, clúster i Kubernetes. A un alt nivell, l'orquestració és el sistema que desplega i gestiona les aplicacions. Per a l'automatització de proves, aquestes aplicacions en contenidors són Selenium grid i Selenoid. Docker i K8 es complementen. El primer s'utilitza per al desplegament d'aplicacions, el segon per a l'orquestració. Al seu torn, K8s és un clúster. La tasca del clúster és utilitzar màquines virtuals com a nodes, la qual cosa us permet instal·lar diverses funcionalitats, programes i serveis dins d'un servidor (clúster). Si algun dels nodes falla, altres nodes es recolliran, cosa que garanteix un funcionament ininterromput de la nostra aplicació. A més d'això, K8s té una important funcionalitat relacionada amb l'escalat, gràcies a la qual obtenim automàticament la quantitat òptima de recursos en funció de la càrrega i els límits establerts.
De fet, desplegar manualment Kubernetes des de zero no és una tasca trivial. Us deixo un enllaç a la famosa guia pràctica "Kubernetes The Hard Way" i si us interessa, podeu practicar-la. Però, afortunadament, hi ha mètodes i eines alternatives. La manera més senzilla és utilitzar Google Kubernetes Engine (GKE) a GCP, la qual cosa us permetrà obtenir un clúster preparat amb uns quants clics. Us recomano utilitzar aquest enfocament per començar a aprendre, ja que us permetrà centrar-vos a aprendre a utilitzar els K8 per a les vostres tasques en lloc d'aprendre com s'han d'integrar els components interns.
Valor per a la infraestructura d'automatització
Fem una ullada a algunes característiques significatives que ofereix el K8s:
- desplegament d'aplicacions: utilitzant un clúster de diversos nodes en lloc de màquines virtuals;
- escalada dinàmica: redueix el cost dels recursos que s'utilitzen només a demanda;
- autocuració: recuperació automàtica de beines (com a resultat de la qual també es restauren els contenidors);
- llançament d'actualitzacions i retrocés de canvis sense temps d'inactivitat: l'actualització d'eines, navegadors i emuladors no interromp el treball dels usuaris actuals
Però el K8 encara no és una bala de plata. Per entendre tots els avantatges i limitacions en el context de les eines que estem considerant (quadrícula de seleni, selenoide), parlarem breument de l'estructura dels K8. El clúster conté dos tipus de nodes: nodes mestres i nodes de treball. Els nodes mestres són els responsables de la gestió, el desplegament i les decisions de programació. Els nodes de treball són on s'executen les aplicacions. Els nodes també contenen un entorn d'execució del contenidor. En el nostre cas, es tracta de Docker, responsable de les operacions relacionades amb els contenidors. Però també hi ha solucions alternatives, per exemple. És important entendre que l'escala o l'autocuració no s'aplica directament als contenidors. Això s'implementa afegint/disminuint el nombre de beines, que al seu torn contenen contenidors (normalment un contenidor per pod, però depenent de la tasca n'hi pot haver més). La jerarquia d'alt nivell consta de nodes de treball, dins dels quals hi ha beines, dins dels quals s'aixequen els contenidors.
La funció d'escala és clau i es pot aplicar tant als nodes d'un grup de nodes de clúster com als pods dins d'un node. Hi ha 2 tipus d'escala que s'apliquen tant als nodes com als pods. El primer tipus és horitzontal: l'escala es produeix augmentant el nombre de nodes/pods. Aquest tipus és més preferible. El segon tipus és, en conseqüència, vertical. L'escalat es realitza augmentant la mida dels nodes/pods, i no el seu nombre.
Ara mirem les nostres eines en el context dels termes anteriors.
Reixa de seleni
Com s'ha esmentat anteriorment, la graella de seleni és una eina molt popular i no és d'estranyar que s'hagi envasat en contenidors. Per tant, no sorprèn que la graella de seleni es pugui desplegar als K8. Un exemple de com fer-ho es pot trobar al repositori oficial de K8s. Com és habitual, adjunto enllaços al final de la secció. A més, la guia explicativa mostra com fer-ho a Terraform. També hi ha instruccions sobre com escalar el nombre de pods que contenen contenidors del navegador. Però la funció d'escala automàtica en el context de K8s encara no és una tasca completament òbvia. Quan vaig començar a estudiar, no vaig trobar cap orientació pràctica ni recomanació. Després de diversos estudis i experiments amb el suport de l'equip de DevOps, vam triar l'enfocament d'aixecar contenidors amb els navegadors necessaris dins d'un pod, que es troba dins d'un node de treball. Aquest mètode ens permet aplicar l'estratègia d'escala horitzontal de nodes augmentant-ne el nombre. Espero que això canviï en el futur i veurem cada cop més descripcions de millors enfocaments i solucions ja fetes, especialment després del llançament de Selenium grid 4 amb una arquitectura interna canviada.
selenoide:
El desplegament de selenoides a K8 és actualment la decepció més gran. No són compatibles. En teoria, podem aixecar un contenidor Selenoid dins d'un pod, però quan Selenoid comenci a llançar contenidors amb navegadors, encara estaran dins del mateix pod. Això fa que l'escalat sigui impossible i, com a resultat, el treball de Selenoid dins d'un clúster no diferirà del treball dins d'una màquina virtual. Fi de la història.
Moon:
Coneixent aquest coll d'ampolla quan treballaven amb Selenoid, els desenvolupadors van llançar una eina més potent anomenada Moon. Aquesta eina es va dissenyar originalment per funcionar amb Kubernetes i, com a resultat, la funció d'escalat automàtic es pot i s'ha d'utilitzar. A més, diria que de moment ho és l’únic una eina al món de Selenium, que té suport de clúster natiu K8s fora de la caixa (ja no està disponible, vegeu la següent eina ). Les característiques clau de Moon que proporcionen aquest suport són:
Completament apàtrida. Selenoid emmagatzema a la memòria informació sobre les sessions del navegador que s'executen actualment. Si per algun motiu el seu procés falla, es perden totes les sessions en execució. En canvi, la Lluna no té cap estat intern i es pot replicar a tots els centres de dades. Les sessions del navegador continuen vives encara que una o més rèpliques cauen.
Per tant, Moon és una gran solució, però hi ha un problema: no és gratuïta. El preu depèn del nombre de sessions. Només podeu executar de 0 a 4 sessions de forma gratuïta, cosa que no és especialment útil. Però, a partir de la cinquena sessió, hauràs de pagar 5 dòlars per cadascun. La situació pot variar d'una empresa a una altra, però en el nostre cas, utilitzar Moon no té sentit. Com he descrit anteriorment, podem executar màquines virtuals amb Selenium Grid sota demanda o augmentar el nombre de nodes del clúster. Per a aproximadament un pipeline, iniciem 500 navegadors i aturem tots els recursos un cop finalitzades les proves. Si féssim servir Moon, hauríem de pagar 500 x 5 addicionals = 2500 dòlars al mes, sense importar la freqüència amb què fem proves. Un cop més, no dic que no utilitzeu Moon. Per a les vostres tasques, aquesta pot ser una solució indispensable, per exemple, si teniu molts projectes/equips a la vostra organització i necessiteu un enorme clúster comú per a tothom. Com sempre, deixo un enllaç al final i recomano fer tots els càlculs necessaris en el context de la vostra tasca.
Callisto: (Atenció! Això no està a l'article original i només es troba a la traducció russa)
Com he dit, Selenium és una eina molt popular, i el camp de les TI es desenvolupa molt ràpidament. Mentre treballava en la traducció, va aparèixer a la xarxa una nova eina prometedora anomenada Callisto (hola Cypress i altres assassins de seleni). Funciona de manera nativa amb K8s i us permet executar contenidors Selenoid en pods, distribuïts entre Nodes. Tot funciona des de la caixa, inclòs l'escala automàtica. Fantàstic, però s'ha de provar. Ja he aconseguit desplegar aquesta eina i fer diversos experiments. Però és massa aviat per treure conclusions, després de rebre resultats a llarga distància, potser en faré una revisió en propers articles. De moment només deixo enllaços per a investigacions independents.
Il·lustració de l'estat actual de la infraestructura
Enllaços per explorar
Eines semblants
7. Infraestructura com a codi (IaC)
Breu descripció de la tecnologia
I ara anem a l'últim apartat. Normalment, aquesta tecnologia i les tasques relacionades no són responsabilitat dels enginyers d'automatització. I hi ha raons per això. En primer lloc, en moltes organitzacions, els problemes d'infraestructura estan sota el control del departament de DevOps i els equips de desenvolupament no es preocupen realment del que fa que funcioni el pipeline i de com s'ha de donar suport a tot allò relacionat amb ell. En segon lloc, siguem sincers, la pràctica d'Infraestructura com a codi (IaC) encara no s'adopta a moltes empreses. Però definitivament s'ha convertit en una tendència popular i és important intentar implicar-se en els processos, enfocaments i eines que s'hi associen. O almenys estar al dia.
Comencem per la motivació per utilitzar aquest enfocament. Ja hem comentat que per executar proves a GitlabCI, necessitarem com a mínim els recursos per executar Gitlab Runner. I per executar contenidors amb navegadors/emuladors, hem de reservar una màquina virtual o un clúster. A més dels recursos de prova, necessitem una quantitat important de capacitat per donar suport a entorns de desenvolupament, posada en escena i producció, que també inclou bases de dades, programacions automàtiques, configuracions de xarxa, equilibradors de càrrega, drets d'usuari, etc. La qüestió clau és l'esforç necessari per recolzar-ho tot. Hi ha diverses maneres de fer canvis i implementar actualitzacions. Per exemple, en el context de GCP, podem utilitzar la consola d'IU al navegador i realitzar totes les accions fent clic als botons. Una alternativa seria utilitzar trucades a l'API per interactuar amb entitats del núvol o utilitzar la utilitat de línia d'ordres gcloud per realitzar les manipulacions desitjades. Però amb un nombre molt gran d'entitats i elements d'infraestructura diferents, es fa difícil o fins i tot impossible realitzar totes les operacions manualment. A més, totes aquestes accions manuals són incontrolables. No podem enviar-los per revisar-los abans de l'execució, utilitzar un sistema de control de versions i desfer ràpidament els canvis que van provocar l'incident. Per resoldre aquests problemes, els enginyers van crear i crear scripts bash/shell automàtics, que no són molt millors que els mètodes anteriors, ja que no són tan fàcils de llegir, comprendre, mantenir i modificar ràpidament en un estil procedimental.
En aquest article i com a guia, faig servir 2 eines relacionades amb la pràctica IaC. Aquests són Terraform i Ansible. Algunes persones creuen que no té sentit utilitzar-les al mateix temps, ja que la seva funcionalitat és similar i són intercanviables. Però el fet és que inicialment se'ls encomanen tasques completament diferents. I el fet que aquestes eines s'haurien de complementar mútuament es va confirmar en una presentació conjunta dels desenvolupadors que representen HashiCorp i RedHat. La diferència conceptual és que Terraform és una eina de subministrament per gestionar els propis servidors. Mentre que Ansible és una eina de gestió de configuració la tasca de la qual és instal·lar, configurar i gestionar programari en aquests servidors.
Una altra característica distintiva clau d'aquestes eines és l'estil de codificació. A diferència de bash i Ansible, Terraform utilitza un estil declaratiu basat en una descripció de l'estat final desitjat que s'ha d'aconseguir com a resultat de l'execució. Per exemple, si creem 10 VM i apliquem els canvis mitjançant Terraform, obtindrem 10 VM. Si tornem a executar l'script, no passarà res ja que ja tenim 10 màquines virtuals, i Terraform ho sap perquè emmagatzema l'estat actual de la infraestructura en un fitxer d'estat. Però Ansible utilitza un enfocament procedimental i, si li demaneu que creï 10 VM, en el primer llançament obtindrem 10 VM, similars a Terraform. Però després de reiniciar ja tindrem 20 màquines virtuals. Aquesta és la diferència important. En l'estil procedimental, no emmagatzemem l'estat actual i simplement descrivim una seqüència de passos que s'han de realitzar. Per descomptat, podem gestionar diverses situacions, afegir diverses comprovacions de l'existència de recursos i de l'estat actual, però no serveix de res perdre el temps i esforçar-nos a controlar aquesta lògica. A més, això augmenta el risc d'error.
Resumint tot l'anterior, podem concloure que Terraform i la notació declarativa són una eina més adequada per proveir servidors. Però és millor delegar la tasca de gestió de la configuració a Ansible. Amb això fora del camí, mirem els casos d'ús en el context de l'automatització.
Valor per a la infraestructura d'automatització
L'únic important que cal entendre aquí és que la infraestructura d'automatització de proves s'ha de considerar com a part de tota la infraestructura de l'empresa. Això vol dir que totes les pràctiques d'IaC s'han d'aplicar globalment als recursos de tota l'organització. Qui és responsable d'això depèn dels vostres processos. L'equip de DevOps té més experiència en aquests problemes, veuen tota la imatge del que està passant. No obstant això, els enginyers de control de qualitat estan més implicats en el procés d'automatització de l'edifici i en l'estructura del gasoducte, cosa que els permet veure millor tots els canvis i oportunitats de millora necessaris. La millor opció és treballar junts, intercanviar coneixements i idees per aconseguir el resultat esperat.
A continuació es mostren alguns exemples d'ús de Terraform i Ansible en el context de l'automatització de proves i les eines que hem comentat abans:
1. Descriure les característiques i els paràmetres necessaris de les màquines virtuals i clústers mitjançant Terraform.
2. Amb Ansible, instal·leu les eines necessàries per fer proves: docker, Selenoid, Selenium Grid i descarregueu les versions necessàries dels navegadors/emuladors.
3. Amb Terraform, descriu les característiques de la VM en la qual es llançarà GitLab Runner.
4. Instal·leu GitLab Runner i les eines necessàries que l'acompanyen mitjançant Ansible, configureu els paràmetres i les configuracions.
Il·lustració de l'estat actual de la infraestructura
Enllaços per explorar:
Eines semblants
Resumim-ho!
Pas
Tecnologia
instruments
Valor per a la infraestructura d'automatització
1
Carrera local
Node.js, Selenium, Appium
- Les eines més populars per a web i mòbil
- Admet molts idiomes i plataformes (inclòs Node.js)
2
Sistemes de control de versions
anar
- Beneficis similars amb el codi de desenvolupament
3
Contenidorització
Docker, quadrícula de seleni, selenoide (web, Android)
- Execució de proves en paral·lel
- Ambients aïllats
- Actualitzacions de versions senzilles i flexibles
- Aturant dinàmicament els recursos no utilitzats
- Fàcil de configurar
4
CI/CD
Gitlab CI
- Prova part de la canonada
- Comentaris ràpids
- Visibilitat per a tota l'empresa/equip
5
Plataformes al núvol
Google Cloud Platform
- Recursos sota demanda (només paguem quan cal)
- Fàcil de gestionar i actualitzar
- Visibilitat i control de tots els recursos
6
Orquestració
Kubernetes
En el context de contenidors amb navegadors/emuladors dins de pods:
- Escalat/escalat automàtic
- Autocuració
- Actualitzacions i retrocessos sense interrupcions
7
La infraestructura com a codi (IaC)
Terraform, Ansible
- Beneficis similars amb la infraestructura de desenvolupament
- Tots els avantatges de la versió de codi
- Fàcil de fer canvis i mantenir
- Totalment automatitzat
Esquemes de mapes mentals: evolució de la infraestructura
Pas 1: Local
Pas 2: VCS
Pas 3: Contenidor
Pas 4: CI/CD
Pas 5: Plataformes al núvol
Pas 6: Orquestració
Pas 7: IaC
Què serà el següent?
Per tant, aquest és el final de l'article. Però en conclusió, m'agradaria establir alguns acords amb vosaltres.
Des del teu costat
Com deia al principi, m'agradaria que l'article fos d'utilitat pràctica i us ajudés a aplicar els coneixements adquirits en el treball real. Torno a afegir.
Però fins i tot després d'això, no us atureu, practiqueu, estudieu enllaços i llibres rellevants, descobriu com funciona a la vostra empresa, troba llocs millorables i participa-hi. Bona sort!
Del meu costat
Pel títol es pot veure que aquesta només era la primera part. Tot i que va resultar ser bastant gran, aquí encara no es tracten temes importants. A la segona part, penso mirar la infraestructura d'automatització en el context d'IOS. A causa de les restriccions d'Apple per executar simuladors iOS només en sistemes macOS, la nostra gamma de solucions s'ha reduït. Per exemple, no podem utilitzar Docker per executar el simulador o núvols públics per executar màquines virtuals. Però això no vol dir que no hi hagi altres alternatives. Intentaré mantenir-vos al dia amb solucions avançades i eines modernes!
A més, no he esmentat temes massa grans relacionats amb el seguiment. A la part 3, miraré les eines de supervisió d'infraestructura més populars i quines dades i mètriques cal tenir en compte.
I finalment. En el futur, tinc la intenció de publicar un curs de vídeo sobre la construcció d'infraestructura de prova i eines populars. Actualment, hi ha força cursos i conferències sobre DevOps a Internet, però tots els materials es presenten en el context del desenvolupament, no de l'automatització de proves. Sobre aquest tema, realment necessito comentaris sobre si aquest curs serà interessant i valuós per a la comunitat de provadors i enginyers d'automatització. Gràcies per endavant!
Font: www.habr.com