Parte 1: Web / Android
Nota: questo articolo è una traduzione in italiano dell'articolo originale Tuttavia, tutte le illustrazioni, i link, le citazioni e i termini sono mantenuti nella lingua originale, per evitare distorsioni del significato nella traduzione in italiano. Ti auguro una buona lettura!
Attualmente, la professione di DevOps è tra le più richieste nell'industria IT. Se visiti i siti di ricerca di lavoro più popolari e imposti il filtro per stipendi, noterai che le offerte di lavoro legate a DevOps sono in cima alla lista. Tuttavia, è importante comprendere che questo si riferisce principalmente alla posizione di 'Senior', il che implica che il candidato possiede un alto livello di competenze, conoscenza delle tecnologie e degli strumenti. Ciò implica anche un alto grado di responsabilità legato al funzionamento senza interruzioni della produzione. Tuttavia, abbiamo cominciato a dimenticare cosa significhi DevOps. Originariamente non era una persona specifica o un dipartimento. Se cerchiamo definizioni di questo termine, troveremo molti sostantivi belli e corretti, come metodologia, pratiche, filosofia culturale, gruppo di concetti e così via.
La mia specializzazione è ingegnere di automazione dei test (QA automation engineer), ma credo che non debba essere legata solo alla scrittura di test automatici o allo sviluppo dell'architettura di un framework di test. Nel 2020, la conoscenza dell'infrastruttura di automazione è diventata fondamentale. Questo permette di organizzare autonomamente il processo di automazione, dalla esecuzione dei test fino alla condivisione dei risultati con tutte le parti interessate, in base agli obiettivi prefissati. Di conseguenza, le competenze DevOps diventano un fattore necessario per svolgere tale lavoro. E va tutto bene, ma purtroppo c'è un problema (spoiler: questo articolo cerca di semplificare questo problema). Consiste nel fatto che DevOps è complicato. E questo è ovvio, poiché le aziende non pagano bene per ciò che è facile da fare... Nel mondo DevOps ci sono un gran numero di strumenti, termini e pratiche da padroneggiare. Questo è particolarmente difficile all'inizio della carriera e dipende dall'esperienza tecnica accumulata.
Fonte:
Qui, probabilmente, concludiamo la parte introduttiva e ci concentreremo sull'obiettivo di questo articolo.
Di cosa parla questo articolo
In questo articolo intendo condividere la mia esperienza nella costruzione di un'infrastruttura di automazione dei test. Su Internet si possono trovare molte fonti di informazioni su vari strumenti e su come usarli, ma vorrei considerarli esclusivamente nel contesto dell'automazione. Penso che molti ingegneri di automazione possano riconoscere la situazione in cui i test sviluppati vengono eseguiti solo da loro e non ci si prende cura della loro manutenzione. Di conseguenza, i test diventano obsoleti e si finisce per perdere tempo per aggiornarli. Anche all'inizio della carriera, questo può rappresentare una sfida difficile: decidere quali strumenti debbano aiutare a risolvere questo problema, come sceglierli, configurarli e mantenerli. Alcuni tester si rivolgono a DevOps (persone) e, a essere onesti, questo approccio funziona. In molti casi, potrebbe essere l'unica opzione, dato che non abbiamo visibilità su tutte le dipendenze. Ma, come sappiamo, i DevOps sono ragazzi molto occupati, poiché devono occuparsi dell'infrastruttura dell'intera azienda, del deployment, del monitoraggio, dei microservizi e di altri compiti simili a seconda dell'organizzazione/team. Come spesso accade, l'automazione non è una priorità. In tal caso, dobbiamo cercare di fare tutto il possibile da parte nostra, dall'inizio alla fine. Questo ridurrà le dipendenze, accelererà il flusso di lavoro, migliorerà le nostre competenze e ci consentirà di avere una visione più ampia della situazione.
Nell'articolo sono presentati gli strumenti più richiesti e popolari e viene mostrato come usarli per costruire passo dopo passo un'infrastruttura di automazione. Ogni gruppo è rappresentato da strumenti che sono stati testati a livello personale. Ma questo non significa che tu debba usare gli stessi. 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 compiti possiamo risolvere con il loro aiuto. Pertanto, alla fine di ogni sezione lascio link a strumenti simili che potrebbero essere utilizzati nella tua organizzazione.
Cosa non c'è in questo articolo
Ripeto ancora una volta che l'articolo non riguarda strumenti specifici, quindi non ci saranno inserimenti di codice dalla documentazione e descrizioni di comandi specifici. Tuttavia, alla fine di ogni sezione lascerò dei link per un approfondimento.
Questo è stato fatto per il motivo che:
- questo materiale è molto facile da trovare in diverse fonti (documentazione, libri, corsi video);
- se iniziamo ad approfondire, dovremmo scrivere 10, 20 o 30 parti di questo articolo (mentre i piani prevedono 2-3);
- non voglio semplicemente farvi perdere tempo, dato che forse volete usare altri strumenti per raggiungere gli stessi obiettivi.
Pratica
Vorrei davvero che questo materiale fosse utile per ogni lettore e non fosse semplicemente letto e dimenticato. In ogni studio, la pratica è una componente molto importante. A tal fine, ho preparato. Avrete anche un compito a casa, per assicurarvi di non aver copiato le righe dei comandi senza pensarci.
Piano
Step
Technology
Strumenti
1
Esecuzione locale (preparare test demo web/android e eseguirli localmente)
Node.js, Selenium, Appium
2
Sistemi di controllo versione
Git
3
Containerizzazione
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Piattaforme cloud
Google Cloud Platform
6
Orchestrazione
Kubernetes
7
Infrastructure as a code (IaC)
Terraform, Ansible
Struttura di ogni sezione
Per mantenere la narrazione in modo visivo, ogni sezione è descritta secondo il seguente piano:
- breve descrizione della tecnologia,
- valore per l'infrastruttura di automazione,
- illustrazione dello stato attuale dell'infrastruttura,
- link per lo studio,
- strumenti simili.
1. Esecuzione locale dei test
Breve descrizione della tecnologia
Questo è solo un passaggio preparatorio per eseguire test dimostrativi localmente e per verificare che passino con successo. Nella parte pratica si utilizza Node.js, ma il linguaggio di programmazione e la piattaforma non sono importanti e possono essere utilizzati quelli in uso nella vostra azienda.
Tuttavia, come strumenti di automazione, consiglio di utilizzare Selenium WebDriver per le piattaforme web e Appium per le piattaforme Android, dato che nei passaggi successivi utilizzeremo immagini Docker progettate per lavorare specificamente con questi strumenti. Inoltre, riferendosi alle richieste nei posti di lavoro, questi strumenti sono i più richiesti nel mercato.
Come avrete notato, stiamo considerando solo test web e Android. Sfortunatamente, IOS è una storia completamente differente (grazie Apple). Ho in programma di mostrare soluzioni e pratiche relative a IOS nei prossimi capitoli.
Valore per l'infrastruttura di automazione
Dal punto di vista dell'infrastruttura, l'esecuzione locale non porta alcun valore. Si verifica solo che i test funzionino sulla macchina locale nei browser e simulatori locali. Ma in ogni caso, è un punto di partenza necessario.
Illustrazione dello stato attuale dell'infrastruttura
Link per lo studio
Strumenti simili
- qualsiasi linguaggio di programmazione che preferite in combinazione con i test Selenium/Appium;
- qualunque test;
- qualsiasi test runner.
2. Sistemi di controllo delle versioni (Git)
Breve descrizione della tecnologia
Non sarà una grande rivelazione se dico che il sistema di controllo versione è una parte estremamente importante dello sviluppo sia in team che individualmente. Basandosi su diverse fonti, si può affermare con certezza che Git è il rappresentante più popolare. Il sistema di controllo versione offre numerosi vantaggi, come la condivisione del codice, la conservazione delle versioni, il ripristino a rami precedenti, il monitoraggio della storia del progetto e backup. Non discuteremo ogni punto nei dettagli, poiché sono sicuro che già lo conosci e lo utilizzi nel tuo lavoro quotidiano. Ma se così non fosse, ti consiglio di sospendere la lettura di questo articolo e di colmare al più presto questa lacuna.
Valore per l'infrastruttura di automazione
E qui puoi porre una domanda ragionevole: «Perché ci parla di Git? Tutti lo conoscono e lo usano sia per lo sviluppo del codice che per i test automatici». Avresti assolutamente ragione, ma in questo articolo parliamo di infrastruttura e questa sezione funge da anteprima per la sezione 7: «Infrastructure as code (IaC)». Per noi questo significa che tutta l'infrastruttura, compresa quella di test, viene descritta in forma di codice, quindi possiamo anche applicare sistemi di versionamento e ottenere vantaggi analoghi a quelli per il codice di sviluppo e di automazione.
Esamineremo IaC più nel dettaglio nel passaggio 7, ma anche ora puoi iniziare a utilizzare Git localmente, creando un repository locale. Il quadro generale sarà ampliato quando aggiungeremo un repository remoto all'infrastruttura.
Illustrazione dello stato attuale dell'infrastruttura
Link per lo studio
Strumenti simili
3. Containerizzazione (Docker)
Breve descrizione della tecnologia
Per dimostrare come la containerizzazione abbia cambiato le regole del gioco, facciamo un salto indietro di alcuni decenni. In passato, le persone acquistavano e utilizzavano macchine server per eseguire applicazioni. Tuttavia, nella maggior parte dei casi, le risorse necessarie per l'esecuzione non erano conosciute in anticipo. Di conseguenza, le aziende spendevano soldi per l'acquisto di server potenti e costosi, ma parte di questa potenza non veniva mai utilizzata completamente.
Il passo successivo nell'evoluzione sono state le macchine virtuali (VM), che hanno risolto il problema della spesa per risorse inutilizzate. Questa tecnologia ha permesso di eseguire applicazioni in modo indipendente l'una dall'altra all'interno di un unico server, riservando uno spazio completamente isolato. Tuttavia, sfortunatamente, ogni tecnologia ha i suoi svantaggi. L'esecuzione di VM richiede un sistema operativo completo, che consuma CPU, RAM, spazio di archiviazione e, a seconda del sistema operativo, bisogna considerare anche i costi di licenza. Questi fattori influenzano la velocità di avvio e complicano la portabilità.
Ed ecco arrivare la containerizzazione. Anche in questo caso, questa tecnologia ha risolto il problema precedente, poiché i container non utilizzano un sistema operativo completo, liberando così molte risorse e fornendo una soluzione rapida e flessibile per la portabilità.
Naturalmente, la tecnologia della containerizzazione non è qualcosa di nuovo e fu introdotta per la prima volta alla fine degli anni '70. In quel periodo sono stati condotti molti studi, ricerche e tentativi. Ma è stato Docker a adattare questa tecnologia e renderla ampiamente accessibile. Oggi, quando parliamo di container, ci riferiamo nella maggior parte dei casi a Docker. Quando parliamo di container Docker, intendiamo i container Linux. Possiamo utilizzare sistemi Windows e macOS per eseguire container, ma è importante capire che in questo caso viene introdotto uno strato aggiuntivo. Ad esempio, Docker su Mac avvia silenziosamente i container all'interno di una leggera VM Linux. Torneremo su questo tema quando discuteremo dell'esecuzione di emulatori Android all'interno dei container, poiché qui si presenta un aspetto molto importante che merita un'analisi più approfondita.
Valore per l'infrastruttura di automazione
Abbiamo scoperto che la containerizzazione e Docker sono ottimi. Vediamo come si inseriscono nel contesto dell'automazione, poiché ogni strumento o tecnologia deve affrontare un problema specifico. Identifichiamo i problemi evidenti dell'automazione dei test nell'ambito dei test UI:
- un numero elevato di dipendenze nell'installazione di Selenium e, in particolare, di Appium;
- problemi di compatibilità tra le versioni dei browser, simulatori e driver;
- mancanza di uno spazio isolato per browser/simulatori, particolarmente critico per l'esecuzione parallela;
- è difficile gestire e mantenere se è necessario eseguire contemporaneamente 10, 50, 100 o addirittura 1000 browser.
Ma poiché Selenium è lo strumento di automazione più popolare e Docker è lo strumento di containerizzazione più popolare, non deve sorprendere che qualcuno abbia cercato di combinarli per ottenere uno strumento potente in grado di risolvere i problemi sopra menzionati. Esaminiamo queste soluzioni più nel dettaglio.
Selenium grid in docker
Questo strumento è il più popolare al mondo in Selenium per avviare più browser su più macchine e gestirli da un nodo centrale. Per l'avvio, è necessario registrare almeno 2 componenti: Hub e Node(s). Hub è il nodo centrale che riceve tutte le richieste dai test e le distribuisce ai nodi corrispondenti. Per ogni nodo, possiamo configurare una configurazione specifica, ad esempio specificando il browser desiderato e la sua versione. Tuttavia, dobbiamo ancora occuparci noi stessi dei driver compatibili per i browser e installarli sui nodi necessari. Per questo motivo, Selenium grid non è utilizzato nella sua forma pura, tranne nei casi in cui dobbiamo lavorare con browser che non possono essere installati su sistemi operativi Linux. In tutti gli altri casi, l'utilizzo di immagini Docker per eseguire Selenium grid Hub e Nodes sarà una soluzione molto più flessibile e corretta. Questo approccio semplifica notevolmente la gestione dei nodi, poiché possiamo scegliere l'immagine desiderata con già installate le versioni compatibili di browser e driver.
Nonostante le recensioni negative sulla stabilità operativa, specialmente quando si eseguono un gran numero di nodi in parallelo, Selenium grid rimane ancora lo strumento più popolare per l'esecuzione parallela dei test Selenium. È importante notare che nel mondo open-source ci sono costantemente nuove implementazioni e modifiche a questo strumento, che affrontano vari colli di bottiglia.
Selenoid per Web
Questo strumento rappresenta una svolta nel mondo di Selenium, poiché funziona immediatamente e ha semplificato notevolmente il lavoro di molti ingegneri di automazione. In primo luogo, non è una mera modifica di Selenium Grid. Gli sviluppatori hanno creato una versione completamente nuova di Selenium Hub in linguaggio Golang, che, insieme alle immagini Docker leggere per diversi browser, ha dato una spinta allo sviluppo dell'automazione dei test. Inoltre, nel caso di Selenium Grid, dobbiamo definire in anticipo tutti i browser e le loro versioni richieste, il che non è un problema quando lavoriamo esclusivamente con un singolo browser. Ma quando si tratta di più browser supportati, Selenoid diventa la soluzione numero uno, grazie alla funzione 'browser on demand'. Tutto ciò che dobbiamo fare è caricare 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 richiesto con il browser desiderato. Una volta concluso il test, Selenoid fermerà il contenitore, liberando così risorse per le richieste successive. Questo approccio elimina completamente il noto problema della 'degradazione dei nodi', che incontriamo frequentemente in Selenium Grid.
Tuttavia, Selenoid non è ancora una soluzione miracolosa. Abbiamo ottenuto la funzione 'browser on demand', ma la funzione 'risorse on demand' non è ancora disponibile. Per utilizzare Selenoid, dobbiamo installarlo su hardware fisico o su una VM, il che significa che è necessario sapere in anticipo quante risorse devono essere allocate. Credo che ciò non rappresenti un problema per piccoli progetti, che eseguono 10, 20 o anche 30 browser in parallelo. Ma cosa succede se ci servono 100, 500, 1000 o più? Non ha senso mantenere e pagare per una tale quantità di risorse continuamente. Nelle sezioni 5 e 6 di questo articolo discuteremo delle soluzioni che consentono di scalare, riducendo così significativamente i costi aziendali.
Selenoid for Android
Dopo il successo di Selenoid come strumento per l'automazione web, le persone desideravano qualcosa di simile per Android. E così è stato: è stata rilasciata Selenoid con supporto per Android. Dal punto di vista dell'utente, il principio di funzionamento è simile a quello dell'automazione web. L'unica differenza è che, invece di contenitori con i browser, Selenoid avvia contenitori con emulatori Android. A mio avviso, al momento è lo strumento gratuito più potente per l'esecuzione di test Android in parallelo.
Non mi piace parlare degli aspetti negativi di questo strumento, poiché mi piace davvero molto. Tuttavia, ci sono le stesse limitazioni relative all'automazione web, soprattutto in termini di scalabilità. Inoltre, c’è un altro vincolo da menzionare, che può sorprendere chi configura lo strumento per la prima volta. Per eseguire le immagini Android abbiamo bisogno di una macchina fisica o di una VM con supporto per la virtualizzazione nidificata. Nella guida pratica mostro come attivare questa funzione su una VM Linux. Tuttavia, se sei un utente macOS e desideri installare Selenoid localmente, sarà impossibile eseguire test Android. Ma puoi sempre avviare una VM Linux localmente con la 'virtualizzazione nidificata' attivata e installare Selenoid al suo interno.
Illustrazione dello stato attuale dell'infrastruttura
Nel contesto di questo articolo, aggiungeremo 2 strumenti per illustrare l'infrastruttura. Questi sono Selenium Grid per i test web e Selenoid per i test Android. Nella guida su GitHub mostrerò anche come utilizzare Selenoid per eseguire test web.
Link per lo studio
Strumenti simili
- Esistono altri strumenti di containerizzazione, ma Docker è il più popolare. Se desideri provare qualcos'altro, tieni presente che gli strumenti che abbiamo esaminato per l'esecuzione parallela dei test Selenium non funzioneranno out of the box.
- Come già detto, ci sono molte modifiche a Selenium Grid, come ad esempio.
4. CI / CD
Breve descrizione della tecnologia
La pratica dell'integrazione continua è piuttosto popolare nello sviluppo e si colloca al pari dei sistemi di controllo versione. Tuttavia, sento che c'è confusione nella terminologia. In questo paragrafo vorrei descrivere 3 varianti di questa tecnologia dalla mia prospettiva. Su Internet puoi trovare molti articoli con diverse interpretazioni, ed è assolutamente normale se la tua opinione differisce. L'importante è che tu sia sulla stessa lunghezza d'onda dei tuoi colleghi.
Quindi, ci sono 3 termini: CI - Continuous Integration (integrazione continua), CD - Continuous Delivery (consegna continua), e di nuovo CD - Continuous Deployment (distribuzione continua).In seguito utilizzerò questi termini in lingua inglese). Ogni modifica aggiunge ulteriori fasi al tuo processo di sviluppo. Ma la parola continuous è la più importante. In questo contesto si intende qualcosa che avviene dall'inizio alla fine, senza interruzioni o interventi manuali. Vediamo CI & CD e CD in questo contesto.
- Continuous Integration – è il primo passo dell'evoluzione. Dopo aver inviato un nuovo codice al server, ci aspettiamo un feedback rapido sul fatto che le nostre modifiche siano corrette. Di solito, CI include l'esecuzione di strumenti di analisi statica del codice e test di unità/API interni. Questo ci consente di avere informazioni sul nostro codice già dopo pochi secondi/minuti.
- Continuous Delivery è un passo più avanzato, durante il quale eseguiamo test di integrazione/UI. Tuttavia, in questa fase non otteniamo risultati così rapidamente come nel caso del CI. In primo luogo, questi tipi di test richiedono più tempo per essere completati. In secondo luogo, prima di eseguirli, dobbiamo distribuire le nostre modifiche in un ambiente di test/staging. Inoltre, se parliamo di sviluppo mobile, c'è un ulteriore passaggio per creare la build della nostra applicazione.
- Continuous Deployment significa che rilasciamo automaticamente le nostre modifiche in produzione, se tutti i test di accettazione sono stati superati nelle fasi precedenti. Inoltre, dopo la fase di rilascio, è possibile configurare diverse fasi, come l'esecuzione di test di smoke in produzione e la raccolta di metriche rilevanti. Il Continuous Deployment è possibile solo con una buona copertura di test automatizzati. Se sono necessari interventi manuali, compresi i test, allora questo non è più Continuous (continuo). Allora possiamo dire che il nostro processo corrisponde solo alla pratica del Continuous Delivery.
Valore per l'infrastruttura di automazione
In questa sezione devo chiarire che, quando parliamo di test UI end-to-end, intendiamo che dobbiamo distribuire le nostre modifiche e i servizi correlati negli ambienti di test. La Continuous Integration non è applicabile a questo compito e dobbiamo assicurarci di implementare almeno le pratiche di Continuous Delivery. Anche il Continuous Deployment ha senso nel contesto dei test UI, se intendiamo eseguirli in produzione.
E prima di dare un'occhiata all'illustrazione delle modifiche architetturali, voglio dire 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 logging e raccolta di metriche. L'architettura di GitLab consiste in GitLab CI/CD e GitLab Runner. Ecco una breve descrizione dal sito ufficiale:
GitLab CI/CD è un'applicazione web con 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 distribuita separatamente e lavora con GitLab CI/CD tramite un'API. Per l'esecuzione dei test hai bisogno sia di un'istanza GitLab che di un Runner.
Illustrazione dello stato attuale dell'infrastruttura
Link per lo studio
Strumenti simili
- E molti altri
5. Piattaforme cloud
Breve descrizione della tecnologia
In questa sezione parleremo di una tendenza popolare chiamata 'cloud pubblici'. Nonostante i grandi vantaggi offerti dalle tecnologie di virtualizzazione e containerizzazione sopra descritte, abbiamo ancora bisogno di risorse di calcolo. Le aziende acquistano costosi server o affittano data center, ma in tal caso è necessario fare calcoli (a volte poco realistici) su quante risorse avremo bisogno, se le utilizzeremo 24/7 e per quali scopi. Ad esempio, per la produzione è necessario un server funzionante 24 ore su 24, ma abbiamo bisogno di risorse simili per i test durante l'orario non lavorativo? Questo dipende anche dal tipo di test in corso. Un esempio potrebbero essere i test di carico/stress che intendiamo eseguire durante l'orario non lavorativo per ottenere risultati il giorno successivo. Ma, sicuramente, la disponibilità continua dei server non è necessaria per i test automatici end-to-end e soprattutto per gli ambienti di testing manuale. Per queste situazioni sarebbe utile avere accesso a risorse richieste on-demand, utilizzarle e smettere di pagare quando non sono più necessarie. Inoltre, sarebbe fantastico ottenerle immediatamente, effettuando pochi clic del mouse o eseguendo un paio di script. A questo servono i cloud pubblici. Andiamo a vedere la definizione:
«Il cloud pubblico è definito come servizi di computing offerti da fornitori terzi su Internet pubblico, rendendoli disponibili a chiunque desideri utilizzarli o acquistarli. Possono essere gratuiti o venduti su richiesta, consentendo ai clienti di pagare solo per l'uso delle risorse, come i cicli di CPU, lo stoccaggio o la larghezza di banda che consumano».
Esiste un'opinione condivisa che i cloud pubblici siano costosi. Ma la loro idea principale è la riduzione delle spese aziendali. Come accennato in precedenza, i cloud pubblici permettono di ottenere risorse on-demand e pagare solo per il tempo di utilizzo. Inoltre, a volte dimentichiamo che i dipendenti ricevono uno stipendio e gli esperti sono anch'essi una risorsa costosa. È importante considerare che i cloud pubblici semplificano notevolmente la gestione dell'infrastruttura, permettendo agli ingegneri di concentrarsi su attività più rilevanti.
Valore per l'infrastruttura di automazione
Quali risorse specifiche ci servono per i test UI end-to-end? Fondamentalmente, si tratta di macchine virtuali o cluster (parleremo di Kubernetes nella sezione successiva) per eseguire browser ed emulatori. Maggiore è il numero di browser ed emulatori che vogliamo eseguire contemporaneamente, maggiori saranno le risorse CPU e memoria necessarie, e così più alto sarà il costo. In questo modo, i cloud pubblici nel contesto dell'automazione dei test ci permettono di avviare un gran numero (100, 200, 1000 ...) di browser/emulatori on-demand, ricevere i risultati dei test il prima possibile e smettere di pagare per potenze così resource-intensive.
I fornitori di cloud più popolari sono Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Nel manuale pratico vengono forniti esempi di utilizzo di GCP, ma in generale non importa cosa utilizzi per le attività di automazione. Offrono tutti funzioni simili. Di solito la scelta del fornitore si concentra sull'intera infrastruttura aziendale e sui requisiti di business, cosa che va oltre il tema di questo articolo. Per gli ingegneri dell'automazione, sarà più interessante confrontare l'uso dei fornitori di cloud con piattaforme cloud specifiche per scopi di test, come Sauce Labs, BrowserStack, BitBar e così via. Quindi facciamolo! A mio avviso, Sauce Labs è il più noto fornitore di testing cloud, quindi l'ho scelto per il confronto.
GCP contro Sauce Labs per scopi di automazione:
Immaginiamo di dover eseguire simultaneamente 8 test web e 8 test Android. Per questo utilizzeremo GCP e avvieremo 2 macchine virtuali con Selenoid. Sulla prima avvieremo 8 contenitori con i browser. Sulla seconda – 8 contenitori con gli emulatori. Diamo un'occhiata ai prezzi:
Per avviare un contenitore con Chrome, avremo bisogno di n1-standard-1 macchina. Nel caso di Android, sarà n1-standard-4 per un emulatore. In realtà, un approccio più flessibile e conveniente è quello di definire valori specifici per CPU/Memoria, ma al momento, per il confronto con Sauce Labs, non è fondamentale.
Ecco le tariffe per l'utilizzo di Sauce Labs:
Penso che tu abbia già notato la differenza, ma comunque fornirò una tabella con i calcoli per il nostro compito:
Risorse richieste
Mensile
Ore lavorative(8 a.m — 8 p.m)
Ore lavorative+ Preemptible
GCP per Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 giorni * 12h * 0.38 = 104.88$
23 giorni * 12h * 0.08 = 22.08$
Sauce Labs per Web
Test paralleli Virtual Cloud8
$1.559
—
—
GCP per Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 giorni * 12h * 1.52 = 419.52$
23 giorni * 12h * 0.32 = 88.32$
Sauce Labs per Android
Test paralleli Real Device Cloud 8
$1.999
—
—
Come possiamo notare, la differenza di costo è enorme, specialmente se si eseguono test solo durante l'orario lavorativo di dodici ore. Ma è possibile ridurre ulteriormente le spese utilizzando macchine preemptible. Cosa sono esattamente?
Una VM preemptible è un'istanza che puoi creare e far funzionare a un costo molto inferiore rispetto alle normali istanze. Tuttavia, il Compute Engine può terminare (preempt) queste istanze se ha bisogno di accedere a quelle risorse per altri compiti. Le istanze preemptible sono capacità eccessive del Compute Engine, quindi la loro disponibilità varia in base all'utilizzo.
Se le tue app sono tolleranti ai guasti e possono resistere a possibili interruzioni delle istanze, allora le istanze preemptible possono ridurre significativamente i tuoi costi del Compute Engine. Ad esempio, i lavori di elaborazione batch possono essere eseguiti su istanze preemptible. Se alcune di queste istanze terminano durante l'elaborazione, il lavoro rallenta ma non si ferma completamente. Le istanze preemptible completano i tuoi compiti di elaborazione batch senza aumentare il carico di lavoro sulle tue istanze esistenti e senza richiedere di pagare il prezzo pieno per ulteriori istanze normali.
E questo non è ancora tutto! In realtà, sono sicuro che nessuno esegue test per 12 ore senza una pausa. E se è così, puoi avviare e fermare automaticamente le macchine virtuali quando non sono necessarie. Il tempo reale di utilizzo può ridursi a 6 ore al giorno. Allora, il pagamento nel contesto del nostro compito potrebbe scendere a solo 11$ al mese per 8 browser. Non è fantastico? Ma con le macchine preemptible dobbiamo essere cauti e pronti a interruzioni e instabilità, anche se queste situazioni possono essere previste e gestite programmabilmente. Ne vale la pena!
Ma in nessun modo dico 'mai utilizzare i cloud testing farm'. Essi hanno diversi vantaggi. Prima di tutto, non si tratta solo di una macchina virtuale, ma di una vera e propria soluzione per l'automazione dei test con un insieme di funzionalità pronte all'uso: accesso remoto, log, screenshot, registrazione video, diversi browser e dispositivi mobili fisici. In molte situazioni, questa può essere un'alternativa ricca e insostituibile. Le piattaforme di test sono particolarmente utili per l'automazione su IOS, dove i cloud pubblici possono offrire solo sistemi Linux/Windows. Ma parleremo di IOS nei prossimi articoli. Raccomando sempre di valutare la situazione e di basarsi sulle necessità: in alcuni casi è più economico ed efficace utilizzare i cloud pubblici, mentre in altri le piattaforme di test valgono decisamente il costo sostenuto.
Illustrazione dello stato attuale dell'infrastruttura
Link per lo studio
Strumenti analoghi:
6. Orchestrazione
Breve descrizione della tecnologia
Ho buone notizie – siamo quasi alla fine dell'articolo! Attualmente, la nostra infrastruttura di automazione consiste in test web e Android, che eseguiamo tramite GitLab CI in parallelo, utilizzando strumenti con supporto per Docker: Selenium grid e Selenoid. Inoltre, utilizziamo macchine virtuali create tramite GCP per l'esecuzione di contenitori con browser ed emulatori. Per ridurre i costi, avviamo queste macchine virtuali solo su richiesta e le fermiamo quando non ci sono test in corso. C'è qualcos'altro che potrebbe migliorare la nostra infrastruttura? La risposta è sì! Presentiamo Kubernetes (K8s)!
Iniziamo a esaminare come i termini orchestrazione, cluster e Kubernetes siano interconnessi. A un livello alto, l'orchestrazione è un sistema che distribuisce e gestisce applicazioni. Per l'automazione dei test, tali applicazioni containerizzate sono Selenium grid e Selenoid. Docker e K8s si completano a vicenda. Il primo è utilizzato per implementare le applicazioni, il secondo per l'orchestrazione. A sua volta, K8s è un cluster. La funzione del cluster è utilizzare le VM come Nodes, consentendo di installare varie funzionalità, programmi e servizi all'interno di un singolo server (cluster). Se uno dei Node fallisce, altri Nodes intervengono, garantendo che la nostra applicazione funzioni ininterrottamente. Inoltre, K8s ha una funzionalità importante relativa alla scalabilità, grazie alla quale otteniamo automaticamente il numero ottimale di risorse in base al carico e ai limiti stabiliti.
A dire il vero, implementare Kubernetes manualmente da zero è un compito piuttosto complesso. Lascio un link a una nota guida pratica 'Kubernetes The Hard Way', e, se sei interessato, puoi esercitarti. Ma, per fortuna, esistono modi e strumenti alternativi. Il più semplice tra questi è utilizzare Google Kubernetes Engine (GKE) in GCP, che permette di ottenere un cluster pronto dopo pochi clic. Per iniziare a studiare, consiglio di usare proprio questo approccio, in quanto ti consentirà di concentrarti sull'apprendimento di come utilizzare K8s per le tue esigenze, piuttosto che esplorare come i componenti interni debbano interagire tra loro.
Valore per l'infrastruttura di automazione
Esaminiamo alcune funzioni significative fornite da K8s:
- distribuzione delle applicazioni: utilizzo di un cluster multi-nodes, invece delle VM;
- scalabilità dinamica: riduce i costi delle risorse utilizzate solo su richiesta;
- auto-ripristino (Self-healing): ripristino automatico dei pods (il che porta anche al ripristino dei contenitori);
- distribuzione di aggiornamenti e rollback senza downtime: l'aggiornamento degli strumenti, dei browser e degli emulatori non interrompe il lavoro degli utenti attuali;
Ma K8s non è ancora una panacea. Per comprendere tutti i vantaggi e le limitazioni nel contesto degli strumenti che stiamo esaminando (Selenium grid, Selenoid), discuteremo brevemente la struttura di K8s. Un Cluster contiene due tipi di Nodes: Master Nodes e Workers Nodes. I Master Nodes sono responsabili della gestione, della distribuzione e delle decisioni di scheduling. I Workers nodes sono dove le applicazioni vengono eseguite. I Nodes contengono anche l'ambiente di esecuzione dei contenitori. Nel nostro caso, si tratta di Docker, che gestisce le operazioni legate ai contenitori. Ma ci sono anche soluzioni alternative, come. È importante comprendere che il ridimensionamento o il ripristino automatico non si riferisce direttamente ai container. Questo viene realizzato attraverso l'aggiunta o la riduzione del numero di pods, che a loro volta contengono i container (solitamente un container per pod, ma a seconda del compito possono essercene di più). La gerarchia di alto livello è costituita dai worker nodes, all'interno dei quali si trovano i pods, nei quali vengono sollevati i container.
La funzione di ridimensionamento è fondamentale e può essere applicata sia ai nodes all'interno del cluster node-pool che ai pods all'interno del node. Ci sono 2 tipi di ridimensionamento che si applicano sia ai nodes che ai pods. Il primo tipo – orizzontale – è il ridimensionamento che avviene aumentando il numero di nodes/pods. Questo tipo è preferibile. Il secondo tipo, di conseguenza, è verticale. Il ridimensionamento viene effettuato aumentando le dimensioni dei nodes/pods, non il loro numero.
Ora diamo un'occhiata ai nostri strumenti nel contesto dei termini menzionati sopra.
Selenium grid
Come accennato in precedenza, Selenium grid è uno strumento molto popolare, e non sorprende che sia stato containerizzato. Di conseguenza, non stupisce che Selenium grid possa essere distribuito in K8s. Un esempio di come farlo può essere trovato nel repository ufficiale di K8s. Come al solito, allego i link alla fine della sezione. Inoltre, nella guida pratica viene mostrato come farlo tramite Terraform. C'è anche una guida su come ridimensionare il numero di pods che contengono container con browser. Tuttavia, la funzione di ridimensionamento automatico nel contesto di K8s è ancora un compito poco chiaro. Quando ho iniziato a studiarlo, non ho trovato alcuna guida pratica o raccomandazioni. Dopo varie ricerche e esperimenti con il supporto del team DevOps, abbiamo scelto l'approccio di sollevare i container con i browser richiesti all'interno di un pod, che si trova all'interno di un worker node. Questo metodo ci consente di applicare una strategia di ridimensionamento orizzontale dei nodes aumentando il loro numero. Spero che in futuro la situazione cambi e vedremo sempre più descrizioni delle migliori pratiche e soluzioni pronte, specialmente dopo il rilascio di Selenium grid 4 con un'architettura interna modificata.
Selenoid:
Attualmente, il deployment di Selenoid in K8s rappresenta la maggiore delusione. Non sono compatibili. Teoricamente possiamo sollevare un container Selenoid all'interno di un pod, ma quando Selenoid inizia a lanciare container con browser, questi rimangono all'interno dello stesso pod. Questo rende impossibile il ridimensionamento e, di conseguenza, il funzionamento di Selenoid all'interno del cluster non differirà da quello all'interno di una macchina virtuale. Fine della storia.
Moon:
Conoscendo questo collo di bottiglia nell'uso di Selenoid, gli sviluppatori hanno rilasciato uno strumento più potente chiamato Moon. Questo strumento è stato progettato per funzionare con Kubernetes e, di conseguenza, è possibile e necessario utilizzare la funzione di ridimensionamento automatico. Inoltre, direi che al momento è l'unica lo strumento nel mondo di Selenium che, out-of-the-box, ha supporto nativo per cluster K8s (non più, vedi il prossimo strumento ). La caratteristica principale di Moon, che consente questo supporto, è:
Completamente stateless. Selenoid memorizza in memoria informazioni sulle sessioni del browser attualmente in esecuzione. Se per qualche motivo il suo processo si interrompe, tutte le sessioni in corso andranno perse. Al contrario, Moon non ha uno stato interno e può essere replicato in vari datacenter. Le sessioni del browser rimangono attive anche se una o più repliche vanno giù.
Quindi, Moon è una soluzione fantastica, ma con un problema: non è gratuita. Il prezzo dipende dal numero di sessioni. È possibile eseguire gratuitamente solo da 0 a 4 sessioni, il che non è molto utile. Ma, a partire dalla quinta sessione, dovremo pagare 5$ per ciascuna. La situazione può variare da azienda a azienda, ma nel nostro caso l'uso di Moon è inutile. Come descritto sopra, possiamo avviare VM con Selenium Grid su richiesta o aumentare il numero di Nodes nel cluster. Circa per ogni pipeline avviamo 500 browser e fermiamo tutte le risorse dopo il completamento dei test. Se avessimo usato Moon, avremmo dovuto pagare ulteriori 500 x 5 = 2500 $ al mese, indipendentemente da quanto spesso eseguiamo i test. E ancora, non dico "non usare Moon". Per le vostre necessità, potrebbe essere una soluzione indispensabile, ad esempio, se la vostra organizzazione ha molti progetti/team e vi serve un enorme cluster condiviso per tutti. Come sempre, lascio il link alla fine e consiglio di effettuare tutti i calcoli necessari nel contesto delle vostre esigenze.
Callisto: (Attenzione! Questo non è presente nell'articolo originale e si trova solo nella traduzione russa)
Come ho già detto, Selenium è uno strumento molto popolare e il settore IT sta evolvendo rapidamente. Mentre lavoravo alla traduzione, è emerso un nuovo strumento promettente, Callisto (salve a Cypress e ad altri killer di Selenium). Funziona in modo nativo con K8s e consente di eseguire contenitori Selenoid in pods, distribuiti su nodi. Tutto funziona subito out of the box, inclusa l'auto-scaling. Fantastico, ma va testato. Sono già riuscito a implementare questo strumento e a condurre alcuni esperimenti. Tuttavia, è prematuro trarre conclusioni; dopo aver ottenuto risultati a lungo termine, potrei scrivere una recensione in articoli futuri. Per ora, lascio solo i link per ulteriori ricerche.
Illustrazione dello stato attuale dell'infrastruttura
Link per lo studio
Link per lo studio
Strumenti simili
7. Infrastruttura come codice (IaC)
Breve descrizione della tecnologia
Ecco che siamo arrivati all'ultimo capitolo. Di solito, questa tecnologia e i compiti ad essa associati non rientrano nelle responsabilità degli ingegneri di automazione. E ci sono buone ragioni per questo. In primo luogo, in molte organizzazioni, le questioni infrastrutturali sono sotto il controllo del team DevOps e il team di sviluppo non si preoccupa molto di ciò che sostiene il pipeline e come mantenere tutto ciò che vi si collega. In secondo luogo, diciamolo chiaramente, la pratica dell'"Infrastruttura come codice (IaC)" non è ancora adottata in molte aziende. Tuttavia, è diventata una tendenza popolare ed è importante cercare di essere coinvolti nei processi, approcci e strumenti ad essa correlati. O, perlomeno, rimanere aggiornati.
Iniziamo motivando l'uso di questo approccio. Abbiamo già discusso che per eseguire test in GitlabCI avremo bisogno di almeno le risorse per avviare Gitlab Runner. E per far funzionare contenitori con browser/emulatori dobbiamo riservare una VM o un cluster. Oltre alle risorse per il testing, abbiamo bisogno di una quantità significativa di potenza per mantenere gli ambienti di sviluppo, staging, produzione, che comprendono anche database, pianificazioni automatiche, configurazioni di rete, bilanciatori di carico, diritti utenti, e così via. Il problema principale riguarda gli sforzi necessari per mantenere tutto questo. Ci sono diversi modi in cui possiamo apportare modifiche e rilasciare aggiornamenti. Ad esempio, nel contesto di GCP possiamo usare la console UI nel browser e compiere tutte le azioni cliccando sui pulsanti. Un metodo alternativo può essere l'utilizzo delle chiamate API per interagire con le entità cloud o l'applicazione dello strumento da riga di comando gcloud per eseguire le manovre necessarie. Ma quando ci sono veramente un gran numero di diverse entità e elementi infrastrutturali, diventa difficile, se non impossibile, eseguire tutte le operazioni manualmente. Inoltre, tutte queste azioni manuali non sono controllate. Non possiamo sottoporle a revisione prima dell'esecuzione, usare un sistema di controllo versione e ripristinare rapidamente correzioni che hanno causato un incidente. Per risolvere tali problemi, gli ingegneri hanno creato e continuano a creare script bash/shell automatizzati, che non sono molto meglio delle soluzioni precedenti, poiché non sono così facili da leggere, comprendere, mantenere e modificare in stile procedurale.
In questo articolo e nella guida pratica utilizzerò 2 strumenti legati alla pratica IaC. Questi sono Terraform e Ansible. Alcuni ritengono che non abbia senso usarli contemporaneamente, poiché le loro funzionalità sono simili e si sostituiscono reciprocamente. Ma la verità è che inizialmente si pongono obiettivi completamente diversi. E il fatto che questi strumenti debbano integrarsi è stato confermato in una presentazione congiunta dai sviluppatori delle aziende HashiCorp e RedHat. La differenza concettuale è che Terraform è uno strumento di provisioning per gestire i server stessi. Mentre Ansible è uno strumento di gestione delle configurazioni, il cui compito è installare, configurare e gestire il software su quei server.
Un'altra caratteristica distintiva di questi strumenti è lo stile di scrittura del codice. A differenza di bash e Ansible, Terraform utilizza uno stile dichiarativo, basato sulla descrizione dello stato finale desiderato da raggiungere. Ad esempio, se intendiamo creare 10 VMs e applicare le modifiche tramite Terraform, avremo 10 VMs. Se eseguiamo lo script di nuovo, non succederà nulla, poiché abbiamo già 10 VMs, e Terraform ne è a conoscenza poiché conserva lo stato attuale dell'infrastruttura in un file di stato. Ansible, invece, utilizza un approccio procedurale e, se gli chiediamo di creare 10 VMs, durante il primo avvio otterremo 10 VMs, analogamente a quanto accade con Terraform. Tuttavia, dopo un secondo avvio, avremo già 20 VMs. Questa è la principale differenza. Nello stile procedurale non conserviamo lo stato attuale e descriviamo semplicemente la sequenza di passaggi da eseguire. Certamente, possiamo gestire diverse situazioni, aggiungere controlli sull'esistenza delle risorse e sullo stato attuale, ma non ha senso perdere tempo e sforzi per controllare questa logica. Inoltre, ciò aumenta il rischio di commettere errori.
In sintesi, si può concludere che per il provisioning dei server, lo strumento più adatto è Terraform con notazione dichiarativa. La gestione delle configurazioni è meglio affidarla ad Ansible. Detto ciò, vediamo alcuni esempi di utilizzo nel contesto dell'automazione.
Valore per l'infrastruttura di automazione
È importante capire che l'infrastruttura per l'automazione dei test deve essere considerata parte dell'intera infrastruttura aziendale. Questo significa che tutte le pratiche IaC devono essere applicate globalmente alle risorse di tutta l'organizzazione. Chi è responsabile dipende dai vostri processi. Il team DevOps è più esperto in queste questioni e ha una visione d'insieme. Tuttavia, gli ingegneri QA sono più coinvolti nel processo di costruzione dell'automazione e nella struttura del pipeline, il che consente loro di vedere meglio tutte le modifiche necessarie e le opportunità di miglioramento. La soluzione migliore è collaborare, scambiarsi conoscenze e idee per raggiungere il risultato desiderato.
Ecco alcuni esempi di utilizzo di Terraform e Ansible nel contesto dell'automazione dei test e degli strumenti che abbiamo discusso in precedenza:
1. Descrivere tramite Terraform le caratteristiche e i parametri necessari per le VMs e i cluster.
2. Installare tramite Ansible gli strumenti necessari per i test: docker, Selenoid, Selenium Grid e caricare le versioni richieste dei browser/emulatori.
3. Descrivere tramite Terraform le caratteristiche della VM in cui verrà eseguito il GitLab Runner.
4. Installare tramite Ansible il GitLab Runner e gli strumenti complementari, configurando le impostazioni.
Illustrazione dello stato attuale dell'infrastruttura
Risorse per approfondire:
Strumenti simili
Riassumiamo!
Step
Technology
Strumenti
Valore per l'infrastruttura di automazione
1
Esecuzione locale
Node.js, Selenium, Appium
- Gli strumenti più popolari per web e mobile
- Supporto per molte lingue e piattaforme (incluso Node.js)
2
Sistemi di controllo versione
Git
- Vantaggi simili con il codice di sviluppo
3
Containerizzazione
Docker, Selenium grid, Selenoid (Web, Android)
- Esecuzione parallela dei test
- Ambienti isolati
- Aggiornamenti di versione semplici e flessibili
- Arresto dinamico delle risorse non utilizzate
- Facile da configurare
4
CI / CD
Gitlab CI
- I test fanno parte del pipeline
- Feedback rapido
- Visibilità per l'intera azienda/team
5
Piattaforme cloud
Google Cloud Platform
- Risorse on demand (paghiamo solo quando sono necessarie)
- Facile da gestire e aggiornare
- Visibilità e controllo di tutte le risorse
6
Orchestrazione
Kubernetes
Nel contesto dei contenitori con browser/emulatori all'interno dei pods:
- Scalabilità / autoscalabilità
- Auto-ripristino
- Aggiornamenti e rollback senza interruzioni
7
Infrastructure as a code (IaC)
Terraform, Ansible
- Vantaggi simili con l'infrastruttura di sviluppo
- Tutti i vantaggi della versioning del codice
- Facile apportare modifiche e mantenere
- Completamente automatizzato
Diagrammi di mappa mentale: evoluzione dell'infrastruttura
step1: Locale
step2: VCS
step3: Containerizzazione
step4: CI/CD
step5: Piattaforme Cloud
step6: Orchestrazione
step7: IaC
E ora?
Quindi, siamo giunti alla fine dell'articolo. Ma per concludere, vorrei stabilire alcune intese con voi.
Da parte vostra
Come detto all'inizio, mi piacerebbe che l'articolo fosse di utilità pratica e vi aiutasse ad applicare le conoscenze acquisite nel lavoro reale. Ripropongo ancora.
Ma anche dopo ciò, non fermatevi, praticate, studiate i link e i libri pertinenti, scoprite come funziona nella vostra azienda, trovate aree da migliorare e partecipate a questo. Buona fortuna!
Da parte mia
Dal titolo si può notare che questa era solo la prima parte. Anche se è risultata piuttosto lunga, ci sono ancora temi importanti da esplorare. Nella seconda parte, intendo esaminare l'infrastruttura di automazione nel contesto di iOS. A causa delle restrizioni di Apple che limitano l'esecuzione degli simulatori iOS solo su sistemi macOS, il nostro set di soluzioni è ridotto. Ad esempio, non abbiamo la possibilità di utilizzare Docker per eseguire lo simulator o di pubblici cloud per avviare macchine virtuali. Tuttavia, ciò non significa che non ci siano altre alternative. Cercherò di mantenervi aggiornati sulle soluzioni all'avanguardia e sugli strumenti moderni!
Inoltre, non ho menzionato argomenti piuttosto ampi legati al monitoraggio. Nella parte 3, intendo esaminare gli strumenti di monitoraggio più popolari per l'infrastruttura, così come i dati e le metriche da considerare.
E infine. In futuro, ho in programma di lanciare un corso video sulla costruzione di un'infrastruttura di test e sugli strumenti più popolari. Attualmente, ci sono molti corsi e conferenze online su DevOps, ma tutto il materiale è presentato nel contesto dello sviluppo, non dell'automazione dei test. Ho davvero bisogno di feedback su se un corso del genere sarebbe interessante e prezioso per la comunità dei tester e degli automatizzatori. Grazie in anticipo!
Fonte: habr.com
