Parto 1: Retejo/Androido
Примечание: ĉi tiu artikolo estas traduko en la rusan de la originala artikolo Tamen, ĉiuj ilustraĵoj, ligiloj, citaĵoj kaj terminoj estas konservitaj en la originala lingvo por eviti misprezenton de la signifo kiam tradukite en la rusan. Mi deziras al vi feliĉan studado!
Nuntempe, la specialaĵo DevOps estas unu el la plej postulataj en la IT-industrio. Se vi malfermas popularajn laborserĉajn retejojn kaj filtras laŭ salajro, vi vidos, ke laboroj rilataj al DevOps estas ĉe la supro de la listo. Tamen, gravas kompreni, ke ĉi tio ĉefe rilatas al "Alta" pozicio, kio implicas, ke la kandidato havas altan nivelon de kapabloj, scion pri teknologio kaj iloj. Ĉi tio ankaŭ venas kun alta grado de respondeco asociita kun la seninterrompa operacio de produktado. Tamen, ni komencis forgesi kio estas DevOps. Komence, ĝi ne estis iu specifa persono aŭ sekcio. Se ni serĉas difinojn de tiu ĉi termino, ni trovos multajn belajn kaj ĝustajn substantivojn, kiel metodaro, praktikoj, kultura filozofio, grupo de konceptoj ktp.
Mia specialiĝo estas testa aŭtomatiga inĝeniero (QA aŭtomatiga inĝeniero), sed mi kredas, ke ĝi ne devas esti asociita nur kun verkado de aŭtomataj testoj aŭ evoluigado de testa kadra arkitekturo. En 2020, scio pri aŭtomatiga infrastrukturo ankaŭ estas esenca. Ĉi tio permesas vin organizi la aŭtomatigan procezon mem, de farado de testoj ĝis liverado de rezultoj al ĉiuj koncernatoj konforme al viaj celoj. Kiel rezulto, DevOps-kapabloj estas necesaj por plenumi la laboron. Kaj ĉio ĉi estas bona, sed, bedaŭrinde, estas problemo (spoiler: ĉi tiu artikolo provas simpligi ĉi tiun problemon). La punkto estas, ke DevOps estas malfacila. Kaj ĉi tio estas evidenta, ĉar kompanioj ne multe pagos por io, kio estas facila por fari... En la mondo DevOps, ekzistas granda nombro da iloj, terminoj kaj praktikoj, kiujn oni devas regi. Ĉi tio estas precipe malfacila komence de kariero kaj dependas de la amasigita teknika sperto.
fonto:
Ĉi tie ni verŝajne finos kun la enkonduka parto kaj koncentriĝos pri la celo de ĉi tiu artikolo.
Pri kio temas ĉi tiu artikolo?
En ĉi tiu artikolo, mi dividos mian sperton pri konstruado de testa aŭtomatiga infrastrukturo. Estas multaj fontoj de informo en la Interreto pri diversaj iloj kaj kiel uzi ilin, sed mi ŝatus rigardi ilin pure en la kunteksto de aŭtomatigo. Mi kredas, ke multaj aŭtomatigaj inĝenieroj konas la situacion, kiam neniu krom vi faras la evoluintajn testojn aŭ zorgas pri konservi ilin. Kiel rezulto, testoj malnoviĝas kaj vi devas pasigi tempon por ĝisdatigi ilin. Denove, komence de kariero, ĉi tio povas esti sufiĉe malfacila tasko: saĝe decidi, kiuj iloj devas helpi forigi difinitan problemon, kiel elekti, agordi kaj konservi ilin. Iuj testantoj turnas sin al DevOps (homoj) por helpo kaj, ni estu honestaj, ĉi tiu aliro funkcias. En multaj kazoj ĉi tio povas esti la sola opcio ĉar ni ne havas videblecon pri ĉiuj dependecoj. Sed kiel ni scias, DevOps estas tre okupataj uloj, ĉar ili devas pensi pri la infrastrukturo de la tuta kompanio, deplojo, monitorado, mikroservoj kaj aliaj similaj taskoj depende de la organizo/teamo. Kiel kutime, aŭtomatigo ne estas prioritato. En tia kazo, ni devas provi fari ĉion eblan nianflanke de la komenco ĝis la fino. Ĉi tio reduktos dependecojn, akcelos laborfluon, plibonigos niajn kapablojn kaj permesos al ni vidi la pli grandan bildon pri tio, kio okazas.
La artikolo prezentas la plej popularajn kaj popularajn ilojn kaj montras kiel uzi ilin por konstrui aŭtomatigan infrastrukturon paŝon post paŝo. Ĉiu grupo estas reprezentita per iloj kiuj estis provitaj per persona sperto. Sed tio ne signifas, ke vi devas uzi la samon. La iloj mem ne estas gravaj, ili aperas kaj malnoviĝas. Nia inĝenieristiko estas kompreni la bazajn principojn: kial ni bezonas ĉi tiun grupon da iloj kaj kiajn laborproblemojn ni povas solvi per ilia helpo. Tial fine de ĉiu sekcio mi lasas ligilojn al similaj iloj, kiuj povas esti uzataj en via organizo.
Kio ne estas en ĉi tiu artikolo
Mi ripetas denove, ke la artikolo ne temas pri specifaj iloj, do ne estos enmetoj de kodo el la dokumentado kaj priskriboj de specifaj komandoj. Sed fine de ĉiu sekcio mi lasas ligilojn por detala studo.
Ĉi tio estas farita ĉar:
- tiu ĉi materialo estas tre facile trovebla en diversaj fontoj (dokumentado, libroj, videokursoj);
- se ni komencos profundiĝi, ni devos skribi 10, 20, 30 partojn de ĉi tiu artikolo (dum la planoj estas 2-3);
- Mi simple ne volas malŝpari vian tempon, ĉar vi eble volas uzi aliajn ilojn por atingi la samajn celojn.
Praktiko
Mi tre ŝatus, ke ĉi tiu materialo estu utila por ĉiu leganto, kaj ne nur legita kaj forgesita. En iu ajn studo, praktiko estas tre grava ero. Por tio mi preparis. Ankaŭ estas hejmtasko, kiu atendas vin por certigi, ke vi ne senpripense kopias la liniojn de la ordonoj, kiujn vi plenumas.
Plano
Paŝo
teknologio
Iloj
1
Loka funkciado (preparu retajn / androidajn pruvtestojn kaj rulu ĝin loke)
Node.js, Seleno, Appium
2
Versiaj kontrolaj sistemoj
Git
3
Kontenigo
Docker, Selena krado, Selenoido (Reto, Android)
4
CI/KD
Gitlab CI
5
Nubaj platformoj
Google Nubo Platformo
6
Orkestrado
Kubernetoj
7
Infrastrukturo kiel kodo (IaC)
Terraform, Ansible
Strukturo de ĉiu sekcio
Por konservi la rakonton klara, ĉiu sekcio estas priskribita laŭ la sekva skizo:
- mallonga priskribo de la teknologio,
- valoro por aŭtomatiga infrastrukturo,
- ilustraĵo de la nuna stato de la infrastrukturo,
- ligiloj por studi,
- similaj iloj.
1. Kuru provojn loke
Mallonga priskribo de la teknologio
Ĉi tio estas nur prepara paŝo por ekzekuti la demo-testojn loke kaj kontroli, ke ili trapasas. En la praktika parto, Node.js estas uzata, sed la programlingvo kaj platformo ankaŭ ne gravas kaj vi povas uzi tiujn, kiuj estas uzataj en via kompanio.
Tamen, kiel aŭtomatigaj iloj, mi rekomendas uzi Selenium WebDriver por TTT-platformoj kaj Appium por la Android-platformo, respektive, ĉar en la sekvaj paŝoj ni uzos Docker-bildojn, kiuj estas tajloritaj por labori specife kun ĉi tiuj iloj. Krome, rilatante al la laborpostuloj, ĉi tiuj iloj estas la plej postulataj en la merkato.
Kiel vi eble rimarkis, ni nur konsideras retajn kaj Android-testojn. Bedaŭrinde, iOS estas tute alia rakonto (dankon Apple). Mi planas montri IOS-rilatajn solvojn kaj praktikojn en venontaj partoj.
Valoro por aŭtomatiga infrastrukturo
De infrastruktura perspektivo, funkcii loke ne disponigas ajnan valoron. Vi nur kontrolas, ke la testoj funkcias sur la loka maŝino en lokaj retumiloj kaj simuliloj. Sed ĉiukaze ĉi tio estas necesa deirpunkto.
Ilustraĵo de la nuna stato de infrastrukturo
Ligiloj por esplori
Similaj iloj
- ajna programlingvo kiun vi ŝatas kune kun Selenium/Appium-testoj;
- iuj provoj;
- ajna testkuristo.
2. Versiokontrolaj sistemoj (Git)
Mallonga priskribo de la teknologio
Ne estos granda revelacio por iu ajn, se mi diros, ke versio-kontrolo estas ekstreme grava parto de evoluo, kaj en teamo kaj individue. Surbaze de diversaj fontoj, estas sekure diri, ke Git estas la plej populara reprezentanto. Versia kontrolsistemo disponigas multajn avantaĝojn, kiel ekzemple koddividado, stokado de versioj, restarigo al antaŭaj branĉoj, monitorado de projektohistorio kaj sekurkopioj. Ni ne diskutos pri ĉiu punkto detale, ĉar mi certas, ke vi tre konas ĝin kaj uzas ĝin en via ĉiutaga laboro. Sed se subite ne, tiam mi rekomendas paŭzi la legadon de ĉi tiu artikolo kaj plenigi ĉi tiun mankon kiel eble plej baldaŭ.
Valoro por aŭtomatiga infrastrukturo
Kaj ĉi tie vi povas demandi prudentan demandon: "Kial li rakontas al ni pri Git? Ĉiuj scias ĉi tion kaj uzas ĝin kaj por evolukodo kaj por aŭtomata testa kodo." Vi tute pravos, sed en ĉi tiu artikolo ni parolas pri infrastrukturo kaj ĉi tiu sekcio funkcias kiel antaŭrigardo por sekcio 7: "Infrastrukturo kiel Kodo (IaC)". Por ni, ĉi tio signifas, ke la tuta infrastrukturo, inkluzive de testado, estas priskribita en formo de kodo, do ni ankaŭ povas apliki versionajn sistemojn al ĝi kaj akiri similajn avantaĝojn kiel por evoluigo kaj aŭtomatiga kodo.
Ni rigardos IaC pli detale en Paŝo 7, sed eĉ nun vi povas komenci uzi Git loke kreante lokan deponejon. La granda bildo estos vastigita kiam ni aldonos malproksiman deponejon al la infrastrukturo.
Ilustraĵo de la nuna stato de infrastrukturo
Ligiloj por esplori
Similaj iloj
3. Kontenigo (Docker)
Mallonga priskribo de la teknologio
Por pruvi kiel kontenerigo ŝanĝis la regulojn de la ludo, ni reiru en la tempo kelkajn jardekojn. Tiam homoj aĉetis kaj uzis servilmaŝinojn por ruli aplikojn. Sed en la plej multaj kazoj, la postulataj komencaj rimedoj ne estis konataj anticipe. Kiel rezulto, kompanioj elspezis monon por aĉeto de multekostaj, potencaj serviloj, sed iuj el ĉi tiu kapablo ne estis tute uzataj.
La sekva etapo de evoluo estis virtualaj maŝinoj (VMs), kiuj solvis la problemon de malŝparado de mono sur neuzataj rimedoj. Ĉi tiu teknologio ebligis ruli aplikojn sendepende unu de la alia ene de la sama servilo, asignante tute izolitan spacon. Sed, bedaŭrinde, ajna teknologio havas siajn malavantaĝojn. Ruli VM postulas plenan operaciumon, kiu konsumas CPU, RAM, stokadon kaj, depende de la OS, licenckostoj devas esti enkalkulitaj. Ĉi tiuj faktoroj influas ŝarĝan rapidecon kaj malfaciligas la porteblon.
Kaj nun ni venas al kontenerigo. Denove, ĉi tiu teknologio solvas la antaŭan problemon, ĉar ujoj ne uzas plenan OS, kiu liberigas grandan kvanton da rimedoj kaj provizas rapidan kaj flekseblan solvon por porteblo.
Kompreneble, kontenerigo teknologio estas nenio nova kaj unue estis lanĉita en la malfruaj 70-aj jaroj. En tiuj tagoj, multaj esploroj, evoluoj kaj provoj estis faritaj. Sed estis Docker kiu adaptis ĉi tiun teknologion kaj faris ĝin facile alirebla por la amasoj. Nuntempe, kiam ni parolas pri ujoj, en la plej multaj kazoj ni celas Docker. Kiam ni parolas pri Docker-ujoj, ni celas Linuksajn ujojn. Ni povas uzi Windows kaj macOS-sistemojn por ruli ujojn, sed gravas kompreni, ke ĉi-kaze aperas plia tavolo. Ekzemple, Docker en Mac silente kuras ujojn ene de malpeza Linuksa VM. Ni revenos al ĉi tiu temo kiam ni diskutos pri funkciado de Android-emuliloj ene de ujoj, do ĉi tie estas tre grava nuanco, kiu devas esti diskutita pli detale.
Valoro por aŭtomatiga infrastrukturo
Ni eksciis, ke kontenerigo kaj Docker estas bonegaj. Ni rigardu ĉi tion en la kunteksto de aŭtomatigo, ĉar ĉiu ilo aŭ teknologio bezonas solvi problemon. Ni skizu la evidentajn problemojn de testa aŭtomatigo en la kunteksto de UI-testoj:
- grandega nombro da dependecoj instalante Selenium kaj precipe Appium;
- problemoj de kongruo inter versioj de retumiloj, simuliloj kaj ŝoforoj;
- manko de izolita spaco por retumiloj/simuliloj, kiu estas precipe kritika por paralela funkciado;
- malfacile administrebla kaj konservi se vi bezonas ruli 10, 50, 100 aŭ eĉ 1000 retumiloj samtempe.
Sed ĉar Selenium estas la plej populara aŭtomatiga ilo kaj Docker estas la plej populara konteneriga ilo, ne devas surprizi, ke iu provis kombini ilin por krei potencan ilon por solvi la supre menciitajn problemojn. Ni konsideru tiajn solvojn pli detale.
Selena krado en docker
Ĉi tiu ilo estas la plej populara en la Selenium-mondo por funkcii plurajn retumilon sur pluraj maŝinoj kaj administri ilin de centra nabo. Por komenci, vi devas registri almenaŭ 2 partojn: Nabo kaj Nodo(j). Nabo estas centra nodo, kiu ricevas ĉiujn petojn de testoj kaj distribuas ilin al la taŭgaj Nodoj. Por ĉiu Nodo ni povas agordi specifan agordon, ekzemple, specifante la deziratan retumilon kaj ĝian version. Tamen, ni ankoraŭ devas zorgi pri kongruaj retumiloj mem kaj instali ilin sur la dezirataj Nodoj. Tial, Selenium krado ne estas uzata en sia pura formo, krom kiam ni bezonas labori kun retumiloj kiuj ne povas esti instalitaj en Linukso OS. Por ĉiuj aliaj kazoj, signife fleksebla kaj ĝusta solvo estus uzi Docker-bildojn por ruli Selenium grid Hub kaj Nodes. Ĉi tiu aliro multe simpligas administradon de nodoj, ĉar ni povas elekti la bildon, kiun ni bezonas kun kongruaj versioj de retumiloj kaj ŝoforoj jam instalitaj.
Malgraŭ negativaj recenzoj pri stabileco, precipe kiam oni rulas grandan nombron da Nodoj paralele, Selenium-krado ankoraŭ estas la plej populara ilo por ruli Seleniajn provojn paralele. Gravas noti, ke diversaj plibonigoj kaj modifoj de ĉi tiu ilo konstante aperas en malfermfonteco, kiuj batalas diversajn botelojn.
Selenoid por Retejo
Ĉi tiu ilo estas sukceso en la mondo de Selenio ĉar ĝi funkcias tuj el la skatolo kaj multe plifaciligis la vivon de multaj aŭtomatigaj inĝenieroj. Antaŭ ĉio, ĉi tio ne estas alia modifo de Selena krado. Anstataŭe, la programistoj kreis tute novan version de Selenium Hub en Golang, kiu, kombinita kun malpezaj Docker-bildoj por diversaj retumiloj, donis impulson al la disvolviĝo de testa aŭtomatigo. Krome, en la kazo de Selenium Grid, ni devas anticipe determini ĉiujn postulatajn retumiloj kaj iliajn versiojn, kio ne estas problemo kiam oni laboras kun nur unu retumilo. Sed se temas pri pluraj subtenataj retumiloj, Selenoid estas la unua solvo danke al ĝia 'retumilo laŭ postulo'. Ĉio, kio postulas de ni, estas anticipe elŝuti la necesajn bildojn per retumiloj kaj ĝisdatigi la agordan dosieron, kun kiu Selenoid interagas. Post kiam Selenoid ricevas peton de la testoj, ĝi aŭtomate lanĉos la deziratan ujon per la dezirata retumilo. Kiam la testo finiĝos, Selenoid retiriĝos la ujon, tiel liberigante rimedojn por estontaj petoj. Ĉi tiu aliro tute forigas la konatan problemon de "noda degenero", kiun ni ofte renkontas en Selenium-reto.
Sed, ve, Selenoid ankoraŭ ne estas arĝenta kuglo. Ni ricevis la funkcion 'retumilo laŭ postulo', sed la funkcio 'rimedoj laŭ postulo' ankoraŭ ne disponeblas. Por uzi Selenoid, ni devas disfaldi ĝin sur fizika aparataro aŭ sur VM, kio signifas, ke ni devas antaŭe scii kiom da rimedoj devas esti asignitaj. Mi supozas, ke tio ne estas problemo por malgrandaj projektoj, kiuj funkcias 10, 20 aŭ eĉ 30 retumiloj paralele. Sed kio se ni bezonas 100, 500, 1000 kaj pli? Ne havas sencon konservi kaj pagi tiom da rimedoj la tutan tempon. En sekcioj 5 kaj 6 de ĉi tiu artikolo, ni diskutos solvojn, kiuj ebligas al vi grimpi, tiel signife reduktante la kostojn de la kompanio.
Selenoid por Android
Post la sukceso de Selenoid kiel interreta aŭtomatiga ilo, homoj volis ion similan por Android. Kaj okazis - Selenoid estis liberigita kun Android-subteno. De altnivela uzanta vidpunkto, la principo de funkciado similas al retaŭtomatigo. La nura diferenco estas, ke anstataŭ retumila ujoj, Selenoid rulas Android-emuladujojn. Laŭ mi, ĉi tio estas nuntempe la plej potenca senpaga ilo por ruli Android-testojn paralele.
Mi vere ne ŝatus paroli pri la negativaj aspektoj de ĉi tiu ilo, ĉar mi tre ŝatas ĝin. Sed tamen, ekzistas la samaj malavantaĝoj kiuj validas por retaŭtomatigo kaj estas asociitaj kun skalo. Aldone al ĉi tio, ni devas paroli pri unu plia limigo, kiu povas surprizi se ni agordas la ilon por la unua fojo. Por ruli Android-bildojn, ni bezonas fizikan maŝinon aŭ VM kun nestita virtualiga subteno. En la gvidilo, mi montras kiel ebligi ĉi tion sur Linuksa VM. Tamen, se vi estas macOS-uzanto kaj volas deploji Selenoid loke, tiam ĉi tio ne eblos ruli Android-testojn. Sed vi ĉiam povas ruli Linuksan VM loke kun 'nestita virtualigo' agordita kaj deploji Selenoid interne.
Ilustraĵo de la nuna stato de infrastrukturo
En la kunteksto de ĉi tiu artikolo, ni aldonos 2 ilojn por ilustri la infrastrukturon. Ĉi tiuj estas Selenium krado por interretaj testoj kaj Selenoid por Android-testoj. En la GitHub lernilo, mi ankaŭ montros al vi kiel uzi Selenoid por fari retajn testojn.
Ligiloj por esplori
Similaj iloj
- Estas aliaj kontenerigaj iloj, sed Docker estas la plej populara. Se vi volas provi ion alian, memoru, ke la iloj, kiujn ni kovris por ruli Selenium-testojn paralele, ne funkcios el la skatolo.
- Kiel jam dirite, estas multaj modifoj de Selena krado, ekzemple,.
4.CI/KD
Mallonga priskribo de la teknologio
La praktiko de kontinua integriĝo estas sufiĉe populara en evoluo kaj estas alparo kun versio-kontrolsistemoj. Malgraŭ tio, mi sentas, ke estas konfuzo en terminologio. En ĉi tiu alineo mi ŝatus priskribi 3 modifojn de ĉi tiu teknologio el mia vidpunkto. En la interreto vi trovos multajn artikolojn kun malsamaj interpretoj, kaj estas absolute normale se via opinio malsamas. La plej grava afero estas, ke vi estas sur la sama paĝo kun viaj kolegoj.
Do, estas 3 terminoj: CI - Kontinua Integriĝo, KD - Kontinua Livero kaj denove KD - Kontinua Deplojo. (Malsupre mi uzos ĉi tiujn terminojn en la angla). Ĉiu modifo aldonas plurajn pliajn paŝojn al via disvolva dukto. Sed la vorto Kontinua (kontinua) estas la plej grava afero. En ĉi tiu kunteksto, ni signifas ion, kio okazas de komenco ĝis fino, sen interrompo aŭ mana interveno. Ni rigardu CI & KD kaj KD en ĉi tiu kunteksto.
- Kontinua Integriĝo ĉi tio estas la komenca paŝo de evoluo. Post sendi novan kodon al la servilo, ni atendas ricevi rapidajn rimarkojn, ke niaj ŝanĝoj estas en ordo. Tipe, CI inkluzivas funkciadon de statikaj kodaj analiziloj kaj unuo/internaj API-testoj. Ĉi tio ebligas al ni akiri informojn pri nia kodo ene de kelkaj sekundoj/minutoj.
- Kontinua Transdono estas pli progresinta paŝo, kie ni faras integrigajn/UI-testojn. Tamen, en ĉi tiu etapo ni ne ricevas rezultojn tiel rapide kiel kun CI. Unue, ĉi tiuj specoj de provoj bezonas pli longe por plenumi. Due, antaŭ lanĉo, ni devas disfaldi niajn ŝanĝojn al la testa/sceniga medio. Krome, se ni parolas pri movebla disvolviĝo, tiam aperas plia paŝo por krei konstruaĵon de nia aplikaĵo.
- Kontinua Disvolviĝo supozas, ke ni aŭtomate liberigas niajn ŝanĝojn al produktado se ĉiuj akceptotestoj estis trapasitaj en la antaŭaj stadioj. Aldone al ĉi tio, post la eldona etapo, vi povas agordi diversajn stadiojn, kiel fari fumtestojn pri produktado kaj kolekti interesajn metrikojn. Kontinua Deplojo nur eblas kun bona kovrado per aŭtomatigitaj testoj. Se necesas iuj manaj intervenoj, inkluzive de provoj, tiam ĉi tio ne plu estas kontinua (kontinua). Tiam ni povas diri, ke nia dukto konformas nur al la praktiko de Kontinua Livero.
Valoro por aŭtomatiga infrastrukturo
En ĉi tiu sekcio, mi devus klarigi, ke kiam ni parolas pri fin-al-finaj UI-testoj, tio signifas, ke ni devas disfaldi niajn ŝanĝojn kaj rilatajn servojn por testi mediojn. Kontinua Integriĝo - la procezo ne aplikeblas por ĉi tiu tasko kaj ni devas zorgi pri efektivigo de almenaŭ Daŭraj Liveraj praktikoj. Kontinua Deplojo ankaŭ havas sencon en la kunteksto de UI-testoj se ni ruligos ilin en produktado.
Kaj antaŭ ol ni rigardas la ilustraĵon de la arkitektura ŝanĝo, mi volas diri kelkajn vortojn pri GitLab CI. Male al aliaj CI/KD-iloj, GitLab disponigas malproksiman deponejon kaj multajn aliajn kromajn funkciojn. Tiel, GitLab estas pli ol CI. Ĝi inkluzivas fontkodadministradon, Agile administradon, CI/KD-duktojn, registradajn ilojn kaj metrikan kolekton el la skatolo. La GitLab-arkitekturo konsistas el Gitlab CI/CD kaj GitLab Runner. Jen mallonga priskribo de la oficiala retejo:
Gitlab CI/CD estas retejo-aplikaĵo kun API, kiu stokas sian staton en datumbazo, administras projektojn/konstruaĵojn kaj disponigas uzantinterfacon. GitLab Runner estas aplikaĵo, kiu prilaboras konstruaĵojn. Ĝi povas esti deplojita aparte kaj funkcias kun GitLab CI/CD per API. Por testoj rulantaj vi bezonas kaj Gitlab-instancon kaj Runner.
Ilustraĵo de la nuna stato de infrastrukturo
Ligiloj por esplori
Similaj iloj
- Kaj multaj aliaj
5. Nubaj platformoj
Mallonga priskribo de la teknologio
En ĉi tiu sekcio ni parolos pri populara tendenco nomata 'publikaj nuboj'. Malgraŭ la grandegaj avantaĝoj, kiujn la virtualigo kaj kontenerigo teknologioj priskribitaj supre provizas, ni ankoraŭ bezonas komputikajn rimedojn. Firmaoj aĉetas multekostajn servilojn aŭ luas datumcentrojn, sed ĉi-kaze necesas fari kalkulojn (foje nerealismajn) pri kiom da rimedoj ni bezonos, ĉu ni uzos ilin 24/7 kaj por kiaj celoj. Ekzemple, produktado postulas servilon funkciantan XNUMX/XNUMX, sed ĉu ni bezonas similajn rimedojn por testado ekster laborhoroj? Ĝi ankaŭ dependas de la tipo de testado farita. Ekzemplo estus ŝarĝaj/strestestoj, kiujn ni planas fari dum nelaboraj horoj por ricevi rezultojn la sekvan tagon. Sed certe ne necesas XNUMX/XNUMX servila havebleco por fin-al-finaj aŭtomatigitaj testoj kaj precipe ne por manaj testaj medioj. Por tiaj situacioj, estus bone akiri tiom da rimedoj laŭbezone, uzi ilin, kaj ĉesi pagi kiam ili ne plu bezonas. Plie, estus bonege ricevi ilin tuj farante kelkajn musklakojn aŭ rulante kelkajn skriptojn. Jen por kio estas uzataj publikaj nuboj. Ni rigardu la difinon:
"La publika nubo estas difinita kiel komputilaj servoj ofertitaj de triaj provizantoj per la publika Interreto, farante ilin haveblaj al ĉiu, kiu volas uzi aŭ aĉeti ilin. Ili povas esti senpagaj aŭ venditaj laŭpeto, permesante al klientoj pagi nur per uzokutimo por la CPU-cikloj, stokado aŭ bendolarĝo, kiun ili konsumas."
Estas opinio, ke publikaj nuboj estas multekostaj. Sed ilia ŝlosila ideo estas redukti kompaniajn kostojn. Kiel menciite antaŭe, publikaj nuboj permesas al vi akiri rimedojn laŭpeto kaj pagi nur por la tempo, kiam vi uzas ilin. Ankaŭ, foje ni forgesas, ke dungitoj ricevas salajrojn, kaj specialistoj ankaŭ estas multekosta rimedo. Oni devas konsideri, ke publikaj nuboj multe plifaciligas infrastrukturan subtenon, kio permesas al inĝenieroj koncentriĝi pri pli gravaj taskoj.
Valoro por aŭtomatiga infrastrukturo
Kiajn specifajn rimedojn ni bezonas por fin-al-finaj UI-testoj? Esence ĉi tiuj estas virtualaj maŝinoj aŭ aretoj (pri Kubernetes ni parolos en la sekva sekcio) por ruli retumiloj kaj emuliloj. Ju pli da retumiloj kaj emuliloj ni volas funkcii samtempe, des pli da CPU kaj memoro necesas kaj des pli da mono ni devas pagi por ĝi. Tiel, publikaj nuboj en la kunteksto de testa aŭtomatigo permesas al ni ruli grandan nombron (100, 200, 1000...) de retumiloj/emuliloj laŭpeto, akiri testrezultojn kiel eble plej rapide kaj ĉesi pagi por tia freneze rimeda intensiva. potenco.
La plej popularaj nubaj provizantoj estas Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). La gvidilo provizas ekzemplojn pri kiel uzi GCP, sed ĝenerale ne gravas, kion vi uzas por aŭtomatigaj taskoj. Ili ĉiuj provizas proksimume la saman funkcion. Tipe, por elekti provizanton, administrado fokusiĝas al la tuta infrastrukturo kaj komercaj postuloj de la kompanio, kio estas preter la amplekso de ĉi tiu artikolo. Por aŭtomatigaj inĝenieroj, estos pli interese kompari la uzon de nubaj provizantoj kun la uzo de nubaj platformoj specife por testaj celoj, kiel Sauce Labs, BrowserStack, BitBar, ktp. Do ankaŭ ni faru ĝin! Laŭ mi, Sauce Labs estas la plej fama nuba testbieno, tial mi uzis ĝin por komparo.
GCP vs Sauce Labs por aŭtomatigaj celoj:
Ni imagu, ke ni devas ruli 8 TTT-testojn kaj 8 Android-testojn samtempe. Por tio ni uzos GCP kaj rulos 2 virtualajn maŝinojn kun Selenoid. Sur la unua ni levos 8 ujojn kun retumiloj. Sur la dua estas 8 ujoj kun emuliloj. Ni rigardu la prezojn:
Por ruli unu ujon kun Chrome, ni bezonas n1-normo-1 aŭto. En la kazo de Android ĝi estos n1-normo-4 por unu emulilo. Fakte, pli fleksebla kaj pli malmultekosta maniero estas agordi specifajn uzantvalorojn por CPU/Memoro, sed nuntempe ĉi tio ne gravas por komparo kun Sauce Labs.
Kaj jen la tarifoj por uzi Sauce Labs:
Mi kredas, ke vi jam rimarkis la diferencon, sed mi ankoraŭ provizos tabelon kun kalkuloj por nia tasko:
Bezonataj rimedoj
Monate
laborhoroj(8am - 8pm)
laborhoroj+ Antaŭvidebla
GCP por Retejo
n1-normo-1 x 8 = n1-normo-8
$194.18
23 tagoj * 12h * 0.38 = $104.88
23 tagoj * 12h * 0.08 = $22.08
Sauce Labs por Retejo
Virtuala Cloud8 paralelaj provoj
$1.559
-
-
GCP por Android
n1-normo-4 x 8: n1-normo-16
$776.72
23 tagoj * 12h * 1.52 = $419.52
23 tagoj * 12h * 0.32 = $88.32
Sauce Labs por Android
Reala Aparato Nubo 8 paralelaj provoj
$1.999
-
-
Kiel vi povas vidi, la diferenco en kosto estas grandega, precipe se vi faras testojn nur dum dekdu-hora laborperiodo. Sed vi povas tranĉi kostojn eĉ pli se vi uzas preventeblajn maŝinojn. Kio estas tio?
Prempebla VM estas okazo, kiun vi povas krei kaj funkcii je multe pli da prezo ol normalaj okazoj. Tamen, Compute Engine povus ĉesigi (antaŭigi) ĉi tiujn kazojn se ĝi postulas aliron al tiuj rimedoj por aliaj taskoj. Preempeblaj okazoj estas troa kapablo de Compute Engine, do ilia havebleco varias laŭ uzado.
Se viaj programoj estas toleremaj al misfunkciadoj kaj povas elteni eblajn okazojn, tiam preventeblaj okazoj povas redukti viajn kostojn de Compute Engine signife. Ekzemple, bataj pretigaj laborpostenoj povas funkcii per preventeblaj okazoj. Se kelkaj el tiuj okazoj finiĝas dum prilaborado, la laboro malrapidiĝas sed ne tute ĉesas. Preempeblaj okazoj kompletigas viajn grupajn prilaborajn taskojn sen meti plian laborŝarĝon sur viaj ekzistantaj okazoj kaj sen devigi vin pagi plenan prezon por pliaj normalaj okazoj.
Kaj ankoraŭ ne finiĝis! Fakte, mi certas, ke neniu faras provojn dum 12 horoj sen paŭzo. Kaj se jes, tiam vi povas aŭtomate starti kaj haltigi virtualajn maŝinojn kiam ili ne bezonas. La reala uzadotempo povas esti reduktita al 6 horoj tage. Tiam la pago en la kunteksto de nia tasko malpliiĝos al $11 monate por 8 retumiloj. Ĉu ĉi tio ne estas mirinda? Sed kun preventeblaj maŝinoj ni devas esti singardaj kaj preparitaj por interrompoj kaj malstabileco, kvankam ĉi tiuj situacioj povas esti provizitaj kaj traktitaj en programaro. Ĝi valoras!
Sed tute ne mi diras 'neniam uzu nubajn testbienojn'. Ili havas kelkajn avantaĝojn. Antaŭ ĉio, ĉi tio ne estas nur virtuala maŝino, sed plentaŭga testa aŭtomatiga solvo kun aro de funkcioj ekstere de la skatolo: fora aliro, protokoloj, ekrankopioj, videoregistrado, diversaj retumiloj kaj fizikaj porteblaj aparatoj. En multaj situacioj, ĉi tio povas esti esenca ŝika alternativo. Testaj platformoj estas precipe utilaj por IOS-aŭtomatigo, kiam publikaj nuboj povas nur oferti sistemojn Linukso/Vindozo. Sed pri iOS ni parolos en la sekvaj artikoloj. Mi rekomendas ĉiam rigardi la situacion kaj komenci de la taskoj: en iuj kazoj estas pli malmultekosta kaj pli efika uzi publikajn nubojn, kaj en aliaj la testplatformoj certe valoras la elspezitan monon.
Ilustraĵo de la nuna stato de infrastrukturo
Ligiloj por esplori
Similaj iloj:
6. Orkestrado
Mallonga priskribo de la teknologio
Mi havas bonan novaĵon - ni estas preskaŭ ĉe la fino de la artikolo! Nuntempe, nia aŭtomatiga infrastrukturo konsistas el retaj kaj Android-testoj, kiujn ni kuras paralele per GitLab CI, uzante ilojn ebligitajn de Docker: Selenium grid kaj Selenoid. Plie, ni uzas virtualajn maŝinojn kreitajn per GCP por gastigi ujojn kun retumiloj kaj emuliloj. Por redukti kostojn, ni ekfunkciigas ĉi tiujn virtualajn maŝinojn nur laŭpeto kaj haltigas ilin kiam testado ne estas farata. Ĉu estas io alia kiu povas plibonigi nian infrastrukturon? La respondo estas jes! Renkontu Kubernetes (K8s)!
Unue, ni rigardu kiel la vortoj orkestrado, areto kaj Kubernetes rilatas unu al la alia. Je alta nivelo, instrumentado estas la sistemo kiu deplojas kaj administras aplikojn. Por testa aŭtomatigo, tiaj konteneritaj aplikoj estas Selenium-krado kaj Selenoid. Docker kaj K8s kompletigas unu la alian. La unua estas uzata por aplikaĵa deplojo, la dua por instrumentado. Siavice, K8s estas areto. La tasko de la areto estas uzi VM-ojn kiel Nodojn, kio permesas vin instali diversajn funkciojn, programojn kaj servojn ene de unu servilo (areto). Se iu el la Nodoj malsukcesas, aliaj Nodoj reprenos, kio certigas seninterrompan funkciadon de nia aplikaĵo. Krom ĉi tio, K8s havas gravajn funkciojn rilatajn al skalo, danke al kiu ni aŭtomate akiras la optimuman kvanton da rimedoj laŭ la ŝarĝo kaj fiksas limojn.
Verdire, mane deploji Kubernetes de nulo tute ne estas bagatela tasko. Mi lasos ligilon al la fama gvida gvidilo "Kubernetes The Hard Way" kaj se vi interesiĝas, vi povas praktiki ĝin. Sed, feliĉe, ekzistas alternativaj metodoj kaj iloj. La plej facila maniero estas uzi Google Kubernetes Engine (GKE) en GCP, kio permesos al vi akiri pretan areton per kelkaj klakoj. Mi rekomendas uzi ĉi tiun aliron por komenci lerni, ĉar ĝi permesos al vi koncentriĝi pri lerni kiel uzi la K8s por viaj taskoj anstataŭ lerni kiel la internaj komponantoj devus esti integritaj unu kun la alia.
Valoro por aŭtomatiga infrastrukturo
Ni rigardu kelkajn signifajn funkciojn, kiujn la K8s provizas:
- aplikaĵa deplojo: uzante plurnodan areton anstataŭ VMs;
- dinamika skalo: reduktas la koston de rimedoj, kiuj estas uzataj nur laŭpeto;
- mem-resanigo: aŭtomata reakiro de guŝoj (pro kio ankaŭ ujoj estas restarigitaj);
- lanĉo de ĝisdatigoj kaj malfunkciigo de ŝanĝoj sen malfunkcio: ĝisdatigo de iloj, retumiloj kaj emuliloj ne interrompas la laboron de nunaj uzantoj
Sed la K8s ankoraŭ ne estas arĝenta kuglo. Por kompreni ĉiujn avantaĝojn kaj limigojn en la kunteksto de la iloj, kiujn ni konsideras (Selena krado, Selenoido), ni mallonge diskutos la strukturon de K8s. Areto enhavas du specojn de Nodoj: Majstroj kaj Laboristaj Nodoj. Majstroj Nodoj respondecas pri administrado, deplojo kaj planado de decidoj. Laboristaj nodoj estas kie aplikaĵoj estas rulitaj. Nodoj ankaŭ enhavas konteneran rultempan medion. En nia kazo, ĉi tio estas Docker, kiu respondecas pri uj-rilataj operacioj. Sed ekzistas ankaŭ alternativaj solvoj, ekzemple. Gravas kompreni, ke skalo aŭ mem-resanigo ne validas rekte por ujoj. Ĉi tio efektiviĝas per aldono/malpliigo de la nombro da podoj, kiuj siavice enhavas ujojn (kutime po unu ujo, sed laŭ la tasko povas esti pliaj). La altnivela hierarkio konsistas el labornodoj, ene de kiuj estas balgoj, ene de kiuj ujoj estas levitaj.
La skalo-trajto estas ŝlosila kaj povas esti aplikita al ambaŭ nodoj ene de areto-nodo-pool kaj balgoj ene de nodo. Estas 2 specoj de skalo, kiuj validas por kaj nodoj kaj balgoj. La unua tipo estas horizontala - skalo okazas per pliigo de la nombro da nodoj/pods. Ĉi tiu tipo estas pli preferinda. La dua tipo estas, sekve, vertikala. Skalado estas efektivigita pliigante la grandecon de nodoj/pods, kaj ne ilian nombron.
Nun ni rigardu niajn ilojn en la kunteksto de la supraj terminoj.
Selena krado
Kiel menciite antaŭe, Selena krado estas tre populara ilo, kaj ne estas surprize, ke ĝi estis enhavigita. Sekve, ne surprizas, ke Selena krado povas esti deplojita en K8s. Ekzemplo de kiel fari tion troveblas en la oficiala K8s-deponejo. Kiel kutime, mi almetas ligilojn ĉe la fino de la sekcio. Krome, la gvidilo montras kiel fari tion en Terraform. Estas ankaŭ instrukcioj pri kiel skali la nombron da podoj kiuj enhavas retumilon ujojn. Sed la aŭtomata skala funkcio en la kunteksto de K8s ankoraŭ ne estas tute evidenta tasko. Kiam mi komencis studi, mi ne trovis praktikajn gvidojn aŭ rekomendojn. Post pluraj studoj kaj eksperimentoj kun la subteno de la teamo DevOps, ni elektis la aliron levi ujojn kun la necesaj retumiloj ene de unu pod, kiu situas ene de unu laborista nodo. Ĉi tiu metodo permesas al ni apliki la strategion de horizontala skalo de nodoj pliigante ilian nombron. Mi esperas, ke tio ŝanĝiĝos en la estonteco kaj ni vidos pli kaj pli da priskriboj de pli bonaj aliroj kaj pretaj solvoj, precipe post la liberigo de Selenium krado 4 kun ŝanĝita interna arkitekturo.
Selenoido:
Selenoid-deplojo en K8s estas nuntempe la plej granda seniluziiĝo. Ili ne estas kongruaj. En teorio, ni povas levi Selenoid-ujon ene de pod, sed kiam Selenoid komencas lanĉi ujojn per retumiloj, ili ankoraŭ estos ene de la sama pod. Ĉi tio faras grimpi malebla kaj, kiel rezulto, la laboro de Selenoid ene de areto ne diferencas de laboro en virtuala maŝino. Fino de rakonto.
luno:
Konante ĉi tiun botelon laborante kun Selenoid, la programistoj publikigis pli potencan ilon nomatan Luno. Ĉi tiu ilo estis origine desegnita por labori kun Kubernetes kaj, kiel rezulto, la aŭtoskala funkcio povas kaj devas esti uzata. Cetere, mi dirus, ke nuntempe ĝi estas la sola ilo en la Selenium-mondo, kiu havas indiĝenan K8s-grupsubtenon el la skatolo (ne plu disponebla, vidu sekvan ilon ). La ĉefaj trajtoj de Moon, kiuj provizas ĉi tiun subtenon, estas:
Tute sennacia. Selenoid stokas en memoro informojn pri aktualaj retumiloj. Se ial ĝia procezo kraŝas - tiam ĉiuj kurantaj sesioj estas perditaj. Luno male havas neniun internan staton kaj povas esti reproduktita tra datencentroj. Sesioj de retumilo restas vivaj eĉ se unu aŭ pluraj kopioj malfunkcias.
Do, Luno estas bonega solvo, sed estas unu problemo: ĝi ne estas senpaga. La prezo dependas de la nombro da sesioj. Vi povas ruli nur 0-4 sesiojn senpage, kio ne estas precipe utila. Sed, ekde la kvina sesio, vi devos pagi $5 por ĉiu. La situacio povas diferenci de kompanio al kompanio, sed en nia kazo, uzi Lunon estas sencela. Kiel mi priskribis supre, ni povas ruli VMs kun Selenium Grid laŭ postulo aŭ pliigi la nombron da Nodoj en la areto. Por proksimume unu dukto, ni lanĉas 500 retumiloj kaj ĉesas ĉiujn rimedojn post kiam la testoj estas finitaj. Se ni uzus Lunon, ni devus pagi pliajn 500 x 5 = $2500 monate, negrave kiom ofte ni faras testojn. Denove, mi ne diras, ke vi ne uzu Lunon. Por viaj taskoj, ĉi tio povas esti nemalhavebla solvo, ekzemple, se vi havas multajn projektojn/teamojn en via organizo kaj vi bezonas grandegan komunan areton por ĉiuj. Kiel ĉiam, mi lasas ligilon ĉe la fino kaj rekomendas fari ĉiujn necesajn kalkulojn en la kunteksto de via tasko.
Callisto: (Atentu! Ĉi tio ne estas en la originala artikolo kaj estas enhavita nur en la rusa traduko)
Kiel mi diris, Selenium estas tre populara ilo, kaj la IT-kampo disvolviĝas tre rapide. Dum mi laboris pri la traduko, aperis en la reto nova promesplena ilo nomata Kalisto (saluton Cipreso kaj aliaj Seleniaj murdistoj). Ĝi funkcias denaske kun K8s kaj permesas al vi ruli Selenoidajn ujojn en podoj, distribuitaj tra Nodoj. Ĉio funkcias tuj el la skatolo, inkluzive de aŭtoskalo. Mirinda, sed necesas provita. Mi jam sukcesis disfaldi ĉi tiun ilon kaj fari plurajn eksperimentojn. Sed estas tro frue por tiri konkludojn, ricevinte rezultojn sur longa distanco, eble mi faros recenzon en estontaj artikoloj. Nuntempe mi lasas nur ligilojn por sendependa esploro.
Ilustraĵo de la nuna stato de infrastrukturo
Ligiloj por esplori
Similaj iloj
7. Infrastrukturo kiel Kodo (IaC)
Mallonga priskribo de la teknologio
Kaj nun ni venas al la lasta sekcio. Tipe, ĉi tiu teknologio kaj rilataj taskoj ne estas la respondeco de aŭtomatigaj inĝenieroj. Kaj estas kialoj por ĉi tio. Unue, en multaj organizoj, infrastrukturaj aferoj estas sub la kontrolo de la DevOps-sekcio kaj la evoluigaj teamoj ne vere zorgas pri tio, kio funkcias la dukto kaj kiel ĉio ligita al ĝi devas esti subtenata. Due, ni estu honestaj, la praktiko de Infrastrukturo kiel Kodo (IaC) ankoraŭ ne estas adoptita en multaj kompanioj. Sed ĝi certe fariĝis populara tendenco kaj gravas provi esti implikita en la procezoj, aliroj kaj iloj asociitaj kun ĝi. Aŭ almenaŭ resti ĝisdatigita.
Ni komencu kun la instigo por uzi ĉi tiun aliron. Ni jam diskutis, ke por ruli testojn en GitlabCI, ni bezonos minimume la rimedojn por ruli Gitlab Runner. Kaj por ruli ujojn kun retumiloj/emuliloj, ni devas rezervi VM aŭ areton. Krom testado de rimedoj, ni bezonas signifan kvanton da kapablo subteni disvolviĝon, surscenigon, produktadmediojn, kiuj ankaŭ inkluzivas datumbazojn, aŭtomatajn horarojn, retajn agordojn, ŝarĝbalancilojn, uzantrajtojn ktp. La ŝlosila afero estas la klopodo necesa por subteni ĉion. Estas pluraj manieroj, kiel ni povas fari ŝanĝojn kaj eligi ĝisdatigojn. Ekzemple, en la kunteksto de GCP, ni povas uzi la UI-konzolon en la retumilo kaj plenumi ĉiujn agojn alklakante butonojn. Alternativo estus uzi API-vokojn por interagi kun nubaj estaĵoj, aŭ uzi la gcloud-komandlinian ilon por fari la deziratajn manipuladojn. Sed kun vere granda nombro da malsamaj entoj kaj infrastrukturaj elementoj, fariĝas malfacile aŭ eĉ neeble plenumi ĉiujn operaciojn permane. Krome, ĉiuj ĉi tiuj manaj agoj estas nekontroleblaj. Ni ne povas sendi ilin por revizio antaŭ ekzekuto, uzi version-kontrolan sistemon kaj rapide refari la ŝanĝojn, kiuj kaŭzis la okazaĵon. Por solvi tiajn problemojn, inĝenieroj kreis kaj kreas aŭtomatajn bash/shell-skriptojn, kiuj ne estas multe pli bonaj ol antaŭaj metodoj, ĉar ili ne estas tiel facile rapide legi, kompreni, konservi kaj modifi laŭ procedura stilo.
En ĉi tiu artikolo kaj gvidilo, mi uzas 2 ilojn rilatajn al IaC-praktiko. Ĉi tiuj estas Terraform kaj Ansible. Iuj homoj kredas, ke ne havas sencon uzi ilin samtempe, ĉar ilia funkcieco estas simila kaj ili estas interŝanĝeblaj. Sed la fakto estas, ke komence ili ricevas tute malsamajn taskojn. Kaj la fakto, ke ĉi tiuj iloj devas kompletigi unu la alian, estis konfirmita ĉe komuna prezento de programistoj reprezentantaj HashiCorp kaj RedHat. La koncipa diferenco estas, ke Terraform estas provianta ilo por administri la servilojn mem. Dum Ansible estas agorda administra ilo, kies tasko estas instali, agordi kaj administri programaron sur ĉi tiuj serviloj.
Alia ŝlosila karakterizaĵo de ĉi tiuj iloj estas la kodiga stilo. Male al bash kaj Ansible, Terraform uzas deklaran stilon bazitan sur priskribo de la dezirata fina stato por esti atingita kiel rezulto de ekzekuto. Ekzemple, se ni kreos 10 VM-ojn kaj aplikos la ŝanĝojn per Terraform, tiam ni ricevos 10-VM-ojn. Se ni rulas la skripton denove, nenio okazos ĉar ni jam havas 10 VM-ojn, kaj Terraform scias pri tio ĉar ĝi konservas la nunan staton de la infrastrukturo en ŝtatdosiero. Sed Ansible uzas proceduran aliron kaj, se vi petas ĝin krei 10 VM-ojn, tiam ĉe la unua lanĉo ni ricevos 10 VM-ojn, similajn al Terraform. Sed post rekomenco ni jam havos 20 VM-ojn. Ĉi tiu estas la grava diferenco. En procedura stilo, ni ne konservas la nunan staton kaj simple priskribas sekvencon de paŝoj kiuj devas esti faritaj. Kompreneble, ni povas trakti diversajn situaciojn, aldoni plurajn kontrolojn pri la ekzisto de rimedoj kaj la nuna stato, sed ne utilas malŝpari nian tempon kaj peni kontroli ĉi tiun logikon. Krome, ĉi tio pliigas la riskon fari erarojn.
Resumante ĉion supre, ni povas konkludi, ke Terraform kaj deklara notado estas pli taŭga ilo por provizi servilojn. Sed estas pli bone delegi la laboron de agorda administrado al Ansible. Kun tio ekster la vojo, ni rigardu uzkazojn en la kunteksto de aŭtomatigo.
Valoro por aŭtomatiga infrastrukturo
La sola grava afero por kompreni ĉi tie estas, ke la testa aŭtomatiga infrastrukturo devas esti konsiderata kiel parto de la tuta kompanio-infrastrukturo. Ĉi tio signifas, ke ĉiuj IaC-praktikoj devas esti aplikataj tutmonde al la rimedoj de la tuta organizo. Kiu respondecas pri tio dependas de viaj procezoj. La teamo DevOps estas pli sperta pri ĉi tiuj aferoj, ili vidas la tutan bildon pri tio, kio okazas. Tamen, QA-inĝenieroj estas pli implikitaj en la procezo de konstruado de aŭtomatigo kaj la strukturo de la dukto, kio permesas al ili pli bone vidi ĉiujn postulatajn ŝanĝojn kaj ŝancojn por plibonigo. La plej bona elekto estas kunlabori, interŝanĝi scion kaj ideojn por atingi la atendatan rezulton.
Jen kelkaj ekzemploj pri uzado de Terraform kaj Ansible en la kunteksto de testa aŭtomatigo kaj la iloj, kiujn ni antaŭe diskutis:
1. Priskribu la necesajn karakterizaĵojn kaj parametrojn de VMs kaj aretoj uzante Terraform.
2. Uzante Ansible, instalu la ilojn necesajn por testado: docker, Selenoid, Selenium Grid kaj elŝutu la bezonatajn versiojn de retumiloj/emuliloj.
3. Uzante Terraform, priskribu la karakterizaĵojn de la VM en kiu GitLab Runner estos lanĉita.
4. Instalu GitLab Runner kaj la necesajn akompanajn ilojn uzante Ansible, agordu agordojn kaj agordojn.
Ilustraĵo de la nuna stato de infrastrukturo
Ligiloj por esplori:
Similaj iloj
Ni resumu ĝin!
Paŝo
teknologio
Iloj
Valoro por aŭtomatiga infrastrukturo
1
Loka kurado
Node.js, Seleno, Appium
- La plej popularaj iloj por retejo kaj poŝtelefono
- Subtenas multajn lingvojn kaj platformojn (inkluzive de Node.js)
2
Versiaj kontrolaj sistemoj
Git
- Similaj avantaĝoj kun evolukodo
3
Kontenigo
Docker, Selena krado, Selenoido (Reto, Android)
- Kurante testojn paralele
- Izolitaj medioj
- Simplaj, flekseblaj versioj ĝisdatigoj
- Dinamike ĉesigi neuzatajn rimedojn
- Facila agordi
4
CI/KD
Gitlab CI
- Testas parton de la dukto
- Rapida Reago
- Videbleco por la tuta kompanio/teamo
5
Nubaj platformoj
Google Nubo Platformo
- Rimedoj laŭpeto (ni pagas nur kiam bezonate)
- Facila administri kaj ĝisdatigi
- Videbleco kaj kontrolo de ĉiuj rimedoj
6
Orkestrado
Kubernetoj
En la kunteksto de ujoj kun retumiloj/emuliloj ene de podoj:
- Skalado/aŭtomata skalado
- Mem-resanigo
- Ĝisdatigoj kaj malfunkciigo sen interrompo
7
Infrastrukturo kiel kodo (IaC)
Terraform, Ansible
- Similaj avantaĝoj kun evolua infrastrukturo
- Ĉiuj avantaĝoj de koda versio
- Facile fari ŝanĝojn kaj konservi
- Plene aŭtomatigita
Diagramoj pri mensmapoj: evoluo de infrastrukturo
paŝo 1: Loka
paŝo 2: VCS
paŝo3: Kontenigo
paŝo4: CI/KD
paŝo 5: Nubaj Platformoj
paŝo 6: Orkestrado
paŝo7: IaC
Kio sekvas?
Do, jen la fino de la artikolo. Sed konklude, mi ŝatus starigi kelkajn interkonsentojn kun vi.
De via flanko
Kiel mi diris komence, mi ŝatus, ke la artikolo estu praktike kaj helpu vin apliki la sciojn akiritajn en reala laboro. Mi aldonas denove.
Sed eĉ post tio, ne ĉesu, praktiku, studu koncernajn ligilojn kaj librojn, eksciu kiel ĝi funkcias en via kompanio, trovu lokojn plibonigeblajn kaj partoprenu en ĝi. Bonŝancon!
De mia flanko
De la titolo oni povas vidi, ke tio estis nur la unua parto. Malgraŭ tio, ke ĝi montriĝis sufiĉe granda, gravaj temoj ankoraŭ ne estas traktataj ĉi tie. En la dua parto, mi planas rigardi aŭtomatigan infrastrukturon en la kunteksto de iOS. Pro la limigoj de Apple pri rulado de iOS-simuliloj nur en macOS-sistemoj, nia gamo da solvoj estas malvastigita. Ekzemple, ni ne povas uzi Docker por ruli la simulilon aŭ publikajn nubojn por ruli virtualajn maŝinojn. Sed ĉi tio ne signifas, ke ne ekzistas aliaj alternativoj. Mi provos teni vin ĝisdatigita kun altnivelaj solvoj kaj modernaj iloj!
Ankaŭ mi ne menciis sufiĉe grandajn temojn rilate al monitorado. En Parto 3, mi rigardos la plej popularajn infrastrukturajn monitorajn ilojn kaj kiajn datumojn kaj metrikojn konsideri.
Kaj finfine. Estonte, mi planas publikigi videokurson pri konstruado de testa infrastrukturo kaj popularaj iloj. Nuntempe, ekzistas sufiĉe da kursoj kaj prelegoj pri DevOps en la Interreto, sed ĉiuj materialoj estas prezentitaj en la kunteksto de evoluo, ne testa aŭtomatigo. Pri ĉi tiu afero, mi vere bezonas komentojn pri tio, ĉu tia kurso estos interesa kaj valora por la komunumo de testistoj kaj aŭtomatigaj inĝenieroj. Antaŭdankon!
fonto: www.habr.com