Čo je DevOps? Základné princípy, výhody a nástroje

Autor: Michaela Kojnoková

CloudHľadanie práceProgramovanie

DevOps spája vývoj a prevádzku softvéru do jedného procesu, v ktorom sa tímy nestriedajú, ale pracujú súbežne. Ak premýšľaš nad kariérou v programovaní, testovaní alebo v správe infraštruktúry, je to pojem, na ktorý narazíš hneď na začiatku. Čo teda DevOps znamená, ako vyzerá jeho cyklus, aké nástroje sa v ňom používajú, čo robí DevOps engineer (m/ž), od čoho závisí plat na tejto pozícii a čo sa treba naučiť, ak chceš túto prácu robiť?

DevOps nie je nástroj, ale spôsob práce

DevOps je prístup, ktorý spája vývoj (Development) a prevádzku (Operations) softvéru do jedného kontinuálneho procesu, ako ho vo svojom prehľade popisuje aj Atlassian, jeden z tvorcov nástrojov, ktoré sa v tomto procese bežne používajú.

Nenainštaluješ si ho, nie je to nástroj ani softvér. Je to spôsob práce, pri ktorom sa ľudia zodpovední za písanie kódu a ľudia zodpovední za jeho beh v produkcii nestriedajú v štafete, ale nesú spoločnú zodpovednosť za výsledok od návrhu až po prevádzku. Alebo jednoduchšie – DevOps je dohoda, že za beh softvéru zodpovedá celý tím, nie ten posledný v rade.

Tímy, ktoré takto pracujú, dodávajú zmeny častejšie a v menších dávkach. Menšia zmena znamená menšie riziko, rýchlejšie odhalenie chyby a lacnejšiu opravu. Rozdiel oproti tradičnému postupu nie je v tom, že sa pracuje rýchlejšie, ale v tom, že sa pracuje v kratších slučkách so spätnou väzbou.

Mení sa aj to, ako členovia a členky tímu nazerajú na produkt. Namiesto otázky „Funguje moja časť?“ sa pýtajú: „Funguje to, čo dostane zákazník?“ Vďaka tomu sa chyby odhalia skôr a nasadenie býva predvídateľnejšie.

Ako vznikol DevOps

Koncept vznikol ako reakcia na oddelené fungovanie vývoja a prevádzky, ktoré v mnohých firmách predlžovalo cestu softvéru k používateľovi.

V minulosti fungovala práca v IT firmách veľmi oddelene. Vývojové tímy pripravili aplikáciu a odovzdali ju ďalším špecialistom a špecialistkám, napríklad testerom a testerkám. Tí ju otestovali, odhalili chyby a vrátili ju späť na opravu. Medzi jednotlivými krokmi vznikali prestoje a každý tím videl len svoj výsek.

Práve preto vznikol koncept, v ktorom sa do procesu kontinuálne zapájajú všetci odborníci z oblasti vývoja aj prevádzky, ako dokumentuje aj samotný priebeh vzniku hnutia.

Kultúra spolupráce a automatizácie

Základom DevOps je spolupráca naprieč rolami a automatizácia opakujúcich sa krokov.

Otvorená komunikácia a zdieľaná zodpovednosť za výsledný produkt vedú k rýchlejšiemu reagovaniu na nečakané problémy, menšiemu riziku zlyhania a bezpečnejšej práci, čo potvrdzuje aj prehľad princípov od IBM venovaný práve tejto téme. Automatizácia k tomu pridáva predvídateľnosť: krok, ktorý vykoná stroj, prebehne zakaždým rovnako, kým ručný krok závisí od toho, kto ho práve robí a či nemá zlý deň.

Ide o kombináciu oboch vecí. Automatizácia bez spolupráce znamená len rýchlejšie opakovanie tých istých chýb. Spolupráca bez automatizácie naráža na ľudskú kapacitu, len čo je zmien viac než pár za mesiac.

Základné princípy a fázy DevOps

Cyklus DevOps má štyri fázy, ktoré na seba nadväzujú a neustále sa opakujú: plánovanie, vývoj, testovanie a nasadenie.

Životný cyklus DevOps nemá jednu záväznú podobu ani jednotný počet fáz. Rôzne modely ho členia inak. V tomto článku ho zjednodušujeme na štyri široké oblasti. Testovanie, bezpečnosť, monitoring a spätná väzba pritom prebiehajú priebežne naprieč celým cyklom, nielen v jednej z nich.

Cyklus DevOps (DevOps lifecycle)

