Parte 1: Web/Android
Nota: questo articolo è una traduzione in russo dell'articolo originale Tuttavia, tutte le illustrazioni, i collegamenti, le citazioni e i termini sono conservati nella lingua originale per evitare distorsioni del significato quando tradotti in russo. Ti auguro buon studio!
Attualmente, la specialità DevOps è una delle più richieste nel settore IT. Se apri siti di ricerca di lavoro popolari e filtri in base allo stipendio, vedrai che i lavori relativi a DevOps sono in cima all'elenco. Tuttavia, è importante capire che questo si riferisce principalmente a una posizione 'Senior', il che implica che il candidato abbia un elevato livello di competenze, conoscenza della tecnologia e degli strumenti. Ciò comporta anche un elevato grado di responsabilità associato al funzionamento ininterrotto della produzione. Tuttavia, abbiamo iniziato a dimenticare cosa sia DevOps. Inizialmente, non si trattava di una persona o di un dipartimento specifico. Se cerchiamo le definizioni di questo termine, troveremo molti nomi belli e corretti, come metodologia, pratiche, filosofia culturale, gruppo di concetti e così via.
La mia specializzazione è un ingegnere dell'automazione dei test (ingegnere dell'automazione QA), ma credo che non dovrebbe essere associata solo alla scrittura di test automatici o allo sviluppo dell'architettura del framework di test. Nel 2020 è essenziale anche la conoscenza delle infrastrutture di automazione. Ciò ti consente di organizzare tu stesso il processo di automazione, dall'esecuzione dei test alla fornitura di risultati a tutte le parti interessate in conformità con i tuoi obiettivi. Di conseguenza, le competenze DevOps sono indispensabili per portare a termine il lavoro. E tutto questo va bene, ma sfortunatamente c'è un problema (spoiler: questo articolo tenta di semplificare questo problema). Il punto è che DevOps è difficile. E questo è ovvio, perché le aziende non sono disposte a pagare molto per qualcosa che è facile da fare... Nel mondo DevOps, esiste un gran numero di strumenti, termini e pratiche che devono essere padroneggiati. Ciò è particolarmente difficile all'inizio di una carriera e dipende dall'esperienza tecnica accumulata.
Fonte:
Qui probabilmente finiremo con la parte introduttiva e ci concentreremo sullo scopo di questo articolo.
Di cosa parla questo articolo?
In questo articolo condividerò la mia esperienza nella creazione di un'infrastruttura di automazione dei test. Ci sono molte fonti di informazioni su Internet sui vari strumenti e su come utilizzarli, ma vorrei considerarli esclusivamente nel contesto dell'automazione. Credo che molti ingegneri dell'automazione abbiano familiarità con la situazione in cui nessuno tranne te esegue i test sviluppati o si preoccupa di mantenerli. Di conseguenza, i test diventano obsoleti e devi dedicare tempo ad aggiornarli. Ancora una volta, all'inizio di una carriera, questo può essere un compito piuttosto difficile: decidere saggiamente quali strumenti dovrebbero aiutare a eliminare un determinato problema, come selezionarli, configurarli e mantenerli. Alcuni tester si rivolgono a DevOps (umani) per chiedere aiuto e, siamo onesti, questo approccio funziona. In molti casi questa potrebbe essere l'unica opzione poiché non abbiamo visibilità su tutte le dipendenze. Ma come sappiamo, i DevOps sono persone molto impegnate, perché devono pensare all'infrastruttura, all'implementazione, al monitoraggio, ai microservizi e ad altri compiti simili dell'intera azienda a seconda dell'organizzazione/del team. Come di solito accade, l’automazione non è una priorità. In tal caso, dobbiamo cercare di fare tutto il possibile da parte nostra dall'inizio alla fine. Ciò ridurrà le dipendenze, accelererà il flusso di lavoro, migliorerà le nostre capacità e ci consentirà di vedere il quadro più ampio di ciò che sta accadendo.
L'articolo presenta gli strumenti più diffusi e diffusi e mostra passo dopo passo come utilizzarli per costruire un'infrastruttura di automazione. Ogni gruppo è rappresentato da strumenti che sono stati testati attraverso l'esperienza personale. Ma ciò non significa che devi usare la stessa cosa. Gli strumenti in sé non sono importanti, appaiono e diventano obsoleti. Il nostro compito ingegneristico è comprendere i principi di base: perché abbiamo bisogno di questo gruppo di strumenti e quali problemi di lavoro possiamo risolvere con il loro aiuto. Ecco perché alla fine di ogni sezione lascio collegamenti a strumenti simili che potrebbero essere utilizzati nella tua organizzazione.
Cosa non c'è in questo articolo
Ribadisco ancora una volta che l'articolo non riguarda strumenti specifici, quindi non saranno presenti inserimenti di codice dalla documentazione e descrizioni di comandi specifici. Ma alla fine di ogni sezione lascio collegamenti per uno studio dettagliato.
Questo viene fatto perché:
- questo materiale è molto facile da reperire in varie fonti (documentazione, libri, videocorsi);
- se iniziamo ad andare più in profondità, dovremo scrivere 10, 20, 30 parti di questo articolo (mentre i piani sono 2-3);
- Non voglio farti perdere tempo perché potresti voler utilizzare altri strumenti per raggiungere gli stessi obiettivi.
Pratica
Vorrei davvero che questo materiale fosse utile a ogni lettore, e non solo letto e dimenticato. In ogni studio, la pratica è una componente molto importante. Per questo mi sono preparato. Ci sono anche dei compiti che ti aspettano per assicurarti di non copiare senza pensarci le righe dei comandi che stai eseguendo.
План
step
Tecnologia
Strumenti
1
Esecuzione locale (preparare test demo web/Android ed eseguirli localmente)
Node.js, Selenio, Appio
2
Sistemi di controllo versione
Idiota
3
Containerizzazione
Docker, griglia Selenium, Selenoid (Web, Android)
4
CI/CD
CI Gitlab
5
Piattaforme cloud
Google Cloud Platform
6
Orchestrazione
kubernetes
7
Infrastruttura come codice (IaC)
Terraformazione, Ansible
Struttura di ogni sezione
Per mantenere la narrazione chiara, ogni sezione è descritta secondo il seguente schema:
- breve descrizione della tecnologia,
- valore per le infrastrutture di automazione,
- illustrazione dello stato attuale delle infrastrutture,
- link allo studio,
- strumenti simili.
1. Esegui i test localmente
Breve descrizione della tecnologia
Questo è solo un passaggio preparatorio per eseguire i test demo in locale e verificarne il superamento. Nella parte pratica viene utilizzato Node.js, ma anche il linguaggio di programmazione e la piattaforma non sono importanti e potete utilizzare quelli che si utilizzano nella vostra azienda.
Tuttavia, come strumenti di automazione, consiglio di utilizzare rispettivamente Selenium WebDriver per piattaforme Web e Appium per la piattaforma Android, poiché nei passaggi successivi utilizzeremo immagini Docker personalizzate per funzionare specificamente con questi strumenti. Inoltre, per quanto riguarda i requisiti lavorativi, questi strumenti sono i più richiesti sul mercato.
Come avrai notato, consideriamo solo test web e Android. Sfortunatamente, iOS è una storia completamente diversa (grazie Apple). Ho intenzione di mostrare soluzioni e pratiche relative a IOS nelle prossime parti.
Valore per l'infrastruttura di automazione
Dal punto di vista dell'infrastruttura, l'esecuzione locale non fornisce alcun valore. Controlla solo che i test vengano eseguiti sul computer locale nei browser e nei simulatori locali. Ma in ogni caso questo è un punto di partenza necessario.
Illustrazione dello stato attuale delle infrastrutture
Collegamenti da esplorare
Strumenti simili
- qualsiasi linguaggio di programmazione che ti piace insieme ai test Selenium/Appium;
- eventuali prove;
- qualsiasi corridore di prova.
2. Sistemi di controllo della versione (Git)
Breve descrizione della tecnologia
Non sarà una grande rivelazione per nessuno se dico che il controllo della versione è una parte estremamente importante dello sviluppo, sia in team che individualmente. Sulla base di varie fonti, si può affermare con certezza che Git è il rappresentante più popolare. Un sistema di controllo della versione offre molti vantaggi, come la condivisione del codice, l'archiviazione delle versioni, il ripristino dei rami precedenti, il monitoraggio della cronologia del progetto e i backup. Non discuteremo ogni punto in dettaglio, poiché sono sicuro che lo conosci molto bene e lo usi nel tuo lavoro quotidiano. Ma se all'improvviso no, allora ti consiglio di fermarti a leggere questo articolo e di colmare questa lacuna il prima possibile.
Valore per l'infrastruttura di automazione
E qui puoi porre una domanda ragionevole: “Perché ci parla di Git? Tutti lo sanno e lo usano sia per il codice di sviluppo che per quello di auto-test”. Avrai perfettamente ragione, ma in questo articolo parliamo di infrastrutture e questa sezione funge da anteprima per la sezione 7: “Infrastruttura come codice (IaC)”. Per noi questo significa che l'intera infrastruttura, compreso il test, viene descritta sotto forma di codice, in modo da poter applicare anche ad essa sistemi di controllo delle versioni e ottenere vantaggi simili a quelli dello sviluppo e dell'automazione del codice.
Esamineremo IaC in modo più dettagliato nel passaggio 7, ma anche adesso puoi iniziare a utilizzare Git localmente creando un repository locale. Il quadro generale verrà ampliato quando aggiungeremo un repository remoto all'infrastruttura.
Illustrazione dello stato attuale delle infrastrutture
Collegamenti da esplorare
Strumenti simili
3. Containerizzazione (Docker)
Breve descrizione della tecnologia
Per dimostrare come la containerizzazione abbia cambiato le regole del gioco, torniamo indietro nel tempo di qualche decennio. Allora, le persone acquistavano e utilizzavano macchine server per eseguire applicazioni. Ma nella maggior parte dei casi le risorse necessarie per l’avvio non erano note in anticipo. Di conseguenza, le aziende hanno speso soldi per l’acquisto di server costosi e potenti, ma parte di questa capacità non è stata completamente utilizzata.
La fase successiva dell'evoluzione sono state le macchine virtuali (VM), che hanno risolto il problema dello spreco di denaro su risorse inutilizzate. Questa tecnologia ha consentito di eseguire applicazioni indipendentemente l'una dall'altra all'interno dello stesso server, allocando spazio completamente isolato. Ma sfortunatamente ogni tecnologia ha i suoi svantaggi. L'esecuzione di una macchina virtuale richiede un sistema operativo completo, che consuma CPU, RAM, spazio di archiviazione e, a seconda del sistema operativo, è necessario tenere conto dei costi di licenza. Questi fattori influiscono sulla velocità di caricamento e rendono difficile la trasportabilità.
E ora veniamo alla containerizzazione. Ancora una volta, questa tecnologia risolve il problema precedente, poiché i container non utilizzano un sistema operativo completo, il che libera una grande quantità di risorse e fornisce una soluzione veloce e flessibile per la portabilità.
Naturalmente, la tecnologia di containerizzazione non è una novità ed è stata introdotta per la prima volta alla fine degli anni ’70. A quei tempi furono effettuate molte ricerche, sviluppi e tentativi. Ma è stato Docker ad adattare questa tecnologia e a renderla facilmente accessibile alle masse. Al giorno d’oggi, quando si parla di container, nella maggior parte dei casi si intende Docker. Quando parliamo di contenitori Docker, intendiamo contenitori Linux. Possiamo utilizzare i sistemi Windows e macOS per eseguire i container, ma è importante capire che in questo caso appare un livello aggiuntivo. Ad esempio, Docker su Mac esegue silenziosamente i contenitori all'interno di una VM Linux leggera. Torneremo su questo argomento quando discuteremo dell'esecuzione di emulatori Android all'interno dei contenitori, quindi qui c'è una sfumatura molto importante che deve essere discussa in modo più dettagliato.
Valore per l'infrastruttura di automazione
Abbiamo scoperto che la containerizzazione e Docker sono interessanti. Consideriamolo nel contesto dell'automazione, perché ogni strumento o tecnologia deve risolvere un problema. Descriviamo gli ovvi problemi dell'automazione dei test nel contesto dei test dell'interfaccia utente:
- un numero enorme di dipendenze durante l'installazione di Selenium e soprattutto di Appium;
- problemi di compatibilità tra versioni di browser, simulatori e driver;
- mancanza di spazio isolato per browser/simulatori, che è particolarmente critico per l'esecuzione parallela;
- difficile da gestire e mantenere se è necessario eseguire 10, 50, 100 o anche 1000 browser contemporaneamente.
Ma poiché Selenium è lo strumento di automazione più popolare e Docker è lo strumento di containerizzazione più popolare, non dovrebbe sorprendere che qualcuno abbia provato a combinarli per creare un potente strumento per risolvere i problemi sopra menzionati. Consideriamo tali soluzioni in modo più dettagliato.
Griglia di selenio nella finestra mobile
Questo strumento è il più popolare nel mondo Selenium per eseguire più browser su più macchine e gestirli da un hub centrale. Per iniziare, è necessario registrare almeno 2 parti: Hub e Nodo/i. L'Hub è un nodo centrale che riceve tutte le richieste dai test e le distribuisce ai nodi appropriati. Per ciascun Nodo possiamo configurare una configurazione specifica, ad esempio specificando il browser desiderato e la sua versione. Tuttavia, dobbiamo comunque occuparci noi stessi dei driver del browser compatibili e installarli sui nodi desiderati. Per questo motivo la griglia Selenium non viene utilizzata nella sua forma pura, tranne quando dobbiamo lavorare con browser che non possono essere installati sul sistema operativo Linux. Per tutti gli altri casi, una soluzione significativamente flessibile e corretta sarebbe quella di utilizzare le immagini Docker per eseguire hub e nodi della griglia Selenium. Questo approccio semplifica notevolmente la gestione dei nodi, poiché possiamo selezionare l'immagine di cui abbiamo bisogno con versioni compatibili di browser e driver già installati.
Nonostante le recensioni negative sulla stabilità, soprattutto quando si esegue un gran numero di nodi in parallelo, la griglia Selenium è ancora lo strumento più popolare per eseguire test Selenium in parallelo. È importante notare che vari miglioramenti e modifiche di questo strumento appaiono costantemente in open source, per combattere vari colli di bottiglia.
Selenoide per il Web
Questo strumento rappresenta una svolta nel mondo di Selenium poiché funziona immediatamente e ha reso la vita di molti ingegneri dell'automazione molto più semplice. Prima di tutto, questa non è un'altra modifica della griglia del selenio. Invece, gli sviluppatori hanno creato una versione completamente nuova di Selenium Hub a Golang, che, combinata con immagini Docker leggere per vari browser, ha dato slancio allo sviluppo dell'automazione dei test. Inoltre, nel caso di Selenium Grid, dobbiamo determinare in anticipo tutti i browser richiesti e le loro versioni, il che non è un problema quando si lavora con un solo browser. Ma quando si tratta di più browser supportati, Selenoid è la soluzione numero uno grazie alla sua funzionalità "browser on demand". Tutto ciò che ci viene richiesto è scaricare in anticipo le immagini necessarie con i browser e aggiornare il file di configurazione con cui interagisce Selenoid. Dopo che Selenoid riceve una richiesta dai test, avvierà automaticamente il contenitore desiderato con il browser desiderato. Una volta completato il test, Selenoid ritirerà il contenitore, liberando così risorse per richieste future. Questo approccio elimina completamente il noto problema del "degrado dei nodi" che spesso incontriamo nella griglia del selenio.
Ma, ahimè, Selenoid non è ancora la soluzione miracolosa. Abbiamo la funzionalità "browser su richiesta", ma la funzionalità "risorse su richiesta" non è ancora disponibile. Per utilizzare Selenoid dobbiamo distribuirlo su un hardware fisico o su una VM, il che significa che dobbiamo sapere in anticipo quante risorse devono essere allocate. Immagino che questo non sia un problema per piccoli progetti che eseguono 10, 20 o anche 30 browser in parallelo. E se ne avessimo bisogno di 100, 500, 1000 e più? Non ha senso mantenere e pagare continuamente così tante risorse. Nelle sezioni 5 e 6 di questo articolo parleremo di soluzioni che consentono di crescere, riducendo così in modo significativo i costi aziendali.
Selenoide per Android
Dopo il successo di Selenoid come strumento di automazione web, le persone volevano qualcosa di simile per Android. Ed è successo: Selenoid è stato rilasciato con il supporto Android. Dal punto di vista dell'utente di alto livello, il principio di funzionamento è simile all'automazione web. L'unica differenza è che invece dei contenitori del browser, Selenoid esegue i contenitori dell'emulatore Android. Secondo me, questo è attualmente lo strumento gratuito più potente per eseguire test Android in parallelo.
Non vorrei davvero parlare degli aspetti negativi di questo strumento, dato che mi piace davvero tanto. Tuttavia, ci sono gli stessi svantaggi che si applicano all’automazione web e sono associati alla scalabilità. Oltre a questo, dobbiamo parlare di un’altra limitazione che potrebbe sorprendere se configuriamo lo strumento per la prima volta. Per eseguire le immagini Android, abbiamo bisogno di una macchina fisica o VM con supporto di virtualizzazione nidificata. Nella guida pratica, mostro come abilitarlo su una VM Linux. Tuttavia, se sei un utente macOS e desideri distribuire Selenoid localmente, non sarà possibile eseguire test Android. Ma puoi sempre eseguire una VM Linux localmente con la "virtualizzazione annidata" configurata e distribuire Selenoid all'interno.
Illustrazione dello stato attuale delle infrastrutture
Nel contesto di questo articolo, aggiungeremo 2 strumenti per illustrare l'infrastruttura. Si tratta della griglia Selenium per i test web e Selenoid per i test Android. Nel tutorial di GitHub ti mostrerò anche come utilizzare Selenoid per eseguire test web.
Collegamenti da esplorare
Strumenti simili
- Esistono altri strumenti di containerizzazione, ma Docker è il più popolare. Se vuoi provare qualcos'altro, tieni presente che gli strumenti che abbiamo trattato per l'esecuzione dei test Selenium in parallelo non funzioneranno immediatamente.
- Come già detto, ci sono molte modifiche alla griglia del selenio, ad esempio,.
4.CI/CD
Breve descrizione della tecnologia
La pratica dell'integrazione continua è piuttosto popolare nello sviluppo ed è alla pari con i sistemi di controllo della versione. Nonostante ciò, ritengo che ci sia confusione nella terminologia. In questo paragrafo vorrei descrivere 3 modifiche di questa tecnologia dal mio punto di vista. Su internet troverai molti articoli con interpretazioni diverse, ed è assolutamente normale che la tua opinione sia diversa. La cosa più importante è che tu sia sulla stessa lunghezza d’onda con i tuoi colleghi.
Quindi, ci sono 3 termini: CI - Continuous Integration, CD - Continuous Delivery e ancora CD - Continuous Deployment. (Di seguito userò questi termini in inglese). Ogni modifica aggiunge diversi passaggi aggiuntivi alla pipeline di sviluppo. Ma la parola continuo (continua) è la cosa più importante. In questo contesto intendiamo qualcosa che accade dall'inizio alla fine, senza interruzioni o interventi manuali. Diamo un'occhiata a CI & CD e CD in questo contesto.
- Integrazione continua questo è il passo iniziale dell'evoluzione. Dopo aver inviato il nuovo codice al server, ci aspettiamo di ricevere un rapido feedback che le nostre modifiche siano ok. In genere, la CI include l'esecuzione di strumenti di analisi del codice statico e test API interni/unità, che ci consentono di ottenere informazioni sul nostro codice in pochi secondi/minuti.
- Consegna continua è un passaggio più avanzato in cui eseguiamo test di integrazione/interfaccia utente. Tuttavia, in questa fase non otteniamo risultati così rapidamente come con la CI. Innanzitutto, questi tipi di test richiedono più tempo per essere completati. In secondo luogo, prima del lancio, dobbiamo implementare le nostre modifiche nell'ambiente di test/staging. Inoltre, se parliamo di sviluppo mobile, appare un passaggio aggiuntivo per creare una build della nostra applicazione.
- Distribuzione Continua presuppone che rilasciamo automaticamente le nostre modifiche alla produzione se tutti i test di accettazione sono stati superati nelle fasi precedenti. Oltre a questo, dopo la fase di rilascio, è possibile configurare varie fasi, come l'esecuzione di test di fumo sulla produzione e la raccolta delle metriche di interesse. La distribuzione continua è possibile solo con una buona copertura tramite test automatizzati. Se sono necessari interventi manuali, inclusi i test, ciò non è più necessario Educazione (continuo). Quindi possiamo dire che la nostra pipeline rispetta solo la pratica della Continuous Delivery.
Valore per l'infrastruttura di automazione
In questa sezione, dovrei chiarire che quando parliamo di test dell'interfaccia utente end-to-end, significa che dovremmo distribuire le nostre modifiche e i servizi associati agli ambienti di test. Integrazione continua: il processo non è applicabile per questa attività e dobbiamo occuparci di implementare almeno le pratiche di consegna continua. La distribuzione continua ha senso anche nel contesto dei test dell'interfaccia utente se li eseguiremo in produzione.
E prima di guardare l'illustrazione del cambiamento dell'architettura, voglio spendere alcune parole su GitLab CI. A differenza di altri strumenti CI/CD, GitLab fornisce un repository remoto e molte altre funzionalità aggiuntive. Pertanto, GitLab è più che CI. Include gestione del codice sorgente, gestione Agile, pipeline CI/CD, strumenti di registrazione e raccolta di metriche pronte all'uso. L'architettura GitLab è composta da Gitlab CI/CD e GitLab Runner. Ecco una breve descrizione dal sito ufficiale:
Gitlab CI/CD è un'applicazione web con un'API che memorizza il suo stato in un database, gestisce progetti/build e fornisce un'interfaccia utente. GitLab Runner è un'applicazione che elabora le build. Può essere distribuito separatamente e funziona con GitLab CI/CD tramite un'API. Per i test in esecuzione sono necessari sia l'istanza Gitlab che Runner.
Illustrazione dello stato attuale delle infrastrutture
Collegamenti da esplorare
Strumenti simili
- E molti altri
5. Piattaforme cloud
Breve descrizione della tecnologia
In questa sezione parleremo di una tendenza popolare chiamata "cloud pubblici". Nonostante gli enormi vantaggi offerti dalle tecnologie di virtualizzazione e containerizzazione sopra descritte, abbiamo ancora bisogno di risorse informatiche. Le aziende acquistano server costosi o affittano data center, ma in questo caso è necessario fare calcoli (a volte irrealistici) di quante risorse avremo bisogno, se le utilizzeremo 24 ore su 7, XNUMX giorni su XNUMX e per quali scopi. Ad esempio, la produzione richiede un server in funzione XNUMX ore su XNUMX, XNUMX giorni su XNUMX, ma abbiamo bisogno di risorse simili per i test al di fuori dell'orario di lavoro? Dipende anche dal tipo di test da eseguire. Un esempio potrebbero essere i test di carico/stress che prevediamo di eseguire durante le ore non lavorative per ottenere risultati il giorno successivo. Ma sicuramente la disponibilità del server XNUMX ore su XNUMX, XNUMX giorni su XNUMX non è richiesta per i test automatizzati end-to-end e soprattutto non per gli ambienti di test manuali. In tali situazioni, sarebbe bene ottenere tutte le risorse necessarie su richiesta, utilizzarle e smettere di pagare quando non sono più necessarie. Inoltre, sarebbe fantastico riceverli istantaneamente facendo pochi clic del mouse o eseguendo un paio di script. Questo è lo scopo per cui vengono utilizzati i cloud pubblici. Diamo un'occhiata alla definizione:
“Il cloud pubblico è definito come servizi informatici offerti da fornitori terzi tramite la rete Internet pubblica, rendendoli disponibili a chiunque voglia utilizzarli o acquistarli. Possono essere gratuiti o venduti su richiesta, consentendo ai clienti di pagare solo in base all'utilizzo per i cicli di CPU, lo spazio di archiviazione o la larghezza di banda consumati."
Si ritiene che i cloud pubblici siano costosi. Ma la loro idea chiave è ridurre i costi aziendali. Come accennato in precedenza, i cloud pubblici ti consentono di ottenere risorse on demand e di pagare solo per il tempo in cui le utilizzi. Inoltre, a volte dimentichiamo che i dipendenti ricevono uno stipendio e che anche gli specialisti sono una risorsa costosa. Va tenuto presente che i cloud pubblici facilitano notevolmente il supporto dell’infrastruttura, consentendo agli ingegneri di concentrarsi su compiti più importanti.
Valore per l'infrastruttura di automazione
Di quali risorse specifiche abbiamo bisogno per i test dell'interfaccia utente end-to-end? Fondamentalmente si tratta di macchine virtuali o cluster (parleremo di Kubernetes nella prossima sezione) per l'esecuzione di browser ed emulatori. Più browser ed emulatori vogliamo eseguire contemporaneamente, più CPU e memoria saranno necessarie e più soldi dovremo pagare per averli. Pertanto, i cloud pubblici nel contesto dell'automazione dei test ci consentono di eseguire un gran numero (100, 200, 1000...) di browser/emulatori su richiesta, ottenere risultati dei test il più rapidamente possibile e smettere di pagare per tali operazioni ad alta intensità di risorse. energia.
I fornitori di servizi cloud più popolari sono Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). La guida pratica fornisce esempi su come utilizzare GCP, ma in generale non importa cosa utilizzi per le attività di automazione. Forniscono tutti approssimativamente la stessa funzionalità. In genere, per selezionare un fornitore, la direzione si concentra sull'intera infrastruttura dell'azienda e sui requisiti aziendali, cosa che va oltre lo scopo di questo articolo. Per gli ingegneri dell'automazione, sarà più interessante confrontare l'uso dei fornitori di servizi cloud con l'uso di piattaforme cloud specifiche per scopi di test, come Sauce Labs, BrowserStack, BitBar e così via. Allora facciamolo anche noi! Secondo me, Sauce Labs è la farm di cloud testing più famosa, motivo per cui l'ho utilizzata per il confronto.
GCP vs Sauce Labs per scopi di automazione:
Immaginiamo di dover eseguire 8 test web e 8 test Android contemporaneamente. Per questo utilizzeremo GCP ed eseguiremo 2 macchine virtuali con Selenoid. Sul primo solleveremo 8 contenitori con i browser. Sul secondo ci sono 8 contenitori con emulatori. Diamo un'occhiata ai prezzi:
Per eseguire un contenitore con Chrome, abbiamo bisogno n1-standard-1 auto. Nel caso di Android lo sarà n1-standard-4 per un emulatore. In effetti, un modo più flessibile ed economico è impostare valori utente specifici per CPU/Memoria, ma al momento questo non è importante per il confronto con Sauce Labs.
Ed ecco le tariffe per l'utilizzo di Sauce Labs:
Credo che tu abbia già notato la differenza, ma fornirò comunque una tabella con i calcoli per il nostro compito:
Risorse richieste
Mensile
Ore lavorative(8:8 - XNUMX:XNUMX)
Ore lavorative+ Prerilasciabile
GCP per il Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 giorni * 12 ore * 0.38 = $ 104.88
23 giorni * 12 ore * 0.08 = $ 22.08
Sauce Labs per il Web
Test paralleli di Virtual Cloud8
$1.559
-
-
GCP per Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 giorni * 12 ore * 1.52 = $ 419.52
23 giorni * 12 ore * 0.32 = $ 88.32
Salsa Labs per Android
Test paralleli di Real Device Cloud 8
$1.999
-
-
Come puoi vedere, la differenza di costo è enorme, soprattutto se esegui i test solo durante un periodo lavorativo di dodici ore. Ma puoi ridurre ulteriormente i costi se utilizzi macchine prerilasciabili. Che cos'è?
Una VM prerilasciabile è un'istanza che puoi creare ed eseguire a un prezzo molto inferiore rispetto alle istanze normali. Tuttavia, Compute Engine potrebbe terminare (precedere) queste istanze se richiede l'accesso a tali risorse per altre attività. Le istanze prerilasciabili rappresentano la capacità di Compute Engine in eccesso, quindi la loro disponibilità varia in base all'utilizzo.
Se le tue app sono tolleranti agli errori e possono sopportare possibili prelazioni delle istanze, le istanze prerilasciabili possono ridurre significativamente i costi di Compute Engine. Ad esempio, i processi di elaborazione batch possono essere eseguiti su istanze prerilasciabili. Se alcune di queste istanze terminano durante l'elaborazione, il lavoro rallenta ma non si arresta completamente. Le istanze prerilasciabili completano le attività di elaborazione batch senza aggiungere ulteriore carico di lavoro alle istanze esistenti e senza richiedere il pagamento del prezzo intero per istanze normali aggiuntive.
E non è ancora finita! In realtà, sono sicuro che nessuno esegue test per 12 ore senza interruzioni. E se è così, puoi avviare e arrestare automaticamente le macchine virtuali quando non sono necessarie. Il tempo di utilizzo effettivo può essere ridotto a 6 ore al giorno. Quindi il pagamento nell'ambito della nostra attività diminuirà a $ 11 al mese per 8 browser. Non è meraviglioso? Ma con le macchine prerilasciabili dobbiamo essere attenti e preparati alle interruzioni e all'instabilità, sebbene queste situazioni possano essere previste e gestite tramite software. Ne vale la pena!
Ma non sto affatto dicendo "non utilizzare mai cloud test farm". Hanno una serie di vantaggi. Prima di tutto, questa non è solo una macchina virtuale, ma una soluzione di automazione dei test a tutti gli effetti con una serie di funzionalità pronte all'uso: accesso remoto, registri, screenshot, registrazione video, vari browser e dispositivi mobili fisici. In molte situazioni, questa può essere un’alternativa essenziale e chic. Le piattaforme di test sono particolarmente utili per l'automazione IOS, quando i cloud pubblici possono offrire solo sistemi Linux/Windows. Ma di iOS parleremo nei prossimi articoli. Consiglio di guardare sempre la situazione e di partire dai compiti: in alcuni casi è più economico ed efficiente utilizzare i cloud pubblici, in altri le piattaforme di test valgono sicuramente i soldi spesi.
Illustrazione dello stato attuale delle infrastrutture
Collegamenti da esplorare
Strumenti simili:
6. Orchestrazione
Breve descrizione della tecnologia
Ho una buona notizia: siamo quasi alla fine dell’articolo! Al momento, la nostra infrastruttura di automazione è costituita da test Web e Android, che eseguiamo in parallelo tramite GitLab CI, utilizzando strumenti abilitati per Docker: Selenium grid e Selenoid. Inoltre, utilizziamo macchine virtuali create tramite GCP per ospitare contenitori con browser ed emulatori. Per ridurre i costi, avviamo queste macchine virtuali solo su richiesta e le arrestiamo quando non vengono eseguiti i test. C’è qualcos’altro che può migliorare la nostra infrastruttura? La risposta è si! Scopri Kubernetes (K8)!
Innanzitutto, esaminiamo la relazione tra le parole orchestrazione, cluster e Kubernetes. Ad alto livello, l'orchestrazione è il sistema che distribuisce e gestisce le applicazioni. Per l'automazione dei test, tali applicazioni containerizzate sono Selenium grid e Selenoid. Docker e K8 si completano a vicenda. Il primo viene utilizzato per la distribuzione dell'applicazione, il secondo per l'orchestrazione. A sua volta, K8s è un cluster. Il compito del cluster è utilizzare le VM come nodi, che consentono di installare varie funzionalità, programmi e servizi all'interno di un server (cluster). Se uno qualsiasi dei nodi si guasta, gli altri nodi lo riprenderanno, il che garantisce il funzionamento ininterrotto della nostra applicazione. Oltre a questo, K8s dispone di importanti funzionalità legate allo scaling, grazie alle quali otteniamo automaticamente la quantità ottimale di risorse in base al carico e ai limiti impostati.
In verità, distribuire manualmente Kubernetes da zero non è affatto un compito banale. Lascerò un link alla famosa guida pratica "Kubernetes The Hard Way" e, se sei interessato, puoi esercitarti. Ma fortunatamente esistono metodi e strumenti alternativi. Il modo più semplice è utilizzare Google Kubernetes Engine (GKE) in GCP, che ti consentirà di ottenere un cluster già pronto in pochi clic. Consiglio di utilizzare questo approccio per iniziare l'apprendimento, poiché ti consentirà di concentrarti sull'apprendimento di come utilizzare i K8 per le tue attività invece di imparare come i componenti interni dovrebbero essere integrati tra loro.
Valore per l'infrastruttura di automazione
Diamo un'occhiata ad alcune caratteristiche significative fornite dal K8:
- distribuzione dell'applicazione: utilizzo di un cluster multi-nodo anziché di VM;
- ridimensionamento dinamico: riduce il costo delle risorse utilizzate solo su richiesta;
- self-healing: ripristino automatico dei pod (a seguito del quale vengono ripristinati anche i contenitori);
- implementazione di aggiornamenti e rollback delle modifiche senza tempi di inattività: l'aggiornamento di strumenti, browser ed emulatori non interrompe il lavoro degli utenti attuali
Ma il K8 non è ancora una soluzione miracolosa. Per comprendere tutti i vantaggi e i limiti nell’ambito degli strumenti che stiamo considerando (Selenium grid, Selenoid), discuteremo brevemente della struttura dei K8. Il cluster contiene due tipi di nodi: nodi master e nodi di lavoro. I Master Node sono responsabili delle decisioni di gestione, distribuzione e pianificazione. I nodi di lavoro sono i luoghi in cui vengono eseguite le applicazioni. I nodi contengono anche un ambiente runtime del contenitore. Nel nostro caso si tratta di Docker, responsabile delle operazioni relative ai container. Ma esistono anche soluzioni alternative, ad esempio. È importante comprendere che il ridimensionamento o la riparazione automatica non si applicano direttamente ai contenitori. Ciò viene implementato aggiungendo/diminuendo il numero di pod, che a loro volta contengono contenitori (di solito un contenitore per pod, ma a seconda dell'attività potrebbero essercene di più). La gerarchia di alto livello è costituita da nodi di lavoro, all'interno dei quali sono presenti i pod, all'interno dei quali vengono sollevati i contenitori.
La funzionalità di dimensionamento è fondamentale e può essere applicata sia ai nodi all'interno di un pool di nodi del cluster sia ai pod all'interno di un nodo. Esistono 2 tipi di ridimensionamento che si applicano sia ai nodi che ai pod. Il primo tipo è orizzontale: il ridimensionamento avviene aumentando il numero di nodi/pod. Questo tipo è più preferibile. Il secondo tipo è, di conseguenza, verticale. Il ridimensionamento viene effettuato aumentando la dimensione dei nodi/pod e non il loro numero.
Ora diamo un'occhiata ai nostri strumenti nel contesto dei termini di cui sopra.
Griglia al selenio
Come accennato in precedenza, la griglia Selenium è uno strumento molto popolare e non sorprende che sia stata containerizzata. Pertanto, non sorprende che la griglia di selenio possa essere implementata nei K8. Un esempio di come farlo può essere trovato nel repository ufficiale di K8s. Come al solito allego i link alla fine della sezione. Inoltre, la guida pratica mostra come eseguire questa operazione in Terraform. Sono inoltre disponibili istruzioni su come ridimensionare il numero di pod che contengono contenitori del browser. Ma la funzione di ridimensionamento automatico nel contesto dei K8 non è ancora un compito del tutto ovvio. Quando ho iniziato a studiare, non ho trovato indicazioni o raccomandazioni pratiche. Dopo diversi studi ed esperimenti con il supporto del team DevOps, abbiamo scelto l'approccio di creare contenitori con i browser necessari all'interno di un pod, che si trova all'interno di un nodo di lavoro. Questo metodo ci consente di applicare la strategia di ridimensionamento orizzontale dei nodi aumentandone il numero. Spero che questo cambi in futuro e vedremo sempre più descrizioni di approcci migliori e soluzioni già pronte, soprattutto dopo il rilascio di Selenium grid 4 con un'architettura interna modificata.
Selenoide:
L'implementazione dei selenoidi nei K8 è attualmente la più grande delusione. Non sono compatibili. In teoria, possiamo sollevare un contenitore Selenoid all'interno di un pod, ma quando Selenoid inizierà a lanciare i contenitori con i browser, saranno ancora all'interno dello stesso pod. Ciò rende impossibile la scalabilità e, di conseguenza, il lavoro di Selenoid all'interno di un cluster non sarà diverso dal lavoro all'interno di una macchina virtuale. Fine della storia.
Moon: :
Conoscendo questo collo di bottiglia quando si lavora con Selenoid, gli sviluppatori hanno rilasciato uno strumento più potente chiamato Moon. Questo strumento è stato originariamente progettato per funzionare con Kubernetes e, di conseguenza, la funzionalità di scalabilità automatica può e deve essere utilizzata. Oltretutto direi che al momento lo è единственный uno strumento nel mondo Selenium, che ha il supporto nativo del cluster K8 pronto all'uso (non più disponibile, vedere lo strumento successivo ). Le caratteristiche principali di Moon che forniscono questo supporto sono:
Completamente apolide. Selenoid memorizza in memoria le informazioni sulle sessioni del browser attualmente in esecuzione. Se per qualche motivo il processo si blocca, tutte le sessioni in esecuzione andranno perse. Moon, al contrario, non ha uno stato interno e può essere replicato tra i data center. Le sessioni del browser rimangono attive anche se una o più repliche non funzionano.
Quindi Moon è un’ottima soluzione, ma c’è un problema: non è gratuito. Il prezzo dipende dal numero di sessioni. Puoi eseguire solo 0-4 sessioni gratuitamente, il che non è particolarmente utile. Ma a partire dalla quinta sessione dovrai pagare 5$ per ciascuna. La situazione può variare da azienda ad azienda, ma nel nostro caso utilizzare Moon è inutile. Come ho descritto sopra, possiamo eseguire VM con Selenium Grid su richiesta o aumentare il numero di nodi nel cluster. Per circa una pipeline, lanciamo 500 browser e interrompiamo tutte le risorse una volta completati i test. Se utilizzassimo Moon, dovremmo pagare altri 500 x 5 = $ 2500 al mese, indipendentemente dalla frequenza con cui eseguiamo i test. Ancora una volta, non sto dicendo di non usare Moon. Per le tue attività, questa può essere una soluzione indispensabile, ad esempio, se hai molti progetti/team nella tua organizzazione e hai bisogno di un enorme cluster comune per tutti. Come sempre, lascio un collegamento alla fine e consiglio di eseguire tutti i calcoli necessari nel contesto del tuo compito.
Callisto: (Attenzione! Questo non è nell'articolo originale ed è contenuto solo nella traduzione russa)
Come ho detto, il selenio è uno strumento molto popolare e il campo IT si sta sviluppando molto rapidamente. Mentre stavo lavorando alla traduzione, è apparso sul web un nuovo promettente strumento chiamato Callisto (ciao Cypress e altri assassini del selenio). Funziona in modo nativo con K8 e consente di eseguire contenitori Selenoid in pod, distribuiti su nodi. Tutto funziona immediatamente, inclusa la scalabilità automatica. Fantastico, ma da testare. Sono già riuscito a distribuire questo strumento ed eseguire diversi esperimenti. Ma è troppo presto per trarre conclusioni, dopo aver ricevuto risultati a distanza, forse farò un ripasso nei prossimi articoli. Per ora lascio solo link per ricerche indipendenti.
Illustrazione dello stato attuale delle infrastrutture
Collegamenti da esplorare
Strumenti simili
7. Infrastruttura come codice (IaC)
Breve descrizione della tecnologia
E ora arriviamo all'ultima sezione. In genere, questa tecnologia e le attività correlate non sono di responsabilità degli ingegneri dell'automazione. E ci sono ragioni per questo. In primo luogo, in molte organizzazioni, le questioni infrastrutturali sono sotto il controllo del dipartimento DevOps e ai team di sviluppo non interessa veramente ciò che fa funzionare la pipeline e come tutto ciò che è connesso ad essa deve essere supportato. In secondo luogo, siamo onesti, la pratica dell'Infrastructure as Code (IaC) non è ancora adottata in molte aziende. Ma è sicuramente diventata una tendenza popolare ed è importante cercare di essere coinvolti nei processi, negli approcci e negli strumenti ad essa associati. O almeno rimani aggiornato.
Cominciamo con la motivazione per utilizzare questo approccio. Abbiamo già discusso del fatto che per eseguire test in GitlabCI, avremo bisogno come minimo delle risorse per eseguire Gitlab Runner. E per eseguire contenitori con browser/emulatori, dobbiamo prenotare una VM o un cluster. Oltre a testare le risorse, abbiamo bisogno di una notevole quantità di capacità per supportare ambienti di sviluppo, gestione temporanea e produzione, che includono anche database, pianificazioni automatiche, configurazioni di rete, bilanciatori del carico, diritti utente e così via. La questione fondamentale è lo sforzo necessario per sostenere tutto questo. Esistono diversi modi in cui possiamo apportare modifiche e implementare aggiornamenti. Ad esempio, nel contesto di GCP, possiamo utilizzare la console dell'interfaccia utente nel browser ed eseguire tutte le azioni facendo clic sui pulsanti. Un'alternativa sarebbe utilizzare le chiamate API per interagire con le entità cloud o utilizzare l'utilità della riga di comando gcloud per eseguire le manipolazioni desiderate. Ma con un numero davvero elevato di entità ed elementi infrastrutturali diversi, diventa difficile o addirittura impossibile eseguire manualmente tutte le operazioni. Inoltre, tutte queste azioni manuali sono incontrollabili. Non possiamo sottoporli a revisione prima dell'esecuzione, utilizzare un sistema di controllo della versione e ripristinare rapidamente le modifiche che hanno portato all'incidente. Per risolvere tali problemi, gli ingegneri hanno creato e creano script bash/shell automatici, che non sono molto migliori dei metodi precedenti, poiché non sono così facili da leggere, comprendere, mantenere e modificare rapidamente in uno stile procedurale.
In questo articolo e nella guida pratica utilizzo 2 strumenti relativi alla pratica IaC. Questi sono Terraform e Ansible. Alcune persone credono che non abbia senso usarli contemporaneamente, poiché la loro funzionalità è simile e sono intercambiabili. Ma il fatto è che inizialmente vengono assegnati compiti completamente diversi. E il fatto che questi strumenti dovrebbero completarsi a vicenda è stato confermato in una presentazione congiunta degli sviluppatori in rappresentanza di HashiCorp e RedHat. La differenza concettuale è che Terraform è uno strumento di provisioning per la gestione dei server stessi. Mentre Ansible è uno strumento di gestione della configurazione il cui compito è installare, configurare e gestire il software su questi server.
Un'altra caratteristica distintiva chiave di questi strumenti è lo stile di codifica. A differenza di bash e Ansible, Terraform utilizza uno stile dichiarativo basato su una descrizione dello stato finale desiderato da raggiungere come risultato dell'esecuzione. Ad esempio, se creeremo 10 VM e applicheremo le modifiche tramite Terraform, otterremo 10 VM. Se eseguiamo nuovamente lo script, non accadrà nulla poiché abbiamo già 10 VM e Terraform lo sa perché memorizza lo stato attuale dell'infrastruttura in un file di stato. Ma Ansible utilizza un approccio procedurale e, se gli chiedi di creare 10 VM, al primo avvio otterremo 10 VM, in modo simile a Terraform. Ma dopo il riavvio avremo già 20 VM. Questa è la differenza importante. Nello stile procedurale, non memorizziamo lo stato corrente e descriviamo semplicemente una sequenza di passaggi che devono essere eseguiti. Naturalmente, possiamo gestire varie situazioni, aggiungere diversi controlli sull'esistenza delle risorse e sullo stato attuale, ma non ha senso perdere tempo e impegnarsi per controllare questa logica. Inoltre, ciò aumenta il rischio di commettere errori.
Riassumendo tutto quanto sopra, possiamo concludere che Terraform e la notazione dichiarativa sono uno strumento più adatto per il provisioning dei server. Ma è meglio delegare il lavoro di gestione della configurazione ad Ansible. Detto questo, diamo un'occhiata ai casi d'uso nel contesto dell'automazione.
Valore per l'infrastruttura di automazione
L’unica cosa importante da capire qui è che l’infrastruttura di automazione dei test dovrebbe essere considerata come parte dell’intera infrastruttura aziendale. Ciò significa che tutte le pratiche IaC devono essere applicate a livello globale alle risorse dell’intera organizzazione. Chi ne è responsabile dipende dai vostri processi. Il team DevOps è più esperto in questi problemi e vede il quadro completo di ciò che sta accadendo. Tuttavia, gli ingegneri del QA sono maggiormente coinvolti nel processo di automazione degli edifici e nella struttura della pipeline, il che consente loro di vedere meglio tutti i cambiamenti richiesti e le opportunità di miglioramento. L'opzione migliore è lavorare insieme, scambiare conoscenze e idee per ottenere il risultato atteso.
Ecco alcuni esempi di utilizzo di Terraform e Ansible nel contesto dell'automazione dei test e degli strumenti di cui abbiamo discusso in precedenza:
1. Descrivere le caratteristiche e i parametri necessari delle VM e dei cluster utilizzando Terraform.
2. Utilizzando Ansible, installare gli strumenti necessari per il test: docker, Selenoid, Selenium Grid e scaricare le versioni richieste di browser/emulatori.
3. Utilizzando Terraform, descrivere le caratteristiche della VM in cui verrà avviato GitLab Runner.
4. Installa GitLab Runner e gli strumenti di accompagnamento necessari utilizzando Ansible, imposta le impostazioni e le configurazioni.
Illustrazione dello stato attuale delle infrastrutture
Link da esplorare:
Strumenti simili
Riassumiamo!
step
Tecnologia
Strumenti
Valore per l'infrastruttura di automazione
1
Esecuzione locale
Node.js, Selenio, Appio
- Gli strumenti più popolari per web e mobile
- Supporta molte lingue e piattaforme (incluso Node.js)
2
Sistemi di controllo versione
Idiota
- Vantaggi simili con il codice di sviluppo
3
Containerizzazione
Docker, griglia Selenium, Selenoid (Web, Android)
- Esecuzione di test in parallelo
- Ambienti isolati
- Aggiornamenti di versione semplici e flessibili
- Arresto dinamico delle risorse inutilizzate
- Facile da configurare
4
CI/CD
CI Gitlab
- Testa parte della pipeline
- страя обратная связь
- Visibilità per l'intera azienda/team
5
Piattaforme cloud
Google Cloud Platform
- Risorse su richiesta (paghiamo solo quando necessario)
- Facile da gestire e aggiornare
- Visibilità e controllo di tutte le risorse
6
Orchestrazione
kubernetes
Nel contesto di contenitori con browser/emulatori all'interno dei pod:
- Ridimensionamento/ridimensionamento automatico
- Autoguarigione
- Aggiornamenti e rollback senza interruzioni
7
Infrastruttura come codice (IaC)
Terraformazione, Ansible
- Vantaggi simili con le infrastrutture di sviluppo
- Tutti i vantaggi del controllo delle versioni del codice
- Facile apportare modifiche e mantenere
- Completamente automatizzato
Diagrammi delle mappe mentali: evoluzione delle infrastrutture
passaggio 1: locale
passaggio 2: VCS
fase 3: containerizzazione
passaggio 4: CI/CD
passaggio 5: piattaforme cloud
passaggio 6: orchestrazione
passaggio 7: IaC
Quali sono le prospettive?
Quindi, questa è la fine dell'articolo. Ma in conclusione, vorrei stabilire con voi alcuni accordi.
Da parte vostra
Come ho detto all'inizio, vorrei che l'articolo fosse di utilità pratica e ti aiutasse ad applicare le conoscenze acquisite nel lavoro reale. Aggiungo ancora.
Ma anche dopo, non fermarti, esercitati, studia link e libri pertinenti, scopri come funziona nella tua azienda, trova luoghi che possono essere migliorati e prendi parte a questo. Buona fortuna!
Dal mio lato
Dal titolo si capisce che questa era solo la prima parte. Nonostante si sia rivelato piuttosto ampio, qui non vengono ancora trattati argomenti importanti. Nella seconda parte, intendo esaminare l'infrastruttura di automazione nel contesto di IOS. A causa delle restrizioni di Apple sull'esecuzione dei simulatori iOS solo su sistemi macOS, la nostra gamma di soluzioni è ridotta. Ad esempio, non siamo in grado di utilizzare Docker per eseguire il simulatore o i cloud pubblici per eseguire macchine virtuali. Ma questo non significa che non ci siano altre alternative. Cercherò di tenerti aggiornato con soluzioni avanzate e strumenti moderni!
Inoltre, non ho menzionato argomenti piuttosto ampi relativi al monitoraggio. Nella Parte 3 esaminerò gli strumenti di monitoraggio dell'infrastruttura più popolari e quali dati e metriche considerare.
E infine. In futuro, ho intenzione di pubblicare un corso video sulla creazione di infrastrutture di test e strumenti popolari. Attualmente ci sono numerosi corsi e conferenze su DevOps su Internet, ma tutti i materiali sono presentati nel contesto dello sviluppo, non dell'automazione dei test. Su questo tema, ho davvero bisogno di feedback per sapere se un corso del genere sarà interessante e prezioso per la comunità di tester e ingegneri dell'automazione. Grazie in anticipo!
Fonte: habr.com