Dio 1: Web/Android
primjedba: ovaj članak je prijevod originalnog članka na ruski Međutim, sve ilustracije, linkovi, citati i termini su sačuvani na originalnom jeziku kako bi se izbjeglo izobličenje značenja kada se prevode na ruski. Želim vam srećno učenje!
Trenutno je specijalnost DevOps jedna od najtraženijih u IT industriji. Ako otvorite popularne stranice za traženje posla i filtrirate prema plaći, vidjet ćete da su poslovi vezani za DevOps na vrhu liste. Međutim, važno je shvatiti da se to uglavnom odnosi na 'Senior' poziciju, što podrazumijeva da kandidat ima visok nivo vještina, znanja o tehnologiji i alatima. Ovo takođe dolazi sa visokim stepenom odgovornosti povezane sa nesmetanim radom proizvodnje. Međutim, počeli smo da zaboravljamo šta je DevOps. U početku, to nije bila konkretna osoba ili odjel. Ako potražimo definicije ovog pojma, naći ćemo mnogo lijepih i ispravnih imenica, kao što su metodologija, praksa, kulturna filozofija, grupa koncepata i tako dalje.
Moja specijalizacija je inženjer za automatizaciju testova (QA automation engineer), ali smatram da to ne treba povezivati samo sa pisanjem auto-testova ili razvojem arhitekture testnog okvira. U 2020. poznavanje infrastrukture za automatizaciju je također neophodno. Ovo vam omogućava da sami organizujete proces automatizacije, od pokretanja testova do pružanja rezultata svim zainteresovanim stranama u skladu sa vašim ciljevima. Kao rezultat toga, DevOps vještine su neophodne za obavljanje posla. I sve je to dobro, ali, nažalost, postoji problem (spojler: ovaj članak pokušava pojednostaviti ovaj problem). Poenta je da je DevOps težak. I to je očigledno, jer kompanije neće mnogo platiti za nešto što je lako uraditi... U DevOps svetu postoji veliki broj alata, termina i praksi koje treba savladati. To je posebno teško na početku karijere i ovisi o akumuliranom tehničkom iskustvu.
izvor:
Ovdje ćemo vjerovatno završiti s uvodnim dijelom i fokusirati se na svrhu ovog članka.
O čemu je ovaj članak?
U ovom članku ću podijeliti svoje iskustvo u izgradnji infrastrukture za automatizaciju testova. Na internetu postoji mnogo izvora informacija o raznim alatima i načinu njihovog korištenja, ali bih ih želio pogledati isključivo u kontekstu automatizacije. Vjerujem da su mnogi inženjeri automatizacije upoznati sa situacijom kada niko osim vas ne pokreće razvijene testove niti brine o njihovom održavanju. Kao rezultat toga, testovi postaju zastarjeli i morate trošiti vrijeme na njihovo ažuriranje. Opet, na početku karijere, ovo može biti prilično težak zadatak: mudro odlučivanje koji bi alati trebali pomoći u otklanjanju datog problema, kako ih odabrati, konfigurirati i održavati. Neki se testeri obraćaju DevOps-u (ljudi) za pomoć i, budimo iskreni, ovaj pristup funkcionira. U mnogim slučajevima ovo može biti jedina opcija jer nemamo pregled svih zavisnosti. Ali, kao što znamo, DevOpsi su jako zauzeti momci, jer moraju razmišljati o cjelokupnoj infrastrukturi kompanije, implementaciji, monitoringu, mikroservisima i drugim sličnim zadacima u zavisnosti od organizacije/tima. Kao što obično biva, automatizacija nije prioritet. U takvom slučaju moramo pokušati učiniti sve što je moguće sa naše strane od početka do kraja. To će smanjiti ovisnosti, ubrzati radni tok, poboljšati naše vještine i omogućiti nam da vidimo širu sliku onoga što se dešava.
Članak predstavlja najpopularnije i najpopularnije alate i pokazuje kako ih koristiti za izgradnju infrastrukture za automatizaciju korak po korak. Svaka grupa je predstavljena alatima koji su testirani ličnim iskustvom. Ali to ne znači da morate koristiti istu stvar. Alati sami po sebi nisu važni, oni se pojavljuju i zastarevaju. Naš inženjerski zadatak je razumjeti osnovne principe: zašto nam je potrebna ova grupa alata i koje radne probleme možemo riješiti uz njihovu pomoć. Zato na kraju svakog odjeljka ostavljam veze do sličnih alata koji se mogu koristiti u vašoj organizaciji.
Čega nema u ovom članku
Ponavljam još jednom da članak nije o konkretnim alatima, pa neće biti umetanja koda iz dokumentacije i opisa konkretnih naredbi. Ali na kraju svakog odjeljka ostavljam linkove za detaljno proučavanje.
Ovo se radi zbog:
- ovaj materijal je vrlo lako pronaći u raznim izvorima (dokumentacija, knjige, video kursevi);
- ako krenemo dublje, moraćemo da napišemo 10, 20, 30 delova ovog članka (dok su planovi 2-3);
- Samo ne želim gubiti vaše vrijeme jer biste možda željeli koristiti druge alate za postizanje istih ciljeva.
Praksa
Zaista bih volio da ovaj materijal bude koristan svakom čitatelju, a ne samo pročitanom i zaboravljenom. U svakom istraživanju, praksa je veoma važna komponenta. Za ovo sam se pripremio. Tu je i domaći zadatak koji vas čeka kako biste bili sigurni da nećete bezumno kopirati redove naredbi koje izvršavate.
Plan
Korak
tehnologija
Alat
1
Lokalno trčanje (pripremite web/android demo testove i pokrenite ga lokalno)
Node.js, Selen, Appium
2
Sistemi za kontrolu verzija
ići
3
Kontejnerizacija
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud platforme
Google Cloud Platform
6
Orkestracija
Kubernet
7
Infrastruktura kao kod (IaC)
Terraform, Ansible
Struktura svake sekcije
Da bi naracija bila jasna, svaki dio je opisan prema sljedećem pregledu:
- kratak opis tehnologije,
- vrijednost za infrastrukturu automatizacije,
- ilustracija trenutnog stanja infrastrukture,
- linkovi za studiranje,
- slični alati.
1. Pokrenite testove lokalno
Kratak opis tehnologije
Ovo je samo pripremni korak za lokalno pokretanje demo testova i provjeru da li prolaze. U praktičnom dijelu se koristi Node.js, ali programski jezik i platforma također nisu bitni i možete koristiti one koji se koriste u vašoj kompaniji.
Međutim, kao alate za automatizaciju, preporučujem korištenje Selenium WebDriver-a za web platforme i Appium-a za Android platformu, jer ćemo u sljedećim koracima koristiti Docker slike koje su skrojene za rad sa ovim alatima. Štoviše, s obzirom na zahtjeve posla, ovi alati su najtraženiji na tržištu.
Kao što ste možda primijetili, razmatramo samo web i Android testove. Nažalost, iOS je sasvim druga priča (hvala Appleu). Planiram predstaviti rješenja i prakse vezane za IOS u narednim dijelovima.
Vrijednost za infrastrukturu automatizacije
Iz perspektive infrastrukture, lokalno trčanje ne daje nikakvu vrijednost. Provjeravate samo da li se testovi izvode na lokalnoj mašini u lokalnim pretraživačima i simulatorima. Ali u svakom slučaju, ovo je neophodna polazna tačka.
Ilustracija trenutnog stanja infrastrukture
Linkovi za istraživanje
Slični alati
- bilo koji programski jezik koji vam se sviđa u kombinaciji sa testovima Selenium/Appium;
- bilo kakvih testova;
- bilo koji probni trkač.
2. Sistemi kontrole verzija (Git)
Kratak opis tehnologije
Nikome neće biti veliko otkriće ako kažem da je kontrola verzija izuzetno važan dio razvoja, kako u timu, tako i pojedinačno. Na osnovu različitih izvora, sa sigurnošću se može reći da je Git najpopularniji predstavnik. Sistem kontrole verzija pruža mnoge prednosti, kao što je deljenje koda, pohranjivanje verzija, vraćanje na prethodne grane, praćenje istorije projekta i rezervne kopije. Nećemo detaljno raspravljati o svakoj tački, jer sam siguran da ste je dobro upoznati i da je koristite u svom svakodnevnom radu. Ali ako odjednom ne, onda preporučujem da prekinete čitanje ovog članka i popunite ovu prazninu što je prije moguće.
Vrijednost za infrastrukturu automatizacije
I ovdje možete postaviti razumno pitanje: „Zašto nam priča o Gitu? Svi to znaju i koriste ga i za razvojni kod i za kod za automatsko testiranje.” Bićete potpuno u pravu, ali u ovom članku govorimo o infrastrukturi i ovaj odeljak služi kao pregled za odeljak 7: “Infrastruktura kao kod (IaC)”. Za nas to znači da je cjelokupna infrastruktura, uključujući i testiranje, opisana u obliku koda, tako da na nju možemo primijeniti i sisteme za verzioniranje i dobiti slične pogodnosti kao kod razvoja i automatizacije.
IaC ćemo pogledati detaljnije u koraku 7, ali čak i sada možete početi koristiti Git lokalno kreiranjem lokalnog spremišta. Velika slika će se proširiti kada infrastrukturi dodamo udaljeno spremište.
Ilustracija trenutnog stanja infrastrukture
Linkovi za istraživanje
Slični alati
3. Kontejnerizacija (Docker)
Kratak opis tehnologije
Da bismo pokazali kako je kontejnerizacija promijenila pravila igre, vratimo se nekoliko decenija unazad. Tada su ljudi kupovali i koristili serverske mašine za pokretanje aplikacija. Ali u većini slučajeva, potrebni resursi za pokretanje nisu bili poznati unaprijed. Kao rezultat toga, kompanije su trošile novac na kupovinu skupih, moćnih servera, ali dio tih kapaciteta nije u potpunosti iskorišten.
Sljedeća faza evolucije bile su virtualne mašine (VM), koje su riješile problem rasipanja novca na neiskorištene resurse. Ova tehnologija je omogućila pokretanje aplikacija nezavisno jedna od druge unutar istog servera, alocirajući potpuno izolovan prostor. Ali, nažalost, svaka tehnologija ima svoje nedostatke. Za pokretanje VM-a potreban je kompletan operativni sistem, koji troši CPU, RAM, skladište i, u zavisnosti od OS-a, treba uzeti u obzir troškove licence. Ovi faktori utiču na brzinu učitavanja i otežavaju prenosivost.
I sada dolazimo do kontejnerizacije. Još jednom, ova tehnologija rješava prethodni problem, jer kontejneri ne koriste puni OS, što oslobađa veliku količinu resursa i pruža brzo i fleksibilno rješenje za prenosivost.
Naravno, tehnologija kontejnerizacije nije ništa novo i prvi put je predstavljena kasnih 70-ih. U to vrijeme provedeno je mnogo istraživanja, razvoja i pokušaja. Ali upravo je Docker prilagodio ovu tehnologiju i učinio je lako dostupnom masama. Danas, kada govorimo o kontejnerima, u većini slučajeva mislimo na Docker. Kada govorimo o Docker kontejnerima, mislimo na Linux kontejnere. Za pokretanje kontejnera možemo koristiti Windows i macOS sisteme, ali je važno shvatiti da se u ovom slučaju pojavljuje dodatni sloj. Na primjer, Docker na Macu tiho pokreće kontejnere unutar laganog Linux VM-a. Vratit ćemo se na ovu temu kada budemo raspravljali o pokretanju Android emulatora unutar kontejnera, tako da ovdje postoji vrlo važna nijansa o kojoj treba detaljnije razgovarati.
Vrijednost za infrastrukturu automatizacije
Saznali smo da su kontejnerizacija i Docker cool. Pogledajmo ovo u kontekstu automatizacije, jer svaki alat ili tehnologija treba da riješi problem. Istaknimo očigledne probleme automatizacije testova u kontekstu UI testova:
- ogroman broj zavisnosti prilikom instaliranja Selena i posebno Appiuma;
- problemi kompatibilnosti između verzija pretraživača, simulatora i drajvera;
- nedostatak izolovanog prostora za pretraživače/simulatore, što je posebno kritično za paralelno trčanje;
- teško upravljati i održavati ako trebate pokrenuti 10, 50, 100 ili čak 1000 pretraživača u isto vrijeme.
No, budući da je Selenium najpopularniji alat za automatizaciju, a Docker najpopularniji alat za kontejnerizaciju, ne treba čuditi da ih je neko pokušao kombinirati kako bi stvorio moćan alat za rješavanje gore navedenih problema. Razmotrimo takva rješenja detaljnije.
Selenska mreža u dockeru
Ovaj alat je najpopularniji u svetu Selena za pokretanje više pretraživača na više mašina i upravljanje njima iz centralnog čvorišta. Za početak, morate registrirati najmanje 2 dijela: čvorište i čvor(e). Hub je centralni čvor koji prima sve zahtjeve iz testova i distribuira ih odgovarajućim čvorovima. Za svaki čvor možemo konfigurirati određenu konfiguraciju, na primjer, navođenjem željenog pretraživača i njegove verzije. Međutim, i dalje se moramo sami pobrinuti za kompatibilne drajvere pretraživača i instalirati ih na željene čvorove. Iz tog razloga, Selenium grid se ne koristi u svom čistom obliku, osim kada trebamo raditi sa pretraživačima koji se ne mogu instalirati na Linux OS. Za sve ostale slučajeve, značajno fleksibilno i ispravno rješenje bi bilo korištenje Docker slika za pokretanje Selenium grid Hub-a i čvorova. Ovaj pristup uvelike pojednostavljuje upravljanje čvorovima, jer možemo odabrati sliku koja nam je potrebna sa kompatibilnim verzijama pretraživača i već instaliranim drajverima.
Unatoč negativnim kritikama o stabilnosti, posebno kada se pokreće veliki broj čvorova paralelno, Selenium grid je i dalje najpopularniji alat za paralelno pokretanje Selenium testova. Važno je napomenuti da se razna poboljšanja i modifikacije ovog alata stalno pojavljuju u open source-u, koji se bore protiv raznih uskih grla.
Selenoid za Web
Ovaj alat je proboj u svijetu Selena jer radi odmah iz kutije i mnogo je olakšao život mnogim inženjerima automatizacije. Prije svega, ovo nije još jedna modifikacija Selenium grida. Umjesto toga, programeri su kreirali potpuno novu verziju Selenium Hub-a u Golangu, koja je, u kombinaciji s laganim Docker slikama za različite pretraživače, dala poticaj razvoju automatizacije testiranja. Štaviše, u slučaju Selenium Grid-a moramo unaprijed odrediti sve potrebne pretraživače i njihove verzije, što nije problem kada se radi samo sa jednim pretraživačem. Ali kada je u pitanju više podržanih pretraživača, Selenoid je rješenje broj jedan zahvaljujući svojoj funkciji 'pregledač na zahtjev'. Sve što se od nas traži je da unapred preuzmemo potrebne slike sa pretraživača i ažuriramo konfiguracioni fajl sa kojim Selenoid komunicira. Nakon što Selenoid primi zahtjev od testova, automatski će pokrenuti željeni kontejner sa željenim pretraživačem. Kada se test završi, Selenoid će povući kontejner, čime će osloboditi resurse za buduće zahtjeve. Ovaj pristup u potpunosti eliminiše dobro poznati problem 'degradacije čvorova' sa kojim se često susrećemo u Selenium mreži.
Ali, nažalost, Selenoid još uvijek nije srebrni metak. Dobili smo funkciju 'pretraživača na zahtjev', ali funkcija 'resursi na zahtjev' još uvijek nije dostupna. Da bismo koristili Selenoid, moramo ga postaviti na fizički hardver ili na VM, što znači da moramo unaprijed znati koliko resursa treba dodijeliti. Pretpostavljam da to nije problem za male projekte koji pokreću 10, 20 ili čak 30 pretraživača paralelno. Ali šta ako nam treba 100, 500, 1000 i više? Nema smisla stalno održavati i plaćati toliko resursa. U odeljcima 5 i 6 ovog članka raspravljat ćemo o rješenjima koja vam omogućavaju skaliranje, čime se značajno smanjuju troškovi kompanije.
Selenoid za Android
Nakon uspjeha Selenoida kao alata za web automatizaciju, ljudi su htjeli nešto slično za Android. I dogodilo se – Selenoid je izašao sa podrškom za Android. Sa stanovišta korisnika visokog nivoa, princip rada je sličan web automatizaciji. Jedina razlika je u tome što umjesto kontejnera pretraživača, Selenoid pokreće kontejnere Android emulatora. Po mom mišljenju, ovo je trenutno najmoćniji besplatni alat za paralelno pokretanje Android testova.
Zaista ne bih želio da pričam o negativnim aspektima ovog alata, jer mi se jako sviđa. Ali ipak, postoje isti nedostaci koji se odnose na web automatizaciju i povezani su sa skaliranjem. Uz ovo, moramo govoriti o još jednom ograničenju koje može biti iznenađenje ako postavljamo alat po prvi put. Da bismo pokrenuli Android slike, potrebna nam je fizička mašina ili VM sa podrškom za ugniježđenu virtualizaciju. U vodiču s uputama demonstriram kako to omogućiti na Linux VM-u. Međutim, ako ste korisnik macOS-a i želite lokalno implementirati Selenoid, tada neće biti moguće pokrenuti Android testove. Ali uvijek možete pokrenuti Linux VM lokalno s konfiguriranom 'ugniježđenom virtualizacijom' i implementirati Selenoid unutra.
Ilustracija trenutnog stanja infrastrukture
U kontekstu ovog članka, dodaćemo 2 alata za ilustraciju infrastrukture. To su Selenium grid za web testove i Selenoid za Android testove. U vodiču za GitHub, takođe ću vam pokazati kako da koristite Selenoid za pokretanje veb testova.
Linkovi za istraživanje
Slični alati
- Postoje i drugi alati za kontejnerizaciju, ali Docker je najpopularniji. Ako želite da isprobate nešto drugo, imajte na umu da alati koje smo pokrili za paralelno izvođenje Selenium testova neće raditi bez upotrebe.
- Kao što je već rečeno, postoje mnoge modifikacije selenske mreže, npr..
4.CI/CD
Kratak opis tehnologije
Praksa kontinuirane integracije je prilično popularna u razvoju i jednaka je sistemima kontrole verzija. Uprkos tome, smatram da postoji zbrka u terminologiji. U ovom paragrafu bih želeo da opišem 3 modifikacije ove tehnologije sa moje tačke gledišta. Na internetu ćete naći mnogo članaka sa različitim tumačenjima i sasvim je normalno ako se vaše mišljenje razlikuje. Najvažnije je da ste na istoj strani sa svojim kolegama.
Dakle, postoje 3 pojma: CI - Kontinuirana integracija, CD - Kontinuirana isporuka i opet CD - Kontinuirana implementacija. (U nastavku ću koristiti ove termine na engleskom). Svaka modifikacija dodaje nekoliko dodatnih koraka vašem razvojnom kanalu. Ali riječ kontinuirano (kontinuirano) je najvažnija stvar. U ovom kontekstu mislimo na nešto što se dešava od početka do kraja, bez prekida ili ručne intervencije. Pogledajmo CI & CD i CD u ovom kontekstu.
- Kontinuirana integracija ovo je početni korak evolucije. Nakon slanja novog koda na server, očekujemo da ćemo brzo dobiti povratnu informaciju da su naše promjene u redu. Tipično, CI uključuje pokretanje alata za statičku analizu koda i jedinične/interne API testove.Ovo nam omogućava da dobijemo informacije o našem kodu u roku od nekoliko sekundi/minuta.
- Kontinuirana dostava je napredniji korak gdje izvodimo integracijske/UI testove. Međutim, u ovoj fazi ne postižemo rezultate tako brzo kao kod CI. Prvo, za ove vrste testova potrebno je duže da se završe. Drugo, prije pokretanja, moramo implementirati naše promjene u okruženje za testiranje/scenu. Štoviše, ako govorimo o mobilnom razvoju, onda se pojavljuje dodatni korak za kreiranje build naše aplikacije.
- Kontinuirano postavljanje pretpostavlja da automatski puštamo naše promjene u proizvodnju ako su svi testovi prihvatljivosti prošli u prethodnim fazama. Osim toga, nakon faze izdavanja, možete konfigurirati različite faze, kao što je pokretanje testova dima u proizvodnji i prikupljanje metrike od interesa. Kontinuirana implementacija je moguća samo uz dobru pokrivenost automatiziranim testovima. Ako su potrebne bilo kakve ručne intervencije, uključujući testiranje, onda to više nije neprekidan (kontinuirano). Tada možemo reći da je naš cjevovod usklađen samo sa praksom kontinuirane isporuke.
Vrijednost za infrastrukturu automatizacije
U ovom odeljku, trebalo bi da pojasnim da kada govorimo o end-to-end UI testovima, to znači da treba da primenimo naše promene i povezane usluge u okruženjima za testiranje. Kontinuirana integracija – proces nije primjenjiv za ovaj zadatak i moramo se pobrinuti da implementiramo barem praksu kontinuirane isporuke. Kontinuirana implementacija također ima smisla u kontekstu UI testova ako ćemo ih pokrenuti u proizvodnji.
I prije nego što pogledamo ilustraciju promjene arhitekture, želim reći nekoliko riječi o GitLab CI. Za razliku od drugih CI/CD alata, GitLab pruža udaljeno spremište i mnoge druge dodatne mogućnosti. Dakle, GitLab je više od CI. Uključuje upravljanje izvornim kodom, Agile upravljanje, CI/CD cjevovode, alate za evidentiranje i zbirku metrika izvan kutije. GitLab arhitektura se sastoji od Gitlab CI/CD i GitLab Runner-a. Evo kratkog opisa sa službene web stranice:
Gitlab CI/CD je web aplikacija s API-jem koji pohranjuje svoje stanje u bazu podataka, upravlja projektima/izgradnjom i pruža korisnički interfejs. GitLab Runner je aplikacija koja obrađuje gradnje. Može se implementirati zasebno i radi sa GitLab CI/CD preko API-ja. Za pokretanje testova potrebni su vam i Gitlab instanca i Runner.
Ilustracija trenutnog stanja infrastrukture
Linkovi za istraživanje
Slični alati
- I mnogi drugi
5. Cloud platforme
Kratak opis tehnologije
U ovom dijelu ćemo govoriti o popularnom trendu koji se zove 'javni oblaci'. Uprkos ogromnim prednostima koje pružaju gore opisane tehnologije virtuelizacije i kontejnerizacije, i dalje su nam potrebni računarski resursi. Kompanije kupuju skupe servere ili iznajmljuju data centre, ali je u tom slučaju potrebno napraviti kalkulacije (ponekad nerealne) koliko će nam resursa biti potrebno, da li ćemo ih koristiti 24/7 i u koje svrhe. Na primjer, proizvodnja zahtijeva server koji radi XNUMX/XNUMX, ali da li su nam potrebni slični resursi za testiranje van radnog vremena? To također ovisi o vrsti testiranja koja se izvodi. Primjer bi bili testovi opterećenja/stres koje planiramo izvoditi u neradno vrijeme kako bismo sutradan dobili rezultate. Ali definitivno dostupnost servera XNUMX/XNUMX nije potrebna za end-to-end automatizovane testove, a posebno ne za okruženja za ručno testiranje. Za takve situacije bilo bi dobro nabaviti onoliko resursa koliko je potrebno na zahtjev, iskoristiti ih i prestati plaćati kada više nisu potrebni. Štaviše, bilo bi sjajno da ih odmah primite nekoliko klikova mišem ili pokretanjem nekoliko skripti. Za to se koriste javni oblaci. Pogledajmo definiciju:
„Javni oblak se definiše kao računarske usluge koje nude provajderi trećih strana preko javnog Interneta, čineći ih dostupnim svima koji žele da ih koriste ili kupe. Mogu biti besplatni ili se prodaju na zahtjev, omogućavajući kupcima da plate samo po korištenju za CPU cikluse, pohranu ili propusni opseg koji troše."
Postoji mišljenje da su javni oblaci skupi. Ali njihova ključna ideja je smanjenje troškova kompanije. Kao što je ranije spomenuto, javni oblaci vam omogućavaju da dobijete resurse na zahtjev i platite samo za vrijeme koje koristite. Takođe, ponekad zaboravimo da zaposleni primaju plate, a stručnjaci su takođe skup resurs. Mora se uzeti u obzir da javni oblaci znatno olakšavaju podršku infrastrukture, što omogućava inženjerima da se fokusiraju na važnije zadatke.
Vrijednost za infrastrukturu automatizacije
Koji specifični resursi su nam potrebni za end-to-end UI testove? U osnovi, to su virtuelne mašine ili klasteri (o Kubernetesu ćemo govoriti u sledećem odeljku) za pokretanje pretraživača i emulatora. Što više pretraživača i emulatora želimo da pokrećemo istovremeno, to je potrebno više CPU-a i memorije i više novca moramo da platimo za to. Dakle, javni oblaci u kontekstu automatizacije testiranja omogućavaju nam da pokrenemo veliki broj (100, 200, 1000...) pretraživača/emulatora na zahtjev, dobijemo rezultate testiranja što je prije moguće i prestanemo plaćati za tako suludo intenzivne resurse moć.
Najpopularniji cloud provajderi su Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Vodič sa uputstvima pruža primjere kako koristiti GCP, ali općenito nije važno šta koristite za zadatke automatizacije. Svi oni pružaju približno istu funkcionalnost. Tipično, da bi odabrao provajdera, menadžment se fokusira na cjelokupnu infrastrukturu i poslovne zahtjeve kompanije, što je izvan okvira ovog članka. Za inženjere automatizacije će biti zanimljivije uporediti korištenje cloud provajdera s korištenjem cloud platformi posebno u svrhe testiranja, kao što su Sauce Labs, BrowserStack, BitBar itd. Pa hajde da uradimo i to! Po mom mišljenju, Sauce Labs je najpoznatija farma za testiranje oblaka, zbog čega sam je koristio za poređenje.
GCP vs Sauce Labs za potrebe automatizacije:
Zamislimo da trebamo pokrenuti 8 web testova i 8 Android testova istovremeno. Za ovo ćemo koristiti GCP i pokrenuti 2 virtuelne mašine sa Selenoidom. Na prvom ćemo podići 8 kontejnera sa pretraživačima. Na drugom se nalazi 8 kontejnera sa emulatorima. Pogledajmo cijene:
Za pokretanje jednog kontejnera s Chromeom, potrebno nam je n1-standard-1 auto. U slučaju Androida to će biti n1-standard-4 za jedan emulator. Zapravo, fleksibilniji i jeftiniji način je postavljanje specifičnih korisničkih vrijednosti za CPU/Memoriju, ali to trenutno nije važno za usporedbu sa Sauce Labs.
A evo i tarifa za korištenje Sauce Labs:
Vjerujem da ste već primijetili razliku, ali ja ću ipak dati tabelu sa proračunima za naš zadatak:
Potrebni resursi
Mesečno
Radni sati(8 ujutro - 8 sati)
Radni sati+ Preemptibilno
GCP za Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dana * 12 sati * 0.38 = 104.88 USD
23 dana * 12 sati * 0.08 = 22.08 USD
Sauce Labs za web
Virtualni Cloud8 paralelni testovi
$1.559
-
-
GCP za Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dana * 12 sati * 1.52 = 419.52 USD
23 dana * 12 sati * 0.32 = 88.32 USD
Sauce Labs za Android
Real Device Cloud 8 paralelni testovi
$1.999
-
-
Kao što vidite, razlika u cijeni je ogromna, posebno ako testirate samo tokom dvanaestosatnog radnog perioda. Ali možete još više smanjiti troškove ako koristite mašine koje se mogu isključiti. Šta je?
Preemptibilni VM je instanca koju možete kreirati i pokrenuti po mnogo većoj cijeni od normalnih instanci. Međutim, Compute Engine može prekinuti (preuzeti) ove instance ako zahtijeva pristup tim resursima za druge zadatke. Preemptibilne instance su višak kapaciteta Compute Engine-a, tako da njihova dostupnost varira ovisno o upotrebi.
Ako su vaše aplikacije tolerantne na greške i mogu izdržati moguća zabrana instance, tada instance koje se mogu isključiti mogu značajno smanjiti vaše troškove Compute Engine-a. Na primjer, poslovi grupne obrade mogu se izvoditi na instancama koje se mogu preuzeti. Ako se neke od tih instanci prekinu tokom obrade, posao se usporava, ali se ne zaustavlja u potpunosti. Preuzete instance dovršavaju vaše zadatke grupne obrade bez stavljanja dodatnog opterećenja na vaše postojeće instance i bez potrebe da plaćate punu cijenu za dodatne normalne instance.
I još nije gotovo! U stvarnosti, siguran sam da niko ne radi testove 12 sati bez pauze. A ako je tako, onda možete automatski pokrenuti i zaustaviti virtuelne mašine kada nisu potrebne. Stvarno vrijeme korištenja može se smanjiti na 6 sati dnevno. Tada će se plaćanje u kontekstu našeg zadatka smanjiti na 11 USD mjesečno za 8 pretraživača. Nije li ovo divno? Ali sa mašinama koje se mogu isključiti moramo biti oprezni i spremni za prekide i nestabilnost, iako se ove situacije mogu predvidjeti i riješiti softverom. Vrijedi toga!
Ali nipošto ne kažem 'nikada ne koristite farme za testiranje u oblaku'. Imaju niz prednosti. Prije svega, ovo nije samo virtualna mašina, već punopravno rješenje za automatizaciju testiranja sa skupom funkcionalnosti iz kutije: daljinski pristup, zapisnici, screenshotovi, video snimanje, razni pretraživači i fizički mobilni uređaji. U mnogim situacijama ovo može biti bitna šik alternativa. Platforme za testiranje su posebno korisne za automatizaciju iOS-a, kada javni oblaci mogu ponuditi samo Linux/Windows sisteme. Ali o iOS-u ćemo govoriti u sljedećim člancima. Preporučujem da uvijek sagledate situaciju i pođete od zadataka: u nekim slučajevima je jeftinije i efikasnije koristiti javne oblake, au drugima su testne platforme definitivno vrijedne potrošenog novca.
Ilustracija trenutnog stanja infrastrukture
Linkovi za istraživanje
Slični alati:
6. Orkestracija
Kratak opis tehnologije
Imam dobre vijesti – skoro smo pri kraju članka! Trenutno se naša infrastruktura za automatizaciju sastoji od web i Android testova, koje paralelno izvodimo kroz GitLab CI, koristeći alate omogućene za Docker: Selenium grid i Selenoid. Štaviše, koristimo virtuelne mašine kreirane putem GCP-a za hostovanje kontejnera sa pretraživačima i emulatorima. Da bismo smanjili troškove, pokrećemo ove virtuelne mašine samo na zahtev i zaustavljamo ih kada se testiranje ne sprovodi. Postoji li još nešto što može poboljšati našu infrastrukturu? Odgovor je da! Upoznajte Kubernetes (K8s)!
Prvo, pogledajmo kako su riječi orkestracija, klaster i Kubernetes međusobno povezane. Na visokom nivou, orkestracija je sistem koji postavlja i upravlja aplikacijama. Za automatizaciju testiranja, takve kontejnerske aplikacije su Selenium grid i Selenoid. Docker i K8 se međusobno nadopunjuju. Prvi se koristi za implementaciju aplikacije, drugi za orkestraciju. Zauzvrat, K8s je klaster. Zadatak klastera je korištenje VM-a kao čvorova, što vam omogućava da instalirate različite funkcionalnosti, programe i usluge unutar jednog servera (klastera). Ako bilo koji od čvorova pokvari, drugi čvorovi će se aktivirati, što osigurava nesmetan rad naše aplikacije. Pored toga, K8s ima važnu funkcionalnost vezanu za skaliranje, zahvaljujući kojoj automatski dobijamo optimalnu količinu resursa na osnovu opterećenja i postavljenih ograničenja.
Istina, ručno postavljanje Kubernetesa od nule nije nimalo trivijalan zadatak. Ostaviću link do poznatog vodiča "Kubernetes The Hard Way" i ako ste zainteresovani, možete ga vežbati. Ali, srećom, postoje alternativne metode i alati. Najlakši način je da koristite Google Kubernetes Engine (GKE) u GCP-u, koji će vam omogućiti da dobijete gotov klaster u nekoliko klikova. Preporučujem korištenje ovog pristupa za početak učenja, jer će vam omogućiti da se usredotočite na učenje kako koristiti K8s za svoje zadatke umjesto da naučite kako interne komponente trebaju biti integrirane jedna s drugom.
Vrijednost za infrastrukturu automatizacije
Pogledajmo nekoliko značajnih karakteristika koje K8s nudi:
- implementacija aplikacije: korištenje klastera s više čvorova umjesto VM-a;
- dinamičko skaliranje: smanjuje troškove resursa koji se koriste samo na zahtjev;
- samoizlječenje: automatski oporavak mahuna (kao rezultat toga se obnavljaju i kontejneri);
- uvođenje ažuriranja i poništavanje promjena bez zastoja: ažuriranje alata, preglednika i emulatora ne prekida rad trenutnih korisnika
Ali K8s još uvijek nije srebrni metak. Da bismo razumjeli sve prednosti i ograničenja u kontekstu alata koje razmatramo (Selenium grid, Selenoid), ukratko ćemo razmotriti strukturu K8s. Klaster sadrži dvije vrste čvorova: glavne čvorove i radne čvorove. Glavni čvorovi su odgovorni za upravljanje, raspoređivanje i odluke o rasporedu. Radnički čvorovi su mjesta na kojima se pokreću aplikacije. Čvorovi također sadrže okruženje za izvršavanje kontejnera. U našem slučaju, ovo je Docker, koji je odgovoran za operacije vezane za kontejnere. Ali postoje i alternativna rješenja, na primjer. Važno je shvatiti da se skaliranje ili samoizlječenje ne primjenjuju direktno na kontejnere. Ovo se implementira dodavanjem/smanjivanjem broja podova, koji pak sadrže kontejnere (obično jedan kontejner po pod, ali ovisno o zadatku može ih biti i više). Hijerarhija visokog nivoa se sastoji od čvorova radnika, unutar kojih se nalaze podovi, unutar kojih se podižu kontejneri.
Funkcija skaliranja je ključna i može se primijeniti na oba čvora unutar skupa čvorova klastera i na podove unutar čvora. Postoje 2 vrste skaliranja koje se primjenjuju i na čvorove i na podove. Prvi tip je horizontalni - skaliranje se događa povećanjem broja čvorova/podova. Ova vrsta je poželjnija. Drugi tip je, shodno tome, vertikalni. Skaliranje se vrši povećanjem veličine čvorova/podova, a ne njihovog broja.
Pogledajmo sada naše alate u kontekstu gornjih pojmova.
Selenska mreža
Kao što je ranije spomenuto, Selenium grid je vrlo popularan alat i nije iznenađenje da je u kontejnerima. Stoga ne čudi da se Selenium grid može postaviti u K8s. Primjer kako to učiniti možete pronaći u službenom K8s spremištu. Kao i obično, prilažem linkove na kraju odjeljka. Osim toga, vodič s uputama pokazuje kako to učiniti u Terraformu. Tu su i upute o tome kako skalirati broj podova koji sadrže kontejnere pretraživača. Ali funkcija automatskog skaliranja u kontekstu K8s još uvijek nije potpuno očigledan zadatak. Kada sam počeo da učim, nisam našao nikakve praktične smernice ili preporuke. Nakon nekoliko studija i eksperimenata uz podršku DevOps tima, odabrali smo pristup podizanja kontejnera sa potrebnim pretraživačima unutar jednog poda, koji se nalazi unutar jednog radnog čvora. Ova metoda nam omogućava da primijenimo strategiju horizontalnog skaliranja čvorova povećanjem njihovog broja. Nadam se da će se to promijeniti u budućnosti i da ćemo vidjeti sve više opisa boljih pristupa i gotovih rješenja, posebno nakon izlaska Selenium grid 4 sa promijenjenom internom arhitekturom.
Selenoid:
Primena selenoida u K8s je trenutno najveće razočarenje. Nisu kompatibilni. U teoriji, možemo podići Selenoid kontejner unutar pod-a, ali kada Selenoid počne da pokreće kontejnere sa pretraživačima, oni će i dalje biti unutar istog pod-a. Ovo onemogućava skaliranje i, kao rezultat, rad Selenoida unutar klastera neće se razlikovati od rada unutar virtuelne mašine. Kraj priče.
Mjesec:
Znajući ovo usko grlo u radu sa Selenoidom, programeri su objavili moćniji alat pod nazivom Moon. Ovaj alat je prvobitno dizajniran za rad sa Kubernetesom i, kao rezultat, funkcija automatskog skaliranja može i treba da se koristi. Štaviše, rekao bih da u ovom trenutku jeste jedini alat u svijetu Selenium, koji ima izvornu podršku za K8s klaster iz kutije (više nije dostupno, pogledajte sljedeći alat ). Ključne karakteristike Moon-a koje pružaju ovu podršku su:
Potpuno bez državljanstva. Selenoid pohranjuje u memoriju informacije o trenutno pokrenutim sesijama pretraživača. Ako se iz nekog razloga njegov proces sruši — onda su sve aktivne sesije izgubljene. Mjesec naprotiv nema unutrašnje stanje i može se replicirati u podatkovnim centrima. Sesije pretraživača ostaju žive čak i ako se jedna ili više replika pokvari.
Dakle, Mjesec je odlično rješenje, ali postoji jedan problem: nije besplatan. Cijena zavisi od broja sesija. Možete pokrenuti samo 0-4 sesije besplatno, što nije posebno korisno. Ali, počevši od pete sesije, moraćete da platite 5 dolara za svaku. Situacija se može razlikovati od kompanije do kompanije, ali u našem slučaju korištenje Moon-a je besmisleno. Kao što sam gore opisao, možemo pokrenuti VM sa Selenium Grid na zahtjev ili povećati broj čvorova u klasteru. Za otprilike jedan cjevovod pokrećemo 500 pretraživača i zaustavljamo sve resurse nakon što se testovi završe. Ako bismo koristili Moon, morali bismo platiti dodatnih 500 x 5 = 2500 dolara mjesečno, bez obzira koliko često radimo testove. Opet, ne kažem da ne koristite Moon. Za vaše zadatke, ovo može biti nezamjenjivo rješenje, na primjer, ako imate mnogo projekata/timova u vašoj organizaciji i potreban vam je ogroman zajednički klaster za sve. Kao i uvijek, ostavljam link na kraju i preporučujem da izvršite sve potrebne proračune u kontekstu vašeg zadatka.
Callisto: (Pažnja! Ovo nije u originalnom članku i nalazi se samo u ruskom prijevodu)
Kao što sam rekao, Selen je veoma popularan alat, a IT oblast se veoma brzo razvija. Dok sam radio na prijevodu, na webu se pojavio novi obećavajući alat Callisto (zdravo Cypress i druge ubice selena). Nativno radi sa K8s i omogućava vam da pokrenete Selenoid kontejnere u podovima, raspoređenim po čvorovima. Sve radi odmah iz kutije, uključujući automatsko skaliranje. Fantastično, ali treba testirati. Već sam uspio implementirati ovaj alat i pokrenuti nekoliko eksperimenata. Ali prerano je donositi zaključke, nakon što dobijem rezultate na velikoj udaljenosti, možda ću napraviti recenziju u budućim člancima. Za sada ostavljam samo linkove za nezavisno istraživanje.
Ilustracija trenutnog stanja infrastrukture
Linkovi za istraživanje
Slični alati
7. Infrastruktura kao kod (IaC)
Kratak opis tehnologije
I sada dolazimo do posljednjeg dijela. Obično ova tehnologija i povezani zadaci nisu odgovornost inženjera automatizacije. I za to postoje razlozi. Prvo, u mnogim organizacijama, infrastrukturna pitanja su pod kontrolom DevOps odeljenja i razvojni timovi baš i ne mare šta čini da cevovod funkcioniše i kako sve što je povezano sa njim treba da bude podržano. Drugo, budimo iskreni, praksa Infrastruktura kao kodeks (IaC) još uvijek nije usvojena u mnogim kompanijama. Ali definitivno je postao popularan trend i važno je pokušati biti uključen u procese, pristupe i alate koji su s njim povezani. Ili barem budite u toku.
Počnimo s motivacijom za korištenje ovog pristupa. Već smo razgovarali o tome da će nam za pokretanje testova u GitlabCI-u biti potrebni barem resursi za pokretanje Gitlab Runnera. A da bismo pokrenuli kontejnere sa pretraživačima/emulatorima, moramo rezervisati VM ili klaster. Pored resursa za testiranje, potrebna nam je značajna količina kapaciteta za podršku razvojnim, scenskim, proizvodnim okruženjima, što takođe uključuje baze podataka, automatske rasporede, mrežne konfiguracije, balansere opterećenja, korisnička prava itd. Ključno pitanje je napor potreban da se sve to podrži. Postoji nekoliko načina na koje možemo izvršiti promjene i uvesti ažuriranja. Na primjer, u kontekstu GCP-a, možemo koristiti UI konzolu u pretraživaču i izvoditi sve radnje klikom na dugmad. Alternativa bi bila korištenje API poziva za interakciju s entitetima u oblaku ili korištenje uslužnog programa gcloud komandne linije za izvođenje željenih manipulacija. Ali sa zaista velikim brojem različitih entiteta i infrastrukturnih elemenata, postaje teško ili čak nemoguće izvršiti sve operacije ručno. Štaviše, sve ove ručne radnje su nekontrolisane. Ne možemo ih poslati na pregled prije izvršenja, koristiti sistem kontrole verzija i brzo vratiti promjene koje su dovele do incidenta. Da bi riješili takve probleme, inženjeri su kreirali i kreirali automatske bash/shell skripte, koje nisu mnogo bolje od prethodnih metoda, jer ih nije tako lako čitati, razumjeti, održavati i modificirati u proceduralnom stilu.
U ovom članku i vodiču s uputama koristim 2 alata vezana za IaC praksu. To su Terraform i Ansible. Neki ljudi smatraju da ih nema smisla koristiti u isto vrijeme, jer im je funkcionalnost slična i zamjenjivi su. Ali činjenica je da im se u početku daju potpuno drugačiji zadaci. A da bi se ovi alati trebali međusobno nadopunjavati potvrdili su na zajedničkoj prezentaciji programeri koji predstavljaju HashiCorp i RedHat. Konceptualna razlika je u tome što je Terraform alat za proviziju za upravljanje samim serverima. Dok je Ansible alat za upravljanje konfiguracijom čiji je zadatak da instalira, konfiguriše i upravlja softverom na ovim serverima.
Još jedna ključna karakteristika ovih alata je stil kodiranja. Za razliku od bash-a i Ansible-a, Terraform koristi deklarativni stil zasnovan na opisu željenog krajnjeg stanja koje treba postići kao rezultat izvršenja. Na primjer, ako ćemo kreirati 10 VM-a i primijeniti promjene kroz Terraform, onda ćemo dobiti 10 VM-ova. Ako ponovo pokrenemo skriptu, ništa se neće dogoditi jer već imamo 10 VM-ova, a Terraform zna za ovo jer pohranjuje trenutno stanje infrastrukture u datoteku stanja. Ali Ansible koristi proceduralni pristup i, ako od njega zatražite da kreira 10 VM-a, tada ćemo pri prvom pokretanju dobiti 10 VM-ova, slično Terraformu. Ali nakon ponovnog pokretanja već ćemo imati 20 VM-ova. Ovo je bitna razlika. U proceduralnom stilu, mi ne pohranjujemo trenutno stanje i jednostavno opisujemo niz koraka koji se moraju izvesti. Naravno, možemo se nositi sa raznim situacijama, dodati nekoliko provjera postojanja resursa i trenutnog stanja, ali nema smisla gubiti vrijeme i ulagati se u kontrolu ove logike. Osim toga, to povećava rizik od greške.
Sumirajući sve gore navedeno, možemo zaključiti da su Terraform i deklarativne notacije prikladniji alat za obezbjeđivanje servera. Ali bolje je delegirati posao upravljanja konfiguracijom na Ansible. Sklonimo to s puta, pogledajmo slučajeve upotrebe u kontekstu automatizacije.
Vrijednost za infrastrukturu automatizacije
Jedina važna stvar koju treba shvatiti je da infrastrukturu za automatizaciju testiranja treba smatrati dijelom cjelokupne infrastrukture kompanije. To znači da se sve prakse IaC-a moraju primijeniti globalno na resurse cijele organizacije. Ko je odgovoran za ovo zavisi od vaših procesa. DevOps tim je iskusniji u ovim pitanjima, oni vide cijelu sliku onoga što se dešava. Međutim, QA inženjeri su više uključeni u proces automatizacije zgrada i strukture cjevovoda, što im omogućava da bolje sagledaju sve potrebne promjene i mogućnosti za poboljšanje. Najbolja opcija je zajednički rad, razmjena znanja i ideja za postizanje očekivanog rezultata.
Evo nekoliko primjera korištenja Terraforma i Ansiblea u kontekstu automatizacije testiranja i alata o kojima smo ranije raspravljali:
1. Opišite potrebne karakteristike i parametre VM-a i klastera koristeći Terraform.
2. Koristeći Ansible, instalirajte alate potrebne za testiranje: docker, Selenoid, Selenium Grid i preuzmite potrebne verzije pretraživača/emulatora.
3. Koristeći Terraform, opišite karakteristike VM-a u kojem će GitLab Runner biti pokrenut.
4. Instalirajte GitLab Runner i potrebne prateće alate koristeći Ansible, postavite postavke i konfiguracije.
Ilustracija trenutnog stanja infrastrukture
Linkovi za istraživanje:
Slični alati
Hajde da sumiramo!
Korak
tehnologija
Alat
Vrijednost za infrastrukturu automatizacije
1
Lokalno trčanje
Node.js, Selen, Appium
- Najpopularniji alati za web i mobilne uređaje
- Podržava mnoge jezike i platforme (uključujući Node.js)
2
Sistemi za kontrolu verzija
ići
- Slične prednosti sa razvojnim kodom
3
Kontejnerizacija
Docker, Selenium grid, Selenoid (Web, Android)
- Paralelno izvođenje testova
- Izolovana okruženja
- Jednostavne, fleksibilne nadogradnje verzije
- Dinamičko zaustavljanje neiskorištenih resursa
- Jednostavno postavljanje
4
CI/CD
Gitlab CI
- Testira dio cjevovoda
- Bystraâ obratnaâ svâzʹ
- Vidljivost za cijelu kompaniju/tim
5
Cloud platforme
Google Cloud Platform
- Resursi na zahtjev (plaćamo samo po potrebi)
- Jednostavan za upravljanje i ažuriranje
- Vidljivost i kontrola svih resursa
6
Orkestracija
Kubernet
U kontekstu kontejnera sa pretraživačima/emulatorima unutar podova:
- Skaliranje/automatsko skaliranje
- Samoizlječenje
- Ažuriranja i vraćanja bez prekida
7
Infrastruktura kao kod (IaC)
Terraform, Ansible
- Slične pogodnosti sa razvojnom infrastrukturom
- Sve prednosti verzioniranja koda
- Lako se menja i održava
- Potpuno automatizovan
Dijagrami mape uma: evolucija infrastrukture
korak 1: Lokalno
korak 2: VCS
korak 3: Kontejnerizacija
korak 4: CI/CD
korak 5: Cloud platforme
korak 6: Orkestracija
korak 7: IaC
Što je sljedeće?
Dakle, ovo je kraj članka. Ali u zaključku, želeo bih da uspostavim neke dogovore sa vama.
Sa tvoje strane
Kao što je rečeno na početku, želio bih da članak bude od praktične koristi i da vam pomogne da stečeno znanje primijenite u stvarnom radu. Opet dodajem.
Ali ni nakon toga nemojte stati, vježbajte, proučavajte relevantne linkove i knjige, saznajte kako to funkcionira u vašoj kompaniji, pronađite mjesta koja se mogu poboljšati i sudjelujte u tome. Sretno!
Sa moje strane
Iz naslova se vidi da je ovo bio samo prvi dio. Uprkos činjenici da se ispostavilo da je prilično velika, važne teme ovdje još uvijek nisu obrađene. U drugom dijelu planiram pogledati infrastrukturu automatizacije u kontekstu IOS-a. Zbog Appleovih ograničenja za pokretanje iOS simulatora samo na macOS sistemima, naš raspon rješenja je sužen. Na primjer, ne možemo koristiti Docker za pokretanje simulatora ili javne oblake za pokretanje virtuelnih mašina. Ali to ne znači da nema drugih alternativa. Pokušat ću vas držati u toku sa naprednim rješenjima i modernim alatima!
Također, nisam spomenuo dosta velike teme vezane za monitoring. U trećem dijelu, pogledat ću najpopularnije alate za praćenje infrastrukture i koje podatke i metrike treba uzeti u obzir.
I na kraju. U budućnosti planiram objaviti video kurs o izgradnji testne infrastrukture i popularnih alata. Trenutno postoji dosta kurseva i predavanja o DevOps-u na internetu, ali svi materijali su predstavljeni u kontekstu razvoja, a ne automatizacije testiranja. Po ovom pitanju, zaista mi je potrebna povratna informacija o tome da li će takav kurs biti zanimljiv i vrijedan za zajednicu testera i inženjera automatizacije. Hvala unapred!
izvor: www.habr.com