Fázy netvoria priamku s koncom, ale slučku. Po nasadení sa z monitoringu vracia spätná väzba do plánovania a celý cyklus beží odznova.

1. Plánovanie: navrhuje sa aplikácia alebo systém, na ktorom sa bude pracovať. Definuje sa, ako bude vyzerať, aké bude mať funkcie a na čo sa bude používať. Už v tejto fáze sú prítomní všetci odborníci, aby každý člen tímu vedel, čo sa chystá. Na plánovanie sa používajú nástroje na tvorbu úloh a vizualizáciu procesov, napríklad Jira, Trello, Asana alebo Azure DevOps.
2. Vývoj: zahŕňa samotné písanie kódu. Túto úlohu majú na starosti programátori a programátorky. Pracuje sa pri nej s verziovacím nástrojom, najčastejšie so systémom Git. Nový kód sa integruje priebežne, nie raz za týždeň alebo mesiac. Ostatní tak vedia nájsť a odstrániť chybu podstatne skôr.
3. Testovanie: prebieha priebežne počas vývoja aj doručovania, nie až po dopísaní kódu. Testy sa spúšťajú vždy, keď príde zmena alebo pribudne ďalšia časť kódu. Okrem funkčných testov sa využíva aj bezpečnostné testovanie, ktoré preveruje, či nový kód neprináša novú zraniteľnosť. Cieľom je odhaliť technické aj bezpečnostné chyby skôr, než sa s nimi stretne používateľ.
4. Nasadenie: otestovaný kód sa nasadí do produkcie a používatelia ho začnú využívať. Tu sa však práca nekončí – produkt sa monitoruje a overuje sa, či funguje tak, ako má. Pri chybe treba zasiahnuť okamžite a poznatok z incidentu ide späť do plánovania ďalšej zmeny.

Continuous integration (CI) a continuous delivery (CD)

CI/CD (continuous integration/continuous delivery) je technický základ DevOps – automatizuje cestu kódu od commitu po nasadenie.

Odporúčame ti:

Túto problematiku podrobne rozoberáme v samostatnom článku o continuous integration a continuous delivery a detailne o CI/CD z pohľadu testingu píšu kolegovia na msgtester.sk.

• Continuous integration (priebežná integrácia, CI) znamená, že každý špecialista zlučuje svoje zmeny do hlavnej vetvy postupne, po menších častiach. V tímoch, kde sa všetko spája až na konci, vznikajú konflikty, komponenty spolu nespolupracujú a chyby sa objavujú naraz. Pri priebežnej integrácii je problém menší a dá sa opraviť hneď.
• Continuous delivery (priebežné dodávanie, CD) na to nadväzuje. Po tom, ako sa nová časť kódu integruje do hlavnej vetvy, automaticky sa zostaví, otestuje a je pripravená na nasadenie do produkcie, ktoré ešte môže vyžadovať schválenie. Cieľom je, aby sa nové funkcie dostali k zákazníkom v krátkom čase a aby produkt fungoval plynulo a spoľahlivo.

Odporúčame ti:

Pojem continuous delivery sa často mýli s pojmom continuous deployment. Hoci vyzerajú podobne, v jednej veci sa líšia: pri continuous deployment sa nevyžaduje žiadne manuálne schválenie. Keď kód prejde testami, automaticky sa nasadí do produkcie. Nasadenie pritom nemusí znamenať okamžité sprístupnenie všetkým používateľom, napríklad pri použití feature flags.

Výhody DevOps pre firmy

Medzi najväčšie výhody DevOps patria.

• Rýchlejšie dodanie softvéru

Tímy pracujúce v DevOps dodávajú zmeny častejšie, lebo cesta od kódu do produkcie je automatizovaná a nečaká sa na odovzdanie medzi oddeleniami. Ušetrený čas sa dá investovať do vývoja nových funkcií namiesto koordinácie. Tímy zároveň pružnejšie reagujú na spätnú väzbu od zákazníkov a rýchlejšie odstraňujú chyby, ktoré komplikujú používanie aplikácie.

Prínos sa dá aj merať. Výskumný program DORA dnes sleduje päť metrík výkonnosti dodávania softvéru: ako často tím nasadzuje, ako dlho trvá cesta zmeny od commitu do produkcie, ako rýchlo sa tím zotaví po zlyhanom nasadení, aký podiel nasadení spôsobí problém a aký podiel nasadení vyvolá neplánovanú prácu v dôsledku incidentu v produkcii. Prvé tri hovoria o priepustnosti, zvyšné dve o stabilite. Tímy s vyspelým DevOps procesom si vedú dobre naprieč všetkými piatimi, nielen v rýchlosti.

