Osa 1: Web/Android
Huomata: Tämä artikkeli on käännös alkuperäisestä artikkelista venäjäksi Kaikki kuvat, linkit, lainaukset ja termit kuitenkin säilytetään alkuperäisellä kielellä, jotta vältetään merkityksen vääristyminen venäjäksi käännettäessä. Toivotan sinulle onnea opiskeluun!
Tällä hetkellä DevOps-erikoisuus on yksi IT-alan kysytyimmistä. Jos avaat suosittuja työnhakusivustoja ja suodatat palkan mukaan, näet, että DevOpsiin liittyvät työt ovat luettelon kärjessä. On kuitenkin tärkeää ymmärtää, että tämä koskee pääasiassa "Senior"-asemaa, mikä tarkoittaa, että hakijalla on korkea taitotaso, tekniikan ja työkalujen tuntemus. Tähän liittyy myös suuri vastuu tuotannon keskeytymättömästä toiminnasta. Aloimme kuitenkin unohtaa, mikä DevOps on. Aluksi se ei ollut mikään tietty henkilö tai osasto. Jos etsimme tämän termin määritelmiä, löydämme monia kauniita ja oikeita substantiiveja, kuten metodologiaa, käytäntöjä, kulttuurifilosofiaa, käsiteryhmää ja niin edelleen.
Erikoistumiseni on testiautomaatioinsinööri (QA-automaatioinsinööri), mutta mielestäni sitä ei pidä liittää pelkästään autotestien kirjoittamiseen tai testikehysarkkitehtuurin kehittämiseen. Vuonna 2020 automaatioinfrastruktuurin tuntemus on myös välttämätöntä. Näin voit itse organisoida automaatioprosessin aina testien suorittamisesta tulosten toimittamiseen kaikille sidosryhmille tavoitteidesi mukaisesti. Tämän seurauksena DevOps-taidot ovat välttämättömiä työn suorittamiseksi. Ja kaikki tämä on hyvää, mutta valitettavasti on ongelma (spoileri: tämä artikkeli yrittää yksinkertaistaa tätä ongelmaa). Pointti on, että DevOps on kova. Ja tämä on selvää, koska yritykset eivät maksa paljoa jostain, joka on helppo tehdä... DevOps-maailmassa on suuri joukko työkaluja, termejä ja käytäntöjä, jotka on hallittava. Tämä on erityisen vaikeaa uran alussa ja riippuu kertyneestä teknisestä kokemuksesta.
Lähde:
Tässä lopetamme luultavasti johdanto-osan ja keskitymme tämän artikkelin tarkoitukseen.
Mistä tässä artikkelissa on kyse?
Tässä artikkelissa aion jakaa kokemukseni testiautomaatioinfrastruktuurin rakentamisesta. Internetissä on monia tietolähteitä erilaisista työkaluista ja niiden käytöstä, mutta haluaisin tarkastella niitä puhtaasti automaation kontekstissa. Uskon, että monet automaatioinsinöörit tuntevat tilanteen, kun kukaan muu kuin sinä ei suorita kehitettyjä testejä tai välitä niiden ylläpidosta. Tämän seurauksena testit vanhentuvat ja sinun on käytettävä aikaa niiden päivittämiseen. Jälleen uran alussa tämä voi olla melko vaikea tehtävä: viisaasti päättää, mitkä työkalut auttavat poistamaan tietyn ongelman, kuinka ne valitaan, konfiguroidaan ja ylläpidetään. Jotkut testaajat pyytävät apua DevOpsilta (ihmisiltä), ja olkaamme rehellisiä, tämä lähestymistapa toimii. Monissa tapauksissa tämä voi olla ainoa vaihtoehto, koska meillä ei ole näkyvyyttä kaikista riippuvuuksista. Mutta kuten tiedämme, DevOps ovat erittäin kiireisiä tyyppejä, koska heidän täytyy ajatella koko yrityksen infrastruktuuria, käyttöönottoa, valvontaa, mikropalveluita ja muita vastaavia tehtäviä organisaatiosta/tiimistä riippuen. Kuten yleensä, automaatio ei ole prioriteetti. Tällaisessa tapauksessa meidän on yritettävä tehdä omalta osaltamme kaikki mahdollinen alusta loppuun. Tämä vähentää riippuvuuksia, nopeuttaa työnkulkua, parantaa taitojamme ja antaa meille mahdollisuuden nähdä suuremman kuvan siitä, mitä tapahtuu.
Artikkeli esittelee suosituimmat ja suosituimmat työkalut ja näyttää kuinka niitä käytetään automaatioinfrastruktuurin rakentamiseen askel askeleelta. Jokaista ryhmää edustavat henkilökohtaisen kokemuksen kautta testatut työkalut. Mutta se ei tarkoita, että sinun pitäisi käyttää samaa asiaa. Itse työkalut eivät ole tärkeitä, ne ilmestyvät ja vanhenevat. Suunnittelutehtävämme on ymmärtää perusperiaatteet: miksi tarvitsemme tätä työkaluryhmää ja mitä työongelmia voimme ratkaista niiden avulla. Siksi jokaisen osion loppuun jätän linkit vastaaviin työkaluihin, joita voidaan käyttää organisaatiossasi.
Mitä tässä artikkelissa ei ole
Toistan vielä kerran, että artikkeli ei koske erityisiä työkaluja, joten dokumentaatiosta ja tiettyjen komentojen kuvauksista ei tule lisättyä koodia. Mutta jokaisen osan loppuun jätän linkit yksityiskohtaista tutkimusta varten.
Tämä tehdään, koska:
- tämä materiaali on erittäin helppo löytää eri lähteistä (dokumentaatio, kirjat, videokurssit);
- jos alamme mennä syvemmälle, meidän on kirjoitettava 10, 20, 30 osaa tästä artikkelista (kun suunnitelmat ovat 2-3);
- En vain halua tuhlata aikaasi, koska saatat haluta käyttää muita työkaluja samojen tavoitteiden saavuttamiseksi.
Käytäntö
Haluaisin todella, että tästä materiaalista on hyötyä jokaiselle lukijalle, eikä vain luettava ja unohdettu. Kaikissa tutkimuksissa harjoittelu on erittäin tärkeä osa. Tätä varten olen valmistautunut. Sinua odottaa myös kotitehtävä varmistaaksesi, ettet kopioi suorittamiesi komentojen rivejä mielettömästi.
suunnitelma
Vaihe
Elektroniikka
Työkalut
1
Paikallinen käyttö (valmistele web-/android-demotestejä ja suorita se paikallisesti)
Node.js, Seleeni, Appium
2
Versioiden hallintajärjestelmät
mennä
3
Konttikäsittely
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud-alustat
Google Cloud Platform
6
orkestrointi
Kubernetes
7
Infrastruktuuri koodina (IaC)
Terraform, Ansible
Kunkin osan rakenne
Kerronnan pitämiseksi selkeänä jokainen osa on kuvattu seuraavan kaavan mukaisesti:
- lyhyt kuvaus tekniikasta,
- arvo automaatioinfrastruktuurille,
- kuva infrastruktuurin nykytilasta,
- linkkejä opiskeluun,
- vastaavia työkaluja.
1. Suorita testit paikallisesti
Lyhyt kuvaus tekniikasta
Tämä on vain valmisteleva vaihe demotestien suorittamiseksi paikallisesti ja niiden läpäisemisen varmistamiseen. Käytännön osassa käytetään Node.js:ää, mutta ohjelmointikieli ja alusta eivät myöskään ole tärkeitä ja voit käyttää niitä, joita yrityksessäsi käytetään.
Automaatiotyökaluina suosittelen kuitenkin käyttämään Selenium WebDriveria verkkoalustoille ja Appiumia Android-alustalle, sillä seuraavissa vaiheissa käytämme Docker-kuvia, jotka on räätälöity toimimaan erityisesti näiden työkalujen kanssa. Lisäksi työn vaatimuksiin viitaten nämä työkalut ovat markkinoiden kysytyimpiä.
Kuten olet ehkä huomannut, otamme huomioon vain verkko- ja Android-testit. Valitettavasti iOS on täysin erilainen tarina (kiitos Applelle). Aion esitellä IOS:iin liittyviä ratkaisuja ja käytäntöjä tulevissa osissa.
Arvoa automaatioinfrastruktuurille
Infrastruktuurin näkökulmasta paikallisesti ajaminen ei tuota mitään arvoa. Tarkistat vain, että testit suoritetaan paikallisella koneella paikallisissa selaimissa ja simulaattoreissa. Mutta joka tapauksessa tämä on välttämätön lähtökohta.
Kuva infrastruktuurin nykytilasta
Linkkejä tutkittavaksi
Samanlaisia työkaluja
- mikä tahansa haluamasi ohjelmointikieli Selenium/Appium-testien yhteydessä;
- kaikki testit;
- joku koeajaja.
2. Versionhallintajärjestelmät (Git)
Lyhyt kuvaus tekniikasta
Se ei ole suuri paljastus kenellekään, jos sanon, että versionhallinta on erittäin tärkeä osa kehitystä, niin tiimissä kuin yksilöllisestikin. Eri lähteiden perusteella on turvallista sanoa, että Git on suosituin edustaja. Versionhallintajärjestelmä tarjoaa monia etuja, kuten koodin jakamisen, versioiden tallentamisen, palauttamisen aikaisempiin haaroihin, projektihistorian seurantaan ja varmuuskopiointiin. Emme käsittele jokaista kohtaa yksityiskohtaisesti, sillä olen varma, että tunnet sen hyvin ja käytät sitä päivittäisessä työssäsi. Mutta jos yhtäkkiä ei, niin suosittelen keskeyttämään tämän artikkelin lukemisen ja täyttämään tämän aukon mahdollisimman pian.
Arvoa automaatioinfrastruktuurille
Ja tässä voit kysyä järkevän kysymyksen: "Miksi hän kertoo meille Gitistä? Kaikki tietävät tämän ja käyttävät sitä sekä kehityskoodiin että automaattiseen testikoodiin." Olet täysin oikeassa, mutta tässä artikkelissa puhumme infrastruktuurista ja tämä osio toimii esikatseluna jaksolle 7: "Infrastruktuuri koodina (IaC)". Meille tämä tarkoittaa sitä, että koko infrastruktuuri, mukaan lukien testaus, on kuvattu koodin muodossa, joten voimme soveltaa siihen myös versiointijärjestelmiä ja saada samanlaisia etuja kuin kehitys- ja automaatiokoodissa.
Tarkastelemme IaC:tä tarkemmin vaiheessa 7, mutta nytkin voit aloittaa Gitin paikallisen käytön luomalla paikallisen arkiston. Kokonaiskuva laajenee, kun lisäämme infrastruktuuriin etävaraston.
Kuva infrastruktuurin nykytilasta
Linkkejä tutkittavaksi
Samanlaisia työkaluja
3. Säiliöinti (Docker)
Lyhyt kuvaus tekniikasta
Palataan ajassa muutama vuosikymmen taaksepäin, jotta voidaan osoittaa, kuinka konteittaminen on muuttanut pelin sääntöjä. Tuolloin ihmiset ostivat ja käyttivät palvelinkoneita sovellusten suorittamiseen. Useimmissa tapauksissa tarvittavia käynnistysresursseja ei kuitenkaan tiedetty etukäteen. Tämän seurauksena yritykset käyttivät rahaa kalliiden, tehokkaiden palvelimien hankintaan, mutta osaa tästä kapasiteetista ei käytetty kokonaan.
Seuraava evoluution vaihe oli virtuaalikoneet (VM), jotka ratkaisivat rahan tuhlaamisen käyttämättömiin resursseihin. Tämä tekniikka mahdollisti sovellusten suorittamisen toisistaan riippumatta samalla palvelimella ja varaamalla täysin eristettyä tilaa. Mutta valitettavasti kaikilla tekniikoilla on haittapuolensa. Virtuaalikoneen käyttäminen vaatii täyden käyttöjärjestelmän, joka kuluttaa suoritinta, RAM-muistia, tallennustilaa ja käyttöjärjestelmästä riippuen lisenssikustannukset on otettava huomioon. Nämä tekijät vaikuttavat lastausnopeuteen ja vaikeuttavat siirrettävyyttä.
Ja nyt päästään konttien käsittelyyn. Tämä tekniikka ratkaisee jälleen kerran edellisen ongelman, koska kontit eivät käytä täyttä käyttöjärjestelmää, mikä vapauttaa suuren määrän resursseja ja tarjoaa nopean ja joustavan ratkaisun siirrettävyyteen.
Tietenkään konttiteknologia ei ole mitään uutta, ja se esiteltiin ensimmäisen kerran 70-luvun lopulla. Tuohon aikaan tehtiin paljon tutkimusta, kehitystyötä ja yrityksiä. Mutta juuri Docker mukautti tätä tekniikkaa ja teki siitä helposti massojen saatavuuden. Nykyään, kun puhumme konteista, tarkoitamme useimmissa tapauksissa Dockeria. Kun puhumme Docker-säiliöistä, tarkoitamme Linux-säilöjä. Voimme käyttää Windows- ja macOS-järjestelmiä säiliöiden ajamiseen, mutta on tärkeää ymmärtää, että tässä tapauksessa näkyviin tulee ylimääräinen kerros. Esimerkiksi Docker Macissa ajaa hiljaa säilöjä kevyen Linux-virtuaalikoneen sisällä. Palaamme tähän aiheeseen, kun keskustelemme Android-emulaattorien käyttämisestä säilöissä, joten tässä on erittäin tärkeä vivahde, josta on keskusteltava yksityiskohtaisemmin.
Arvoa automaatioinfrastruktuurille
Huomasimme, että konttikuljetus ja Docker ovat siistejä. Tarkastellaan tätä automaation yhteydessä, koska jokaisen työkalun tai tekniikan täytyy ratkaista jokin ongelma. Tehdään pääpiirteittäin testiautomaation ilmeiset ongelmat käyttöliittymätestien yhteydessä:
- valtava määrä riippuvuuksia seleeniä ja erityisesti Appiumia asennettaessa;
- yhteensopivuusongelmat selainversioiden, simulaattorien ja ohjainten välillä;
- eristetyn tilan puute selaimia/simulaattoreita varten, mikä on erityisen tärkeää rinnakkaiskäytössä;
- vaikea hallita ja ylläpitää, jos sinun on käytettävä 10, 50, 100 tai jopa 1000 selainta samanaikaisesti.
Mutta koska Selenium on suosituin automaatiotyökalu ja Docker on suosituin konttityökalu, ei pitäisi olla yllättävää, että joku on yrittänyt yhdistää niitä luodakseen tehokkaan työkalun edellä mainittujen ongelmien ratkaisemiseksi. Harkitsemme tällaisia ratkaisuja yksityiskohtaisemmin.
Seleeniritilä telakassa
Tämä työkalu on Selenium-maailman suosituin useiden selaimien käyttämiseen useissa koneissa ja niiden hallintaan keskuskeskuksesta. Aloitaksesi sinun on rekisteröitävä vähintään 2 osaa: keskitin ja solmu(t). Hub on keskussolmu, joka vastaanottaa kaikki pyynnöt testeistä ja jakaa ne asianmukaisille solmuille. Jokaiselle solmulle voimme määrittää tietyn kokoonpanon, esimerkiksi määrittämällä haluamasi selaimen ja sen version. Meidän on kuitenkin vielä huolehdittava yhteensopivat selainohjaimet itse ja asennettava ne haluttuihin solmuihin. Tästä syystä Selenium-gridiä ei käytetä puhtaassa muodossaan, paitsi silloin, kun meidän on työskenneltävä sellaisten selainten kanssa, joita ei voida asentaa Linux-käyttöjärjestelmään. Kaikissa muissa tapauksissa huomattavasti joustava ja oikea ratkaisu olisi käyttää Docker-kuvia Selenium grid -keskittimen ja -solmujen suorittamiseen. Tämä lähestymistapa yksinkertaistaa huomattavasti solmujen hallintaa, koska voimme valita tarvitsemamme kuvan yhteensopivilla selaimilla ja ohjaimilla, jotka on jo asennettu.
Huolimatta kielteisistä arvioista vakaudesta, erityisesti käytettäessä useita solmuja rinnakkain, Selenium grid on edelleen suosituin työkalu seleenitestien suorittamiseen rinnakkain. On tärkeää huomata, että tähän työkaluun ilmestyy jatkuvasti erilaisia parannuksia ja muutoksia avoimessa lähdekoodissa, jotka torjuvat erilaisia pullonkauloja.
Selenoidi verkkoon
Tämä työkalu on läpimurto Seleenin maailmassa, koska se toimii heti laatikosta ja on helpottanut monien automaatioinsinöörien elämää. Ensinnäkin tämä ei ole toinen seleeniruudukon muunnos. Sen sijaan kehittäjät loivat Golangiin täysin uuden version Selenium Hubista, joka yhdistettynä kevyisiin Docker-kuviin eri selaimille antoi sysäyksen testiautomaation kehitykselle. Lisäksi Selenium Gridin tapauksessa meidän on määritettävä kaikki tarvittavat selaimet ja niiden versiot etukäteen, mikä ei ole ongelma, kun työskentelemme vain yhdellä selaimella. Mutta kun kyse on useista tuetuista selaimista, Selenoid on ykkösratkaisu "selain on demand" -ominaisuuden ansiosta. Ainoa mitä meiltä vaaditaan, on ladata tarvittavat kuvat selaimilla etukäteen ja päivittää asetustiedosto, jonka kanssa Selenoid on vuorovaikutuksessa. Kun Selenoid on saanut pyynnön testeistä, se käynnistää automaattisesti halutun säiliön halutulla selaimella. Kun testi on valmis, Selenoid poistaa kontin käytöstä, mikä vapauttaa resursseja tulevia pyyntöjä varten. Tämä lähestymistapa eliminoi täysin tunnetun "solmujen huononemisen" ongelman, jonka kohtaamme usein seleeniverkossa.
Mutta valitettavasti selenoidi ei silti ole hopealuoti. Meillä on "selain on demand" -ominaisuus, mutta "resurssit on demand" -ominaisuus ei ole vieläkään käytettävissä. Käyttääksemme Selenoidia meidän on otettava se käyttöön fyysisessä laitteistossa tai virtuaalikoneessa, mikä tarkoittaa, että meidän on tiedettävä etukäteen, kuinka monta resurssia on varattava. Luulen, että tämä ei ole ongelma pienissä projekteissa, joissa on 10, 20 tai jopa 30 selainta rinnakkain. Mutta entä jos tarvitsemme 100, 500, 1000 ja enemmän? Ei ole mitään järkeä ylläpitää ja maksaa jatkuvasti niin monia resursseja. Tämän artikkelin kohdissa 5 ja 6 käsittelemme ratkaisuja, joiden avulla voit skaalata ja vähentää siten merkittävästi yrityksen kustannuksia.
Selenoidi Androidille
Selenoidin menestyksen jälkeen verkkoautomaatiotyökaluna ihmiset halusivat jotain vastaavaa Androidille. Ja se tapahtui - Selenoid julkaistiin Android-tuella. Korkean tason käyttäjän näkökulmasta toimintaperiaate muistuttaa verkkoautomaatiota. Ainoa ero on, että Selenoid käyttää selainsäiliöiden sijasta Android-emulaattorisäiliöitä. Mielestäni tämä on tällä hetkellä tehokkain ilmainen työkalu Android-testien suorittamiseen rinnakkain.
En todellakaan haluaisi puhua tämän työkalun kielteisistä puolista, koska pidän siitä todella todella. Silti on samat haitat, jotka koskevat verkkoautomaatiota ja liittyvät skaalaukseen. Tämän lisäksi meidän on puhuttava vielä yhdestä rajoituksesta, joka voi tulla yllätyksenä, jos asennamme työkalua ensimmäistä kertaa. Android-kuvien suorittamiseen tarvitsemme fyysisen koneen tai virtuaalikoneen, jossa on sisäkkäisen virtualisoinnin tuki. Käyttöoppaassa esitän, kuinka tämä aktivoidaan Linux-virtuaalikoneessa. Jos kuitenkin olet macOS-käyttäjä ja haluat ottaa Selenoidin käyttöön paikallisesti, Android-testien suorittaminen ei ole mahdollista. Mutta voit aina käyttää Linux-virtuaalikonetta paikallisesti "sisättyneen virtualisoinnin" kanssa ja ottaa käyttöön Selenoidin sisällä.
Kuva infrastruktuurin nykytilasta
Tämän artikkelin yhteydessä lisäämme kaksi työkalua infrastruktuurin havainnollistamiseen. Nämä ovat Selenium-ruudukko verkkotesteille ja Selenoid Android-testeille. GitHub-opetusohjelmassa näytän sinulle myös, kuinka Selenoidia käytetään verkkotestien suorittamiseen.
Linkkejä tutkittavaksi
Samanlaisia työkaluja
- On muitakin konttityökaluja, mutta Docker on suosituin. Jos haluat kokeilla jotain muuta, muista, että seleenitestien rinnakkaiseen suorittamiseen tarjoamamme työkalut eivät toimi heti.
- Kuten jo todettiin, seleeniruudukossa on monia muunnelmia, esim..
4.CI/CD
Lyhyt kuvaus tekniikasta
Jatkuvan integroinnin käytäntö on varsin suosittu kehitystyössä ja on tasavertainen versionhallintajärjestelmien kanssa. Tästä huolimatta minusta tuntuu, että terminologiassa on sekaannusta. Tässä kappaleessa haluaisin kuvata 3 tämän tekniikan muunnelmaa omasta näkökulmastani. Internetistä löydät monia artikkeleita, joilla on erilaisia tulkintoja, ja on täysin normaalia, jos mielipiteesi eroaa. Tärkeintä on, että olet samalla sivulla kollegojesi kanssa.
Termiä on siis kolme: CI - Jatkuva integrointi, CD - Jatkuva toimitus ja jälleen CD - Jatkuva käyttöönotto. (Alla käytän näitä termejä englanniksi). Jokainen muutos lisää useita lisävaiheita kehitysprosessiisi. Mutta sana jatkuva (jatkuva) on tärkein asia. Tässä yhteydessä tarkoitamme jotain, joka tapahtuu alusta loppuun ilman keskeytyksiä tai manuaalista puuttumista. Katsotaanpa CI:tä ja CD:tä ja CD:tä tässä yhteydessä.
- Jatkuva integraatio tämä on evoluution ensimmäinen askel. Uuden koodin lähettämisen jälkeen palvelimelle odotamme saavamme nopeaa palautetta, että muutokset ovat kunnossa. Tyypillisesti CI sisältää staattisten koodin analysointityökalujen ja yksikkö/sisäisten API-testien suorittamisen, minkä ansiosta voimme saada tietoa koodistamme muutamassa sekunnissa/minuutissa.
- Jatkuva Toimitus on edistyneempi vaihe, jossa suoritamme integraatio-/käyttöliittymätestejä. Tässä vaiheessa emme kuitenkaan saa tuloksia yhtä nopeasti kuin CI:llä. Ensinnäkin tämäntyyppisten testien suorittaminen kestää kauemmin. Toiseksi, ennen käynnistämistä meidän on otettava muutokset käyttöön testi-/vaiheistusympäristössä. Lisäksi, jos puhumme mobiilikehityksestä, näyttää siltä, että lisävaihe luo sovelluksemme koontiversion.
- Jatkuva käyttöönotto olettaa, että julkaisemme muutokset automaattisesti tuotantoon, jos kaikki hyväksyntätestit on läpäissyt edellisissä vaiheissa. Tämän lisäksi julkaisuvaiheen jälkeen voidaan konfiguroida erilaisia vaiheita, kuten savutestien suorittaminen tuotannossa ja kiinnostavien mittareiden kerääminen. Jatkuva käyttöönotto on mahdollista vain, jos automaattiset testit kattavat hyvin. Jos tarvitaan manuaalisia toimenpiteitä, mukaan lukien testaus, tämä ei enää ole Jatkuva (jatkuva). Silloin voimme sanoa, että putkistomme noudattaa vain jatkuvan toimituksen käytäntöä.
Arvoa automaatioinfrastruktuurille
Tässä osiossa minun pitäisi selventää, että kun puhumme päästä päähän -käyttöliittymätesteistä, se tarkoittaa, että meidän tulisi ottaa käyttöön muutokset ja niihin liittyvät palvelut testausympäristöissä. Jatkuva integrointi - prosessi ei sovellu tähän tehtävään ja meidän on huolehdittava vähintään Continuous Deliver -käytäntöjen toteuttamisesta. Jatkuva käyttöönotto on järkevää myös käyttöliittymätestien yhteydessä, jos aiomme suorittaa niitä tuotannossa.
Ja ennen kuin tarkastelemme arkkitehtuurin muutosta, haluan sanoa muutaman sanan GitLab CI:stä. Toisin kuin muut CI/CD-työkalut, GitLab tarjoaa etätietovaraston ja monia muita lisäominaisuuksia. Siten GitLab on enemmän kuin CI. Se sisältää lähdekoodin hallinnan, ketterän hallinnan, CI/CD-putkistot, lokityökalut ja mittareiden keräämisen heti valmiina. GitLab-arkkitehtuuri koostuu Gitlab CI/CD:stä ja GitLab Runnerista. Tässä on lyhyt kuvaus viralliselta verkkosivustolta:
Gitlab CI/CD on verkkosovellus, jossa on API, joka tallentaa tilansa tietokantaan, hallitsee projekteja/koontiversioita ja tarjoaa käyttöliittymän. GitLab Runner on sovellus, joka käsittelee koontiversioita. Se voidaan ottaa käyttöön erikseen ja toimii GitLab CI/CD:n kanssa API:n kautta. Testien suorittamiseen tarvitaan sekä Gitlab-instanssi että Runner.
Kuva infrastruktuurin nykytilasta
Linkkejä tutkittavaksi
Samanlaisia työkaluja
- Ja monet muut
5. Pilviympäristöt
Lyhyt kuvaus tekniikasta
Tässä osiossa puhumme suositusta trendistä nimeltä "julkiset pilvet". Huolimatta valtavista eduista, joita yllä kuvatut virtualisointi- ja konttiteknologiat tarjoavat, tarvitsemme edelleen laskentaresursseja. Yritykset ostavat kalliita palvelimia tai vuokraavat konesaleja, mutta tässä tapauksessa on tehtävä laskelmia (joskus epärealistisia) kuinka paljon resursseja tarvitsemme, käytämmekö niitä 24/7 ja mihin tarkoituksiin. Esimerkiksi tuotanto vaatii palvelimen, joka toimii XNUMX/XNUMX, mutta tarvitsemmeko samanlaisia resursseja testaukseen työajan ulkopuolella? Se riippuu myös suoritettavan testauksen tyypistä. Esimerkkinä voisivat olla kuormitus-/stressitestit, jotka aiomme suorittaa työajan ulkopuolella saadaksemme tuloksia seuraavana päivänä. Mutta ehdottomasti XNUMX/XNUMX palvelimen käytettävyyttä ei vaadita päästä päähän automatisoituihin testeihin eikä varsinkaan manuaalisiin testausympäristöihin. Tällaisia tilanteita varten olisi hyvä hankkia niin paljon resursseja kuin tarvitaan, käyttää niitä ja lopettaa maksaminen, kun niitä ei enää tarvita. Lisäksi olisi hienoa saada ne välittömästi muutamalla hiiren napsautuksella tai suorittamalla pari komentosarjaa. Tähän käytetään julkisia pilviä. Katsotaanpa määritelmää:
"Julkinen pilvi määritellään kolmannen osapuolen tarjoamien tietojenkäsittelypalveluiksi julkisessa Internetissä, jolloin ne ovat kaikkien saatavilla tai ostaa niitä. Ne voivat olla ilmaisia tai myydä tilauksesta, jolloin asiakkaat voivat maksaa vain käyttökohtaisesti kuluttamastaan prosessorin jaksoista, tallennustilasta tai kaistanleveydestä."
On olemassa mielipide, että julkiset pilvet ovat kalliita. Mutta heidän keskeinen ideansa on vähentää yrityksen kustannuksia. Kuten aiemmin mainittiin, julkisten pilvien avulla voit saada resursseja pyynnöstä ja maksaa vain niiden käyttöajasta. Joskus unohdamme myös, että työntekijät saavat palkkaa, ja asiantuntijat ovat myös kallis resurssi. On otettava huomioon, että julkiset pilvet helpottavat infrastruktuurin tukea huomattavasti, jolloin insinöörit voivat keskittyä tärkeämpiin tehtäviin.
Arvoa automaatioinfrastruktuurille
Mitä erityisresursseja tarvitsemme päästä päähän -käyttöliittymätesteihin? Pohjimmiltaan nämä ovat virtuaalikoneita tai klustereita (puhumme Kubernetesista seuraavassa osiossa) selaimien ja emulaattoreiden käyttämiseen. Mitä useampia selaimia ja emulaattoreita haluamme käyttää samanaikaisesti, sitä enemmän suoritinta ja muistia tarvitaan ja sitä enemmän rahaa meidän on maksettava siitä. Näin ollen julkiset pilvet testausautomaation yhteydessä mahdollistavat suuren määrän (100, 200, 1000...) selaimen/emulaattorin käytön tarpeen mukaan, saada testituloksia mahdollisimman nopeasti ja lopettaa maksamisen sellaisista järjettömän resurssiintensiivisistä. tehoa.
Suosituimmat pilvipalveluntarjoajat ovat Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Ohjeessa on esimerkkejä GCP:n käytöstä, mutta yleensä sillä ei ole väliä, mitä käytät automaatiotehtäviin. Ne kaikki tarjoavat suunnilleen samat toiminnot. Yleensä palveluntarjoajan valinnassa johto keskittyy yrityksen koko infrastruktuuriin ja liiketoiminnan vaatimuksiin, mikä ei kuulu tämän artikkelin piiriin. Automaatioinsinöörien kannalta on mielenkiintoisempaa verrata pilvipalveluntarjoajien käyttöä pilvialustojen käyttöön erityisesti testaustarkoituksiin, kuten Sauce Labs, BrowserStack, BitBar ja niin edelleen. Tehdään siis myös! Mielestäni Sauce Labs on tunnetuin pilvitestaustila, minkä vuoksi käytin sitä vertailuna.
GCP vs Sauce Labs automaatiotarkoituksiin:
Kuvitellaan, että meidän on suoritettava 8 verkkotestiä ja 8 Android-testiä samanaikaisesti. Tätä varten käytämme GCP:tä ja käytämme kahta virtuaalikonetta Selenoidilla. Ensimmäisessä nostamme 2 konttia selaimilla. Toisessa on 8 säiliötä emulaattoreilla. Katsotaanpa hintoja:
Tarvitsemme yhden säilön käyttämiseen Chromen kanssa n1-standardi-1 auto. Androidin tapauksessa se tulee olemaan n1-standardi-4 yhdelle emulaattorille. Itse asiassa joustavampi ja halvempi tapa on asettaa tietyt käyttäjäarvot prosessorille/muistille, mutta tällä hetkellä tämä ei ole tärkeää Sauce Labsin vertailussa.
Ja tässä ovat Sauce Labsin käytön tariffit:
Uskon, että olet jo huomannut eron, mutta annan silti taulukon, jossa on laskelmat tehtäväämme varten:
Tarvittavat resurssit
Kuukausittain
Aukioloajat(klo 8-8)
Aukioloajat+ Ennakoiva
GCP Webille
n1-standardi-1 x 8 = n1-standardi-8
$194.18
23 päivää * 12 tuntia * 0.38 = 104.88 dollaria
23 päivää * 12 tuntia * 0.08 = 22.08 dollaria
Sauce Labs Webille
Virtual Cloud8 -rinnakkaistestit
$1.559
-
-
GCP Androidille
n1-standardi-4 x 8: n1-standardi-16
$776.72
23 päivää * 12 tuntia * 1.52 = 419.52 dollaria
23 päivää * 12 tuntia * 0.32 = 88.32 dollaria
Sauce Labs Androidille
Real Device Cloud 8 -rinnakkaistestit
$1.999
-
-
Kuten näette, kustannusero on valtava, varsinkin jos teet testejä vain kahdentoista tunnin työjakson aikana. Mutta voit leikata kustannuksia entisestään, jos käytät ennaltaehkäiseviä koneita. Mikä se on?
Ennakoiva VM on ilmentymä, jonka voit luoda ja suorittaa paljon halvemmalla kuin tavalliset ilmentymät. Compute Engine saattaa kuitenkin lopettaa (ennakolta) nämä esiintymät, jos se vaatii pääsyn kyseisiin resursseihin muihin tehtäviin. Ennakoitavissa olevat ilmentymät ovat Compute Enginen ylikapasiteettia, joten niiden saatavuus vaihtelee käytön mukaan.
Jos sovelluksesi ovat vikasietoisia ja kestävät mahdollisia esiintymien ennaltaehkäisyjä, ennaltaehkäisevät ilmentymät voivat vähentää Compute Engine -kustannuksia merkittävästi. Esimerkiksi eräkäsittelytöitä voidaan suorittaa ennalta ehkäistävissä ilmentymissä. Jos jotkin näistä tapauksista päättyvät käsittelyn aikana, työ hidastuu, mutta ei pysähdy kokonaan. Ennakoiva ilmentymä suorittaa eräkäsittelytehtävät ilman lisätyökuormaa olemassa oleville ilmentymille ja ilman, että sinun tarvitsee maksaa täyttä hintaa ylimääräisistä normaaleista ilmentymistä.
Eikä se ole vieläkään ohi! Todellisuudessa olen varma, että kukaan ei tee testejä 12 tuntia ilman taukoa. Ja jos on, voit käynnistää ja pysäyttää virtuaalikoneita automaattisesti, kun niitä ei tarvita. Todellinen käyttöaika voidaan lyhentää 6 tuntiin päivässä. Silloin tehtävämme yhteydessä maksettava maksu laskee 11 dollariin kuukaudessa 8 selaimella. Eikö tämä olekin ihanaa? Mutta ennakoitavissa olevien koneiden kanssa meidän on oltava varovaisia ja varauduttava keskeytyksiin ja epävakauteen, vaikka nämä tilanteet voidaan ennakoida ja käsitellä ohjelmistoissa. Se on sen arvoista!
Mutta en missään nimessä sano "älä koskaan käytä pilvitestifarmeja". Niillä on useita etuja. Ensinnäkin tämä ei ole vain virtuaalikone, vaan täysimittainen testiautomaatioratkaisu, jossa on joukko toimintoja valmiina: etäkäyttö, lokit, kuvakaappaukset, videotallennus, erilaiset selaimet ja fyysiset mobiililaitteet. Monissa tilanteissa tämä voi olla välttämätön tyylikäs vaihtoehto. Testausalustat ovat erityisen hyödyllisiä IOS-automaatiossa, kun julkiset pilvet voivat tarjota vain Linux/Windows-järjestelmiä. Mutta puhumme iOS:stä seuraavissa artikkeleissa. Suosittelen aina katsomaan tilannetta ja lähtemään tehtävistä: joissain tapauksissa on halvempaa ja tehokkaampaa käyttää julkisia pilviä, toisissa taas testialustat ovat ehdottomasti käytetyn rahan arvoisia.
Kuva infrastruktuurin nykytilasta
Linkkejä tutkittavaksi
Samanlaisia työkaluja:
6. Orkestrointi
Lyhyt kuvaus tekniikasta
Minulla on hyviä uutisia – olemme melkein artikkelin lopussa! Tällä hetkellä automaatioinfrastruktuurimme koostuu web- ja Android-testeistä, jotka suoritamme GitLab CI:n kautta rinnakkain Docker-yhteensopivilla työkaluilla: Selenium grid ja Selenoid. Lisäksi käytämme GCP:n kautta luotuja virtuaalikoneita isännöimään säiliöitä selaimilla ja emulaattoreilla. Kustannusten vähentämiseksi käynnistämme nämä virtuaalikoneet vain pyynnöstä ja pysäytämme ne, kun testausta ei suoriteta. Onko mitään muuta, mikä voisi parantaa infrastruktuuriamme? Vastaus on kyllä! Tapaa Kubernetes (K8s)!
Katsotaanpa ensin, kuinka sanat orkestrointi, klusteri ja Kubernetes liittyvät toisiinsa. Korkealla tasolla orkestrointi on järjestelmä, joka ottaa käyttöön ja hallitsee sovelluksia. Testausautomaatiossa tällaisia konttisovelluksia ovat Selenium grid ja Selenoid. Docker ja K8s täydentävät toisiaan. Ensimmäistä käytetään sovellusten käyttöönottoon, toista orkestrointiin. K8s puolestaan on klusteri. Klusterin tehtävänä on käyttää virtuaalikoneita solmuina, jolloin voit asentaa erilaisia toimintoja, ohjelmia ja palveluita yhden palvelimen (klusterin) sisään. Jos jokin solmuista epäonnistuu, muut solmut poimivat sen, mikä varmistaa sovelluksemme keskeytymättömän toiminnan. Tämän lisäksi K8s:ssa on tärkeä skaalaukseen liittyvä toiminnallisuus, jonka ansiosta saamme automaattisesti optimaalisen määrän resursseja kuormituksen ja asetettujen rajojen mukaan.
Itse asiassa Kubernetesin manuaalinen käyttöönotto tyhjästä ei ole ollenkaan triviaali tehtävä. Jätän linkin kuuluisaan oppaaseen "Kubernetes The Hard Way", ja jos olet kiinnostunut, voit harjoitella sitä. Mutta onneksi on vaihtoehtoisia menetelmiä ja työkaluja. Helpoin tapa on käyttää Google Kubernetes Engineä (GKE) GCP:ssä, jonka avulla saat valmiin klusterin muutamalla napsautuksella. Suosittelen tämän lähestymistavan käyttämistä oppimisen aloittamiseen, sillä sen avulla voit keskittyä K8:n käytön oppimiseen tehtäviisi sen sijaan, että opettelet kuinka sisäiset komponentit tulisi integroida toisiinsa.
Arvoa automaatioinfrastruktuurille
Katsotaanpa muutamia tärkeitä ominaisuuksia, joita K8s tarjoaa:
- sovellusten käyttöönotto: usean solmun klusterin käyttö virtuaalikoneiden sijasta;
- dynaaminen skaalaus: vähentää resurssien kustannuksia, joita käytetään vain kysyntään;
- itseparannus: palojen automaattinen palautus (jonka seurauksena myös säiliöt palautetaan);
- päivitysten käyttöönotto ja muutosten palautukset ilman seisokkeja: päivitystyökalut, selaimet ja emulaattorit eivät keskeytä nykyisten käyttäjien työtä
Mutta K8s ei silti ole hopealuoti. Ymmärtääksemme kaikki tarkastelemiemme työkalujen (Selenium grid, Selenoid) edut ja rajoitukset, käsittelemme lyhyesti K8:n rakennetta. Klusteri sisältää kahden tyyppisiä solmuja: pääsolmut ja työntekijäsolmut. Pääsolmut ovat vastuussa hallinnasta, käyttöönotosta ja aikataulutuspäätöksistä. Workers-solmut ovat missä sovellukset käynnistetään. Solmut sisältävät myös konttiajonaikaisen ympäristön. Meidän tapauksessamme tämä on Docker, joka vastaa kontteihin liittyvistä toiminnoista. Mutta on myös vaihtoehtoisia ratkaisuja mm. On tärkeää ymmärtää, että hilseily tai itsestään paraneminen ei koske suoraan säiliöitä. Tämä toteutetaan lisäämällä/vähentämällä koteloiden määrää, jotka puolestaan sisältävät kontteja (yleensä yksi kontti per pod, mutta tehtävästä riippuen niitä voi olla enemmän). Korkean tason hierarkia koostuu työntekijäsolmuista, joiden sisällä on tyynyjä, joiden sisällä nostetaan kontit.
Skaalausominaisuus on avainasemassa, ja sitä voidaan soveltaa sekä klusterin solmujoukon solmuihin että solmun sisällä oleviin podeihin. On olemassa 2 skaalaustyyppiä, jotka koskevat sekä solmuja että podeja. Ensimmäinen tyyppi on vaaka - skaalaus tapahtuu lisäämällä solmujen/palojen määrää. Tämä tyyppi on suositeltavampi. Toinen tyyppi on vastaavasti pystysuora. Skaalaus suoritetaan lisäämällä solmujen/palojen kokoa, ei niiden määrää.
Tarkastellaan nyt työkalujamme yllä olevien ehtojen yhteydessä.
Seleeniverkko
Kuten aiemmin mainittiin, seleeniverkko on erittäin suosittu työkalu, eikä ole yllätys, että se on pakattu konttiin. Siksi ei ole yllättävää, että Selenium-verkkoa voidaan ottaa käyttöön K8sissa. Esimerkki siitä, kuinka tämä tehdään, löytyy virallisesta K8s-arkistosta. Kuten tavallista, liitän linkit osion loppuun. Lisäksi opas näyttää, kuinka tämä tehdään Terraformissa. Siellä on myös ohjeet selaimen säilöjä sisältävien koteloiden määrän skaalaamiseen. Mutta automaattinen skaalaustoiminto K8s:n yhteydessä ei ole vieläkään täysin ilmeinen tehtävä. Kun aloitin opiskelun, en löytänyt käytännön ohjeita tai suosituksia. Useiden tutkimusten ja kokeilujen jälkeen DevOps-tiimin tuella valitsimme lähestymistavan, jossa nostetaan tarvittavat selaimet sisältäviä säiliöitä yhteen podiin, joka sijaitsee yhden työntekijäsolmun sisällä. Tämä menetelmä antaa meille mahdollisuuden soveltaa solmujen horisontaalisen skaalauksen strategiaa lisäämällä niiden määrää. Toivon, että tämä muuttuu tulevaisuudessa ja näemme yhä enemmän kuvauksia paremmista lähestymistavoista ja valmiista ratkaisuista, etenkin Selenium grid 4:n julkaisun jälkeen muuttuneella sisäisellä arkkitehtuurilla.
Selenoidi:
Selenoidin käyttöönotto K8:ssa on tällä hetkellä suurin pettymys. Ne eivät ole yhteensopivia. Teoriassa voimme nostaa Selenoid-säiliön kotelon sisään, mutta kun Selenoid alkaa käynnistää säiliöitä selaimilla, ne ovat silti samassa kotelossa. Tämä tekee skaalaamisesta mahdotonta, ja tämän seurauksena Selenoidin työ klusterin sisällä ei eroa työstä virtuaalikoneen sisällä. Tarinan loppu.
Kuu:
Tietäen tämän pullonkaulan työskennellessään Selenoidin kanssa kehittäjät julkaisivat tehokkaamman työkalun nimeltä Moon. Tämä työkalu on alun perin suunniteltu toimimaan Kubernetesin kanssa, ja sen seurauksena automaattista skaalausta voidaan ja pitäisi käyttää. Lisäksi sanoisin, että tällä hetkellä on ainoa Selenium-maailman työkalu, jolla on natiivi K8s-klusterituki heti valmiina (ei enää saatavilla, katso seuraava työkalu ). Moonin tärkeimmät ominaisuudet, jotka tarjoavat tämän tuen, ovat:
Täysin valtioton. Selenoidi tallentaa muistiin tietoja käynnissä olevista selainistunnoista. Jos jostain syystä sen prosessi kaatuu - kaikki käynnissä olevat istunnot menetetään. Kuulla sitä vastoin ei ole sisäistä tilaa, ja se voidaan kopioida palvelinkeskuksissa. Selainistunnot pysyvät elossa, vaikka yksi tai useampi replika katkeaisi.
Joten, Moon on loistava ratkaisu, mutta siinä on yksi ongelma: se ei ole ilmainen. Hinta riippuu istuntojen määrästä. Voit suorittaa vain 0-4 istuntoa ilmaiseksi, mikä ei ole erityisen hyödyllistä. Mutta viidennestä istunnosta alkaen sinun on maksettava 5 dollaria jokaisesta. Tilanne voi vaihdella yhtiöittäin, mutta meidän tapauksessamme Moonin käyttö on turhaa. Kuten yllä kuvailin, voimme käyttää VM:itä Selenium Gridillä pyynnöstä tai lisätä klusterin solmujen määrää. Noin yhden putken aikana käynnistämme 500 selainta ja pysäytämme kaikki resurssit, kun testit on suoritettu. Jos käyttäisimme Moonia, joutuisimme maksamaan lisää 500 x 5 = 2500 dollaria kuukaudessa riippumatta siitä, kuinka usein teemme testejä. Jälleen, en sano, että älä käytä Moonia. Tehtävissäsi tämä voi olla korvaamaton ratkaisu esimerkiksi, jos organisaatiossasi on monia projekteja/tiimejä ja tarvitset valtavan yhteisen klusterin kaikille. Kuten aina, jätän linkin loppuun ja suosittelen tekemään kaikki tarvittavat laskelmat tehtäväsi yhteydessä.
Callisto: (Huomio! Tämä ei ole alkuperäisessä artikkelissa, ja se sisältyy vain venäjänkieliseen käännökseen)
Kuten sanoin, Seleeni on erittäin suosittu työkalu, ja IT-ala kehittyy erittäin nopeasti. Kun työskentelin käännöksen parissa, verkkoon ilmestyi uusi lupaava työkalu nimeltä Callisto (hei Cypress ja muut seleenin tappajat). Se toimii natiivisti K8:n kanssa ja mahdollistaa selenoidisäiliöiden käyttämisen koteloissa, jotka on jaettu solmujen kesken. Kaikki toimii heti laatikosta, mukaan lukien automaattinen skaalaus. Loistava, mutta täytyy testata. Olen jo onnistunut ottamaan tämän työkalun käyttöön ja suorittamaan useita kokeiluja. Mutta on liian aikaista tehdä johtopäätöksiä, saatuaan tuloksia pitkän matkan päästä, ehkä teen katsauksen tulevissa artikkeleissa. Jätän toistaiseksi vain linkkejä riippumattomiin tutkimuksiin.
Kuva infrastruktuurin nykytilasta
Linkkejä tutkittavaksi
Samanlaisia työkaluja
7. Infrastruktuuri koodina (IaC)
Lyhyt kuvaus tekniikasta
Ja nyt päästään viimeiseen osaan. Tyypillisesti tämä tekniikka ja siihen liittyvät tehtävät eivät ole automaatioinsinöörien vastuulla. Ja tähän on syitä. Ensinnäkin monissa organisaatioissa infrastruktuurikysymykset ovat DevOps-osaston hallinnassa, eivätkä kehitystiimit juuri välitä siitä, mikä saa putkilinjan toimimaan ja miten kaikkea siihen liittyvää on tuettava. Toiseksi, olkaamme rehellisiä, Infrastructure as Code (IaC) -käytäntö ei ole vieläkään omaksunut monissa yrityksissä. Mutta siitä on ehdottomasti tullut suosittu trendi, ja on tärkeää yrittää olla mukana siihen liittyvissä prosesseissa, lähestymistavoissa ja työkaluissa. Tai ainakin pysyä ajan tasalla.
Aloitetaan tämän lähestymistavan käytön motivaatiosta. Olemme jo keskustelleet siitä, että testien suorittamiseen GitlabCI:ssä tarvitsemme vähintään resurssit Gitlab Runnerin suorittamiseen. Ja jos haluat käyttää säiliöitä selaimilla/emulaattoreilla, meidän on varattava virtuaalikone tai klusteri. Testausresurssien lisäksi tarvitsemme huomattavan määrän kapasiteettia tukemaan kehitys-, vaiheistus-, tuotantoympäristöjä, joihin kuuluvat myös tietokannat, automaattiset aikataulut, verkkokonfiguraatiot, kuormituksen tasaajat, käyttöoikeudet jne. Avainkysymys on kaiken tukeminen. Meillä on useita tapoja tehdä muutoksia ja julkaista päivityksiä. Esimerkiksi GCP:n yhteydessä voimme käyttää selaimen käyttöliittymäkonsolia ja suorittaa kaikki toiminnot napsauttamalla painikkeita. Vaihtoehtona olisi käyttää API-kutsuja vuorovaikutuksessa pilvikokonaisuuksien kanssa tai gcloud-komentorivityökalun avulla haluttujen manipulaatioiden suorittamiseen. Mutta kun erilaisia kokonaisuuksia ja infrastruktuurielementtejä on todella paljon, kaikkien toimintojen suorittaminen manuaalisesti tulee vaikeaksi tai jopa mahdottomaksi. Lisäksi kaikki nämä manuaaliset toiminnot ovat hallitsemattomia. Emme voi lähettää niitä tarkistettavaksi ennen niiden suorittamista, käyttää versionhallintajärjestelmää emmekä nopeasti peruuttaa tapahtumaan johtaneita muutoksia. Tällaisten ongelmien ratkaisemiseksi suunnittelijat loivat ja luovat automaattisia bash/shell-skriptejä, jotka eivät ole paljon parempia kuin aikaisemmat menetelmät, koska niitä ei ole niin helppo nopeasti lukea, ymmärtää, ylläpitää ja muokata proseduurityyliin.
Tässä artikkelissa ja ohjeoppaassa käytän kahta IaC-käytäntöön liittyvää työkalua. Nämä ovat Terraform ja Ansible. Jotkut ihmiset uskovat, että niitä ei ole järkevää käyttää samanaikaisesti, koska niiden toiminnallisuus on samanlainen ja ne ovat keskenään vaihdettavissa. Mutta tosiasia on, että aluksi heille annetaan täysin erilaisia tehtäviä. Ja se, että näiden työkalujen tulisi täydentää toisiaan, vahvistettiin HashiCorpia ja RedHatia edustavien kehittäjien yhteisessä esittelyssä. Käsitteellinen ero on, että Terraform on provisiointityökalu itse palvelimien hallintaan. Vaikka Ansible on kokoonpanonhallintatyökalu, jonka tehtävänä on asentaa, määrittää ja hallita ohjelmistoja näille palvelimille.
Toinen näiden työkalujen keskeinen erottava piirre on koodaustyyli. Toisin kuin bash ja Ansible, Terraform käyttää deklaratiivista tyyliä, joka perustuu kuvaukseen halutusta lopputilasta, joka saavutetaan suorituksen tuloksena. Jos esimerkiksi aiomme luoda 10 virtuaalikonetta ja ottaa muutokset käyttöön Terraformin kautta, saamme 10 virtuaalikonetta. Jos suoritamme komentosarjan uudelleen, mitään ei tapahdu, koska meillä on jo 10 virtuaalikonetta, ja Terraform tietää tämän, koska se tallentaa infrastruktuurin nykyisen tilan tilatiedostoon. Mutta Ansible käyttää menettelytapaa, ja jos pyydät sitä luomaan 10 VM:tä, ensimmäisen käynnistyksen yhteydessä saamme 10 VM:tä, samanlaisia kuin Terraform. Mutta uudelleenkäynnistyksen jälkeen meillä on jo 20 VM:tä. Tämä on tärkeä ero. Proseduurityylissä emme tallenna nykyistä tilaa ja kuvailemme vain suoritettavien vaiheiden sarjaa. Tietenkin voimme käsitellä erilaisia tilanteita, lisätä useita tarkistuksia resurssien olemassaolosta ja nykytilasta, mutta ei ole mitään järkeä tuhlata aikaamme ja ponnistella tämän logiikan hallitsemiseen. Lisäksi tämä lisää virheiden riskiä.
Yhteenvetona kaikesta yllä olevasta voimme päätellä, että Terraform ja deklaratiivinen merkintä ovat sopivampi työkalu palvelimien hallintaan. Mutta on parempi delegoida kokoonpanonhallinta Ansiblelle. Kun tämä on poissa tieltä, tarkastellaan käyttötapauksia automaation yhteydessä.
Arvoa automaatioinfrastruktuurille
Ainoa tärkeä asia, joka on ymmärrettävä tässä, on se, että testiautomaatioinfrastruktuuria tulisi tarkastella osana koko yrityksen infrastruktuuria. Tämä tarkoittaa, että kaikkia IaC-käytäntöjä tulee soveltaa globaalisti koko organisaation resursseihin. Kuka tästä on vastuussa, riippuu prosesseistasi. DevOps-tiimi on kokeneempi näissä asioissa, he näkevät kokonaiskuvan siitä, mitä tapahtuu. Laadunvarmistusinsinöörit ovat kuitenkin enemmän mukana rakennusautomaatioprosessissa ja putkilinjan rakenteessa, jolloin he näkevät paremmin kaikki tarvittavat muutokset ja parannusmahdollisuudet. Paras vaihtoehto on työskennellä yhdessä, vaihtaa tietoja ja ideoita odotetun tuloksen saavuttamiseksi.
Tässä on muutamia esimerkkejä Terraformin ja Ansiblen käyttämisestä testiautomaation ja työkalujen, joista keskustelimme aiemmin, yhteydessä:
1. Kuvaile VM:ien ja klustereiden tarvittavat ominaisuudet ja parametrit Terraformin avulla.
2. Asenna Ansiblen avulla testaukseen tarvittavat työkalut: docker, Selenoid, Selenium Grid ja lataa tarvittavat versiot selaimista/emulaattoreista.
3. Kuvaile Terraformin avulla sen VM:n ominaisuudet, jossa GitLab Runner käynnistetään.
4. Asenna GitLab Runner ja tarvittavat mukana tulevat työkalut Ansiblen avulla, aseta asetukset ja määritykset.
Kuva infrastruktuurin nykytilasta
Linkkejä tutkimiseen:
Samanlaisia työkaluja
Tehdään se yhteenveto!
Vaihe
Elektroniikka
Työkalut
Arvoa automaatioinfrastruktuurille
1
Paikallinen juoksu
Node.js, Seleeni, Appium
- Suosituimmat verkko- ja mobiilityökalut
- Tukee monia kieliä ja alustoja (mukaan lukien Node.js)
2
Versioiden hallintajärjestelmät
mennä
- Samanlaisia etuja kehityskoodilla
3
Konttikäsittely
Docker, Selenium grid, Selenoid (Web, Android)
- Testien suorittaminen rinnakkain
- Eristetyt ympäristöt
- Yksinkertaiset, joustavat versiopäivitykset
- Pysäyttää dynaamisesti käyttämättömät resurssit
- Helppo asentaa
4
CI/CD
Gitlab CI
- Testaa osaa putkistosta
- Pikapalaute
- Näkyvyys koko yritykselle/tiimille
5
Cloud-alustat
Google Cloud Platform
- Resurssit pyynnöstä (maksamme vain tarvittaessa)
- Helppo hallita ja päivittää
- Kaikkien resurssien näkyvyys ja hallinta
6
orkestrointi
Kubernetes
Säilöissä, joissa on selaimet/emulaattorit koteloiden sisällä:
- Skaalaus / automaattinen skaalaus
- Itsensä parantava
- Päivitykset ja palautukset keskeytyksettä
7
Infrastruktuuri koodina (IaC)
Terraform, Ansible
- Samanlaisia etuja kehitysinfrastruktuurin kanssa
- Kaikki koodiversion edut
- Helppo tehdä muutoksia ja ylläpitää
- Täysin automatisoitu
Mielikarttakaaviot: infrastruktuurin kehitys
vaihe 1: Paikallinen
vaihe 2: VCS
vaihe 3: Säiliöinti
vaihe 4: CI/CD
vaihe 5: Pilviympäristöt
vaihe 6: Orkestrointi
vaihe 7: IaC
Mitä seuraavaksi?
Joten tämä on artikkelin loppu. Lopuksi haluaisin kuitenkin tehdä joitakin sopimuksia kanssasi.
Sinun puoleltasi
Kuten alussa sanoin, haluaisin artikkelista olevan käytännön hyötyä ja auttavan sinua soveltamaan hankittua tietoa todellisessa työssä. lisään taas.
Mutta sen jälkeenkään älä pysähdy, harjoittele, opi asiaa koskevia linkkejä ja kirjoja, ota selvää, miten se toimii yrityksessäsi, etsi parannettavia paikkoja ja osallistu siihen. Onnea!
Minun puoleltani
Otsikosta huomaa, että tämä oli vasta ensimmäinen osa. Huolimatta siitä, että se osoittautui melko suureksi, tärkeitä aiheita ei silti käsitellä täällä. Toisessa osassa aion tarkastella automaatioinfrastruktuuria IOS:n kontekstissa. Koska Apple rajoittaa iOS-simulaattorien käyttöä vain macOS-järjestelmissä, ratkaisuvalikoimamme on kapeampi. Emme esimerkiksi voi käyttää Dockeria simulaattorin suorittamiseen tai julkisia pilviä virtuaalikoneiden ajamiseen. Mutta tämä ei tarkoita, etteikö muita vaihtoehtoja olisi. Yritän pitää sinut ajan tasalla edistyneillä ratkaisuilla ja nykyaikaisilla työkaluilla!
En myöskään ole maininnut kovin suuria seurantaan liittyviä aiheita. Osassa 3 aion tarkastella suosituimpia infrastruktuurin seurantatyökaluja ja mitä tietoja ja mittareita on otettava huomioon.
Ja lopuksi. Tulevaisuudessa aion julkaista videokurssin testiinfrastruktuurin rakentamisesta ja suosituista työkaluista. Tällä hetkellä DevOps-kursseja ja luentoja on Internetissä melko paljon, mutta kaikki materiaalit esitetään kehittämisen, ei testiautomaation kontekstissa. Tässä asiassa kaipaan todella palautetta siitä, onko tällainen kurssi kiinnostava ja arvokas testaajien ja automaatioinsinöörien yhteisölle. Kiitos jo etukäteen!
Lähde: will.com