• Zlepšená kvalita a spoľahlivosť

Automatizované testy bežia pri každej zmene a spoľahlivo zopakujú presne tie scenáre, ktoré tím napísal. Tým sa znižuje počet drobných ľudských chýb, ktoré sa v ručnom procese objavia vždy. Ich hodnota však stojí a padá na pokrytí a stabilite testov. Monitoring beží nepretržite nad bežiacim systémom a zachytí odchýlky, ktoré by si človek nemusel všimnúť.

Druhý efekt je menej viditeľný. Keď testy bežia automaticky, v testovaní ubúda čas na opakované klikanie a zostáva priestor na činnosti, ktoré stroj nezvládne: prieskumné testovanie, hraničné prípady a kontrolu použiteľnosti.

• Efektívnejšia spolupráca tímov

V tradične nastavených firmách fungujú tímy ako samostatné jednotky a komunikácia medzi nimi je minimálna. To vedie k chybám, ktorým sa dalo jednoducho predísť: prevádzka nevie, čo prichádza, a vývoj nevie, ako sa aplikácia v produkcii správa. DevOps tieto tímy prepája a znižuje riziko komunikačného šumu, čo urýchľuje riešenie problémov aj rozhodovanie.

Zmena sa týka aj toho, ako sa rieši incident. V oddelenom modeli sa hľadá, kto zaň môže. V DevOps tíme sa hľadá, ktorý krok procesu ho pustil ďalej, a upraví sa proces. Znie to ako detail, ale rozhoduje o tom, či ľudia problémy hlásia alebo skrývajú.

Zníženie nákladov a rizík

Úspora vzniká kombináciou troch vecí – automatizácie opakujúcich sa krokov, častejšieho nasadzovania menších zmien a skoršieho odhalenia chýb. Platí pritom jednoduché pravidlo. Chyba nájdená pri integrácii býva podstatne lacnejšia než tá istá chyba v produkcii, ktorá stojí čas celého tímu a má dopad na zákazníka.

Netreba pritom čakať na kompletné zavedenie. Aj čiastočné zavedenie, napríklad automatizovaný build a testy pri každom commite, prináša citeľný prínos. Zvyšok sa dá dobudovať postupne.

DevOps nástroje

DevOps nástroje (DevOps tools) pokrývajú štyri oblasti: správu kódu, CI/CD, kontajnerizáciu a monitoring.

Aké nástroje sa v DevOps používajú, závisí od toho, s čím tím pracuje a čo už má nasadené. Nižšie sú tie, na ktoré narazíš najčastejšie.

Správa verzií a hosting repozitárov

Na správu verzií sa používa Git. Umožňuje tímu spolupracovať na jednom kóde a sledovať, kto akú zmenu urobil. GitHub, GitLab a Bitbucket sú platformy na hosting Git repozitárov a spoluprácu na kóde, ktoré k tomu pridávajú žiadosti o zlúčenie zmien, správu oprávnení a často aj vlastné CI/CD. Bez správy verzií nefunguje ani jedna ďalšia časť DevOps procesu. Popri samotnom nástroji je dôležitá aj dohoda o tom, ako sa pracuje s vetvami. Tím, ktorý drží vetvy oddelené celé týždne, o výhody kontinuálnej integrácie zasa príde.

Nástroje na CI/CD

Ich úlohou je automatizovať integráciu a nasadzovanie kódu – spustiť build, otestovať ho a nasadiť výsledok do prostredia. Rozšírené sú Jenkins, GitLab CI/CD alebo CircleCI.

K nim patrí aj správa citlivých údajov, teda hesiel, tokenov a prístupových kľúčov. Tie sa nesmú v otvorenej podobe ukladať do repozitára ani priamo zapisovať do konfigurácie. Pipeline si ich vyzdvihne až v momente behu, a to z chráneného úložiska v CI/CD alebo z externého systému na správu tajomstiev.

Kontajnerizácia a orchestrácia

Kontajner zabalí aplikáciu spolu so všetkým, čo potrebuje na beh, takže sa vo vývojovom prostredí aj na produkčnom serveri správa oveľa predvídateľnejšie. Výsledok stále ovplyvňuje konfigurácia, dáta, sieť a externé služby, takže nejde o úplnú zhodu prostredí. Na kontajnerizáciu sa používa Docker, na orchestráciu, teda riadenie veľkého počtu kontajnerov, Kubernetes. Ako kontajnerizácia funguje a kde ju využiješ, rozoberáme v samostatnom článku.

Samostatnou kategóriou je infraštruktúra ako kód. Namiesto ručného nastavovania serverov sa prostredie popíše konfiguračným súborom, ktorý je uložený v správe verzií, buď spolu s aplikáciou, alebo v samostatnom infraštruktúrnom repozitári. Terraform je priamo nástroj infraštruktúry ako kódu, Ansible sa používa najmä na konfiguračný manažment, automatizáciu a nasadzovanie. Výhoda je rovnaká ako pri kóde: vidíš históriu zmien, zmena prejde code review a prostredie sa dá kedykoľvek postaviť odznova.

Monitoring, metriky a logy

Monitoring sleduje, ako sa softvér správa v produkcii. Na zber a vyhodnocovanie metrík sa často používa Prometheus, na ich vizualizáciu a upozornenia Grafana. Logy spravidla ukladá samostatný systém, napríklad Grafana Loki, Elastic Stack alebo OpenSearch, a Grafana ich vie zobraziť po pripojení príslušného dátového zdroja. Bezpečnostné skenovanie ani SIEM tieto nástroje nenahrádzajú. Monitoring je to, čo uzatvára cyklus: bez neho tím nevie, či nasadená zmena skutočne pomohla.

Nástroje sa menia rýchlejšie než princípy. Preto sa oplatí naučiť sa poriadne jeden z každej kategórie, nie povrchne desať. Kto rozumie tomu, ako funguje pipeline v jednom nástroji, prejde na iný za pár dní.

Digitalizácia16 min.

Prečítaj si aj:

Container technology: Ako funguje kontajnerizácia a kde ju využiješ?

Container technology vysvetľuje, ako kontajnerizácia zjednodušuje vývoj aplikácií a prečo sú Docker a Kubernetes základom moderného DevOps.

DevOps v praxi: typické scenáre použitia

DevOps nájde uplatnenie všade, kde sa softvér mení často a zároveň nesmie prestať fungovať, teda v startupoch, veľkých korporáciách aj v cloude.

V startupoch umožňuje rýchlo nasadzovať nové funkcie a overovať ich na reálnych používateľoch. Tím je malý, jeden človek často pokrýva viac rolí a automatizácia mu nahrádza kapacitu, ktorú nemá.

Zároveň tu platí, že malé a ľahko zvrátiteľné experimenty znižujú cenu omylu. Ak sa nová funkcia neosvedčí, vráti sa späť a skúsi sa iná. Neplatí to však bez výnimky: pri strate dát alebo bezpečnostnom incidente je následok rovnako drahý ako inde. Práve preto sa v startupoch DevOps zavádza skoro a bez veľkých diskusií.

Vo veľkých korporáciách rieši opačný problém. Tímov je veľa, závislosti medzi nimi husté a bez spoločného procesu sa každé nasadenie mení na koordinačné cvičenie. DevOps tu znižuje riziko práve pri zložitých projektoch.

Pribúda aj požiadavka na audit. Vo väčších firmách musí byť dohľadateľné, kto zmenu schválil a kedy sa dostala do produkcie. Automatizovaná pipeline túto stopu vytvára sama, kým pri ručnom nasadzovaní ju musí niekto dopisovať do dokumentu.

V cloude podporuje automatizáciu a škálovanie. Prostredie sa dá vytvoriť skriptom a zrušiť, keď nie je potrebné, takže testovacie prostredie už nie je vzácny zdroj, o ktorý sa tímy delia.

Cloud zároveň mení spôsob, akým sa platí za chyby. Nevyužité prostredie, ktoré niekto zabudol vypnúť, sa premietne priamo do faktúry, takže automatické rušenie dočasných prostredí nie je len poriadkumilovnosť, ale úspora.

V poisťovníctve k tomu pribúda ešte jedna vrstva. Core poistný systém spravuje zmluvy, ktoré bežia desiatky rokov, a jeho výpadok sa dotkne klientov aj regulačných povinností. Regulačné zmeny navyše často prichádzajú v krátkych termínoch, takže rýchlosť dodania nie je komfort, ale podmienka.

Ako to vyzerá v praxi, popisuje msg pri svojom riešení pre poisťovne: nasadzovanie stojí na deployment pipeline, ktorá automatizuje všetky kroky spracovania a validácie pred vydaním, na automatizovaných integračných a end-to-end testoch pri každej zmene a na zhode prostredí, teda na tom, že vývoj, testovanie aj produkcia používajú identický spôsob nasadenia.

Odporúčame ti:

Ak chceš DevOps zaviesť vo firme, začni v malom. Zaveď správu verzií kódu a jednu automatizovanú pipeline pre jeden projekt, zapoj do nej vývoj a testovanie a až potom pridávaj monitoring a ďalšie oblasti. Zavádzanie všetkého naraz spravidla skončí tým, že tím sa vráti k pôvodným zvykom.

Čo robí DevOps engineer (m/ž)

DevOps engineer (m/ž), po slovensky DevOps inžinier, prepája vývoj softvéru a jeho prevádzku a stará sa o to, aby nové verzie aplikácií vznikali rýchlo, spoľahlivo a dali sa jednoducho nasadiť.

DevOps engineer z pohľadu tímu zodpovedá za cestu kódu do produkcie a stará sa o to, aby po nej vedeli bezpečne prejsť aj ostatní. Nie je to ani čisto programátorská práca, ani klasická správa serverov. Je to rola na rozhraní oboch svetov – rozumie kódu natoľko, že vie, čo nasadzuje, a infraštruktúre natoľko, že vie, kde to spadne.

Medzi typické zodpovednosti patrí návrh a údržba CI/CD pipeline, správa testovacích a produkčných prostredí, automatizácia opakujúcich sa úloh, nastavenie monitoringu a upozornení a riešenie incidentov v produkcii. K tomu pribúda bezpečnosť: kontrola závislostí a prístupov je dnes súčasť pipeline, nie samostatná disciplína na konci.

Typický deň nevyzerá ako nepretržité programovanie. Ráno sa pozrie, čo v noci zlyhalo a či išlo o skutočnú chybu alebo o nestabilný test. Cez deň rieši požiadavky z vývoja na nové prostredie alebo úpravu pipeline, priebežne opravuje to, čo sa po zmene v aplikácii rozbilo, a keď zostane čas, automatizuje niečo, čo sa doteraz robilo ručne.

Zručnosti sa dajú zhrnúť do piatich oblastí.

Čo táto rola nerobí a s kým spolupracuje

Užitočné je vedieť aj to, čím táto rola nie je. Nie je to človek, ktorý nasadzuje za ostatných, ani jediná osoba s prístupom do produkcie. Ak tím takto DevOps chápe, vytvoril si len nové úzke hrdlo s novým názvom. Zmyslom je, aby sa zmena dala nasadiť samostatne a bezpečne priamo z vývoja, a úlohou tejto roly je postaviť cestu, po ktorej to urobí.

V tíme spolupracuje prakticky so všetkými. S vývojom rieši, ako sa aplikácia bude nasadzovať a konfigurovať, s testovaním to, aby automatizované testy bežali v pipeline, a s bezpečnosťou kontrolu zraniteľností. Značná časť práce je komunikácia, nie kód.

Rola sa v inzerátoch objavuje pod viacerými názvami – DevOps inžinier, stretneš sa však aj s označením DevOps špecialista, DevOps vývojár alebo DevOps programátor, spravidla s doplnkom (m/ž).

Príbuzné, no odlišné sú role Platform Engineer a Site Reliability Engineer, ktoré sa zameriavajú na internú platformu pre vývojové tímy a na dostupnosť behu, a Build Engineer alebo Configuration Manager, ktorí riešia najmä build infraštruktúru a správu konfigurácie.

Aký je plat na tejto pozícii?

Plat na pozícii DevOps engineer (m/ž) sa líši podľa toho, koľko praxe máš a kam nastúpiš. Na konečnú sumu vplýva viacero premenných:

• Seniorita – na začiatku sú platy nižšie než pri ľuďoch, ktorí navrhujú architektúru nasadzovania pre viacero tímov.
• Región a typ firmy – zahraničné korporácie a firmy v Bratislave ponúkajú iné podmienky než menšie lokálne tímy, práca na diaľku tento rozdiel zmenšuje.
• Technológie – práca s cloudom, Kubernetes a infraštruktúrou ako kód je ohodnotená inak než údržba jednej pipeline.
• Jazyk – projekty pre nemecký alebo anglický trh mávajú iné podmienky než čisto lokálne zadania.

Napríklad mzda na pozícii Senior DevOps Engineer pre poisťovníctvo (m/ž) v msg life Slovakia sa začína od 3 500 eur (mesačná hrubá mzda). Ide o seniornú rolu, takže zodpovedá viacročnej praxi, nie vstupu do profesie. Konkrétna výška vychádza z objektívnych kritérií hodnotenia pracovného miesta a zo skúseností, ktoré do roly prinášaš.

K mzde patí aj nástupný bonus a rôzne odmeny a prémie, napríklad vianočná prémia až do výšky základnej mesačnej mzdy, ako aj ďalšie benefity, ako sú napríklad:

• príspevok na stravné nad rámec zákona,
• príspevok do III. piliera a príspevok na hobby 200 eur ročne,
• 5 dní dovolenky nad zákonný rámec a deň plateného voľna na Silvestra,
• home office alebo kancelária podľa vlastného výberu a pružný pracovný čas,
• interné aj externé vzdelávanie a bezplatné kurzy nemčiny a angličtiny.

Ako sa stať DevOps inžinierom/inžinierkou

Na pozíciu DevOps engineer (m/ž) sa najčastejšie prichádza z vývoja, testovania alebo správy infraštruktúry, nie priamo zo školy. Nie je to však jediná možná cesta.

Dôvod je jednoduchý. Rola stojí na tom, že rozumieš aspoň jednej strane poriadne a druhú sa doučíš. Kto prichádza z vývoja, dopĺňa si prevádzku a infraštruktúru. Kto spravuje servery, dopĺňa si programovanie a prácu s verziovaním. Kto prichádza z testovania, býva dobre zorientovaný v tom, čo sa v pipeline reálne deje.

Dáva zmysel učiť sa v tomto poradí: najprv Git a práca s vetvami, potom jeden skriptovací jazyk, potom Docker, následne nastavenie vlastnej CI/CD pipeline na malom projekte a až nakoniec Kubernetes a cloud. Opačné poradie vedie k tomu, že nástroje ovládaš bez toho, aby ti bolo jasné, aký problém riešia.

Ak s programovaním ešte len začínaš, dáva zmysel najprv zvládnuť základy programovania a až potom stavať okolo kódu automatizáciu. Najrýchlejšie sa naučíš na vlastnom projekte. Zober si čokoľvek, čo máš napísané, a postav okolo toho pipeline: build pri každom commite, automatické testy, nasadenie do testovacieho prostredia a jednoduchý monitoring. Aj malý projekt tohto typu naučí viac než prednáška.

Certifikáty od poskytovateľov cloudu vedia pomôcť pri prvom pohovore, ale samy o sebe prácu nezískajú. Zamestnávateľ sa spravidla pýta na konkrétnu vec, ktorú máš postavenú, a na to, prečo vyzerá práve tak. Preto má malý reálny projekt väčšiu váhu než zoznam absolvovaných kurzov.

Kariérna cesta má tri bežné stupne:

• Junior: pracuješ na existujúcej pipeline, opravuješ zlyhania buildov, píšeš menšie automatizačné skripty a učíš sa prostredie projektu. Rozhodnutia robí niekto iný.
• Medior: navrhuješ a nastavuješ pipeline pre nové projekty, spravuješ prostredia, riešiš incidenty a vieš odhadnúť, čo sa pri zmene pravdepodobne pokazí.
• Senior: navrhuješ architektúru nasadzovania pre viacero tímov, rozhoduješ o nástrojoch a štandardoch, mentoruješ ostatných a konzultuje sa s tebou všetko, čo má vplyv na celú platformu.

Cesta z testovania má jednu výhodu navyše. Kto prichádza z testovania, už vie, ako sa aplikácia správa, kde býva krehká a čo znamená, keď test zlyhá nepravidelne. To sú presne otázky, ktoré rieši DevOps engineer pri údržbe pipeline, takže prechod býva plynulejší, než sa čaká.

Zdieľaj článok

Čo je DevOps? Základné princípy, výhody a nástroje

Michaela Kojnoková

Vyštudovala som informatiku na ŽU a TUKE a už niekoľko rokov pôsobím v oblasti softvérového testovania. Špecializujem sa na automatizáciu testov, Python a DevOps procesy. Popri práci ma baví vzdelávať sa ďalej v oblasti machine learningu a vývoja umelej inteligencie a objavovať možnosti jej využitia v praxi. Svoje skúsenosti a poznatky z oblasti AI, testovania a moderných technológií taktiež pravidelne zdieľam prostredníctvom odborných článkov.