{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Pr\u00edru\u010dka pre za\u010diato\u010dn\u00edkov: vytv\u00e1rame DevOps pipeline","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ak ste nov\u00e1\u010dik v DevOps, pozrite sa na tento n\u00e1vod na vytvorenie v\u00e1\u0161ho prv\u00e9ho pipelinu v piatich krokoch.<\/i><\/p>\n

\"Pr\u00edru\u010dka<\/p>\n

DevOps sa stal \u0161tandardn\u00fdm rie\u0161en\u00edm na opravu pomal\u00fdch, roztrhnut\u00fdch alebo nefunguj\u00facich procesov v\u00fdvoja softv\u00e9ru. Probl\u00e9m je v tom, \u017ee ak ste nov\u00e1\u010dik v DevOps a neviete, odkia\u013e za\u010da\u0165, m\u00f4\u017ee v\u00e1m ch\u00fdba\u0165 pochopenie t\u00fdchto metod\u00edk. V tomto \u010dl\u00e1nku sa zameriame na defin\u00edciu DevOps pipelinu a pon\u00fakneme n\u00e1vod na jeho vytvorenie v piatich krokoch. Hoci tento tutori\u00e1l nie je vy\u010derp\u00e1vaj\u00faci, mal by v\u00e1m poskytn\u00fa\u0165 z\u00e1klad, aby ste mohli za\u010da\u0165 svoju cestu a nielen roz\u0161\u00edri\u0165 svoje vedomosti. Ale za\u010dnime s hist\u00f3riou.<\/p>\n

Moja cesta v oblasti DevOps<\/h3>\n

\nPredt\u00fdm som pracoval v cloudovom t\u00edme Citi Group, kde som vyv\u00edjal webov\u00fa aplik\u00e1ciu Infrastructure-as-a-Service (IaaS) na spr\u00e1vu cloudovej infra\u0161trukt\u00fary Citi, ale v\u017edy ma zauj\u00edmalo, ako spravi\u0165 proces v\u00fdvoja efekt\u00edvnej\u0161\u00edm a prinies\u0165 pozit\u00edvne kult\u00farne zmeny do v\u00fdvojov\u00e9ho t\u00edmu. Odpove\u010f som na\u0161iel v knihe, ktor\u00fa odporu\u010dil Greg Lavender, technick\u00fd riadite\u013e Citi pre cloudov\u00fa architekt\u00faru a infra\u0161trukt\u00faru. Kniha sa volala \u201eProjekt F\u00e9nix\u201c (The Phoenix Project<\/a><\/noindex>), a v nej s\u00fa vysvetlen\u00e9 princ\u00edpy DevOps, pri\u010dom sa \u010d\u00edta ako rom\u00e1n.<\/p>\n

V tabu\u013eke na zadnej strane knihy je zobrazen\u00e9, ako \u010dasto r\u00f4zne spolo\u010dnosti nasadzuj\u00fa svoje syst\u00e9my na distribu\u010dn\u00e9 prostredie pre vydanie verzi\u00ed:<\/p>\n

Amazon: 23 000 denne
\nGoogle: 5 500 denne
\nNetflix: 500 denne
\nFacebook: Raz denne
\nTwitter: 3 kr\u00e1t za t\u00fd\u017ede\u0148
\nTypick\u00e1 spolo\u010dnos\u0165: Raz za 9 mesiacov<\/p>\n

Ako je v\u00f4bec mo\u017en\u00e9, \u017ee Amazon, Google a Netflix maj\u00fa tak\u00fato frekvenciu? V\u0161etko je to preto, \u017ee tieto spolo\u010dnosti vymysleli, ako vytvori\u0165 takmer dokonal\u00fd DevOps pipeline.
\n<\/a><\/noindex>
\nBoli sme od toho \u010faleko, k\u00fdm sme neza\u010dali implementova\u0165 DevOps v Citi. Vtedy mala moja t\u00edm r\u00f4zne prostredia, av\u0161ak nasadenie na v\u00fdvojov\u00fd server bolo \u00faplne manu\u00e1lne. V\u0161etci v\u00fdvoj\u00e1ri mali pr\u00edstup iba k jedn\u00e9mu v\u00fdvojov\u00e9mu serveru zalo\u017een\u00e9mu na IBM WebSphere Application Server Community Edition. Probl\u00e9m bol v tom, \u017ee server sa v\u017edy vypol, ke\u010f sa viacer\u00ed pou\u017e\u00edvatelia pok\u00fasili naraz vykona\u0165 nasadenie, tak\u017ee v\u00fdvoj\u00e1ri sa museli navz\u00e1jom informova\u0165 o svojich \u00famysloch, \u010do bolo dos\u0165 bolestn\u00e9. Navy\u0161e existovali probl\u00e9my so z\u00e1kladn\u00fdm testovan\u00edm pokrytia k\u00f3du, nepraktick\u00fdmi manu\u00e1lnymi procesmi nasadenia a nedostatkom mo\u017enosti sledova\u0165 nasadenie k\u00f3du spojen\u00e9ho s konkr\u00e9tnou \u00falohou alebo pou\u017e\u00edvate\u013esk\u00fdm pr\u00edbehom.<\/p>\n

Uvedomil som si, \u017ee je potrebn\u00e9 nie\u010do urobi\u0165, a na\u0161iel som kolegu, ktor\u00fd mal podobn\u00e9 n\u00e1zory. Rozhodli sme sa spolupracova\u0165 na vytvoren\u00ed po\u010diato\u010dn\u00e9ho DevOps kan\u00e1la \u2013 on nain\u0161taloval virtu\u00e1lny stroj a server aplik\u00e1ci\u00ed Tomcat, zatia\u013e \u010do ja som pracoval na Jenkins, integroval Atlassian Jira a BitBucket a pracoval na pokryt\u00ed testovania k\u00f3du. Tento ved\u013eaj\u0161\u00ed projekt bol ve\u013emi \u00faspe\u0161n\u00fd: takmer sme \u00faplne automatizovali mnoho procesov, dosiahli sme takmer 100% funk\u010dnos\u0165 n\u00e1\u0161ho v\u00fdvojov\u00e9ho servera, zabezpe\u010dili sme sledovanie a zlep\u0161ili pokrytie testovania k\u00f3du a pridali mo\u017enos\u0165 prepoji\u0165 vetvy v Gite s \u00falohami v Jira alebo nasaden\u00edm. V\u00e4\u010d\u0161ina n\u00e1strojov, ktor\u00e9 sme pou\u017eili na budovanie n\u00e1\u0161ho DevOps kan\u00e1la, mala otvoren\u00fd zdrojov\u00fd k\u00f3d.<\/p>\n

Teraz ch\u00e1pem, ak\u00fd jednoduch\u00fd bol n\u00e1\u0161 DevOps pipeline: nepou\u017e\u00edvali sme roz\u0161\u00edrenia ako Jenkins files alebo Ansible. Av\u0161ak tento jednoduch\u00fd kan\u00e1l fungoval dobre, pravdepodobne v\u010faka Pareto princ\u00edpu (zn\u00e1mej\u0161iemu ako pravidlo 80\/20).<\/p>\n

Kr\u00e1tke uvedenie do DevOps a pipeline CI\/CD<\/h3>\n

\nAk sa op\u00fdtate nieko\u013ek\u00fdch \u013eud\u00ed: \u201e\u010co je to DevOps?\u201c, pravdepodobne dostanete nieko\u013eko r\u00f4znych odpoved\u00ed. DevOps, podobne ako Agile, sa vyvinul tak, aby zah\u0155\u0148al mno\u017estvo r\u00f4znych discipl\u00edn, ale v\u00e4\u010d\u0161ina \u013eud\u00ed s\u00fahlas\u00ed s niektor\u00fdmi vecami: DevOps je prax v\u00fdvoja softv\u00e9ru alebo \u017eivotn\u00e9ho cyklu v\u00fdvoja softv\u00e9ru (SDLC), ktor\u00e9ho centr\u00e1lnym princ\u00edpom je zmena kult\u00fary, v ktorej existuj\u00fa v\u00fdvoj\u00e1ri a ne-v\u00fdvoj\u00e1ri v prostred\u00ed, v ktorom:<\/p>\n

S\u00fa automatizovan\u00e9 oper\u00e1cie, ktor\u00e9 predt\u00fdm vykon\u00e1vali manu\u00e1lne;
\nKa\u017ed\u00fd rob\u00ed to, \u010do najlep\u0161ie ovl\u00e1da;
\nZv\u00fd\u0161uje sa po\u010det nasaden\u00ed za ur\u010dit\u00e9 \u010dasov\u00e9 obdobie; Zvy\u0161uje sa priepustnos\u0165;
\nZvy\u0161uje sa flexibilita v\u00fdvoja.<\/p>\n

Hoci ma\u0165 spr\u00e1vne softv\u00e9rov\u00e9 n\u00e1stroje nie je jedin\u00e9, \u010do potrebujete na vytvorenie prostredia DevOps, niektor\u00e9 n\u00e1stroje s\u00fa nevyhnutn\u00e9. K\u013e\u00fa\u010dov\u00fdm n\u00e1strojom je nepretr\u017eit\u00e1 integr\u00e1cia a nepretr\u017eit\u00e9 nasadenie (CI\/CD). V tomto potrub\u00ed prostredia maj\u00fa r\u00f4zne f\u00e1zy (napr\u00edklad DEV, INT, TST, QA, UAT, STG, PROD), mnoh\u00e9 oper\u00e1cie s\u00fa automatizovan\u00e9 a v\u00fdvoj\u00e1ri m\u00f4\u017eu p\u00edsa\u0165 kvalitn\u00fd k\u00f3d, dosahova\u0165 flexibilitu v\u00fdvoja a vysok\u00fa frekvenciu nasaden\u00ed.<\/p>\n

V tomto \u010dl\u00e1nku sa opisuje p\u00e4\u0165f\u00e1zov\u00fd pr\u00edstup k vytvoreniu DevOps kan\u00e1la, podobn\u00e9ho tomu, ktor\u00fd je zobrazen\u00fd na nasleduj\u00facej sch\u00e9me, s vyu\u017eit\u00edm n\u00e1strojov s otvoren\u00fdm zdrojom.<\/p>\n

Krok 1: Met\u00f3dy CI\/CD<\/h3>\n

\nPrv\u00e1 vec, ktor\u00fa potrebujete, je n\u00e1stroj pre CI\/CD. Jenkins, n\u00e1stroj s otvoren\u00fdm zdrojom zalo\u017een\u00fd na Jave a distribuovan\u00fd pod licenciou MIT, je prostriedok, ktor\u00fd popularizoval smerovanie DevOps a stal sa de facto \u0161tandardom.<\/p>\n

\u010co je teda Jenkins? Pova\u017eujte to za ak\u00fdsi magick\u00fd univerz\u00e1lny dia\u013ekov\u00fd ovl\u00e1da\u010d, ktor\u00fd dok\u00e1\u017ee komunikova\u0165 s r\u00f4znymi slu\u017ebami a n\u00e1strojmi a organizova\u0165 ich. S\u00e1m o sebe je n\u00e1stroj CI\/CD, ako Jenkins, bezcenn\u00fd, ale st\u00e1va sa silnej\u0161\u00edm, ke\u010f je pripojen\u00fd k r\u00f4znym n\u00e1strojom a slu\u017eb\u00e1m.<\/p>\n

Jenkins je len jedn\u00fdm z mnoh\u00fdch n\u00e1strojov s otvoren\u00fdm zdrojom pre CI\/CD, ktor\u00e9 m\u00f4\u017eete pou\u017ei\u0165 na vytvorenie DevOps potrubia.<\/p>\n

Jenkins: Creative Commons a MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

Takto vyzeraj\u00fa DevOps procesy s n\u00e1strojom CI\/CD:<\/p>\n

\"Pr\u00edru\u010dka<\/p>\n

M\u00e1te n\u00e1stroj CI\/CD be\u017eiaci na va\u0161om localhost, ale zatia\u013e s n\u00edm nem\u00f4\u017eete ve\u013ea robi\u0165. Prejdime na nasleduj\u00faci krok na ceste do sveta DevOps.<\/p>\n

Krok 2: Spr\u00e1va syst\u00e9mov na kontrolu zdrojov\u00e9ho k\u00f3du<\/h3>\n

\nNajlep\u0161\u00ed (a mo\u017eno aj najjednoduch\u0161\u00ed) sp\u00f4sob, ako overi\u0165, \u017ee v\u00e1\u0161 n\u00e1stroj CI\/CD dok\u00e1\u017ee vykon\u00e1va\u0165 m\u00e1giu, je integr\u00e1cia s n\u00e1strojom na kontrolu zdrojov\u00e9ho k\u00f3du (SCM). Pre\u010do potrebujete kontrolu nad zdrojov\u00fdm k\u00f3dom? Predpokladajme, \u017ee vyv\u00edjate aplik\u00e1ciu. Kedyko\u013evek vytv\u00e1rate aplik\u00e1ciu, programujete, a nez\u00e1le\u017e\u00ed na tom, \u010di pou\u017e\u00edvate Java, Python, C++, Go, Ruby, JavaScript alebo ktor\u00fdko\u013evek z nespo\u010detn\u00fdch programovac\u00edch jazykov. K\u00f3d, ktor\u00fd p\u00ed\u0161ete, sa naz\u00fdva zdrojov\u00fd k\u00f3d. Na za\u010diatku, najm\u00e4 ke\u010f pracujete sami, je pravdepodobne mo\u017en\u00e9 umiestni\u0165 v\u0161etko do lok\u00e1lneho adres\u00e1ra. Ale ke\u010f projekt narast\u00e1 a poz\u00fdvate in\u00fdch, aby sa pripojili, potrebujete sp\u00f4sob, ako zabr\u00e1ni\u0165 konfliktom pri efekt\u00edvnom zdie\u013ean\u00ed zmien. Taktie\u017e potrebujete sp\u00f4sob, ako obnovi\u0165 predch\u00e1dzaj\u00face verzie, preto\u017ee vytv\u00e1ranie z\u00e1loh a kop\u00edrovanie\/vkladanie je u\u017e zastaran\u00e9. Potrebujete (a va\u0161i kolegovia z t\u00edmu) nie\u010do lep\u0161ie.<\/p>\n

Pr\u00e1ve tu sa n\u00e1stroj na kontrolu zdrojov\u00e9ho k\u00f3du st\u00e1va prakticky nevyhnutnos\u0165ou. Tento n\u00e1stroj uchov\u00e1va v\u00e1\u0161 k\u00f3d v repozit\u00e1roch, sleduje verzie a koordinuje pr\u00e1cu \u00fa\u010dastn\u00edkov projektu.<\/p>\n

Aj ke\u010f existuje mnoho n\u00e1strojov na kontrolu zdrojov\u00e9ho k\u00f3du, Git je \u0161tandardom, a to je pravda. D\u00f4razne odpor\u00fa\u010dam pou\u017e\u00edva\u0165 Git, aj ke\u010f ak chcete, s\u00fa k dispoz\u00edcii aj in\u00e9 mo\u017enosti s otvoren\u00fdm zdrojom.<\/p>\n

Git: GPLv2 a LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

Takto vyzer\u00e1 DevOps pipeline s pridan\u00edm n\u00e1strojov na kontrolu zdrojov\u00e9ho k\u00f3du.<\/p>\n

\"Pr\u00edru\u010dka<\/p>\n

N\u00e1stroj CI\/CD m\u00f4\u017ee automatizova\u0165 procesy kontroly, z\u00edskavania zdrojov\u00e9ho k\u00f3du a spolupr\u00e1ce medzi \u010dlenmi t\u00edmu. Nie zl\u00e9? Ale ako transformova\u0165 toto na funk\u010dn\u00fa aplik\u00e1ciu, aby ju miliardy \u013eud\u00ed mohli pou\u017e\u00edva\u0165 a oce\u0148ova\u0165?<\/p>\n

Krok 3: Vytvorenie n\u00e1stroja na automatiz\u00e1ciu zostavenia<\/h3>\n

\nSkvele! M\u00f4\u017eete kontrolova\u0165 k\u00f3d a robi\u0165 zmeny v syst\u00e9me spr\u00e1vy zdrojov\u00e9ho k\u00f3du, ako aj poz\u00fdva\u0165 svojich priate\u013eov na spolupr\u00e1cu v r\u00e1mci v\u00fdvoja. Ale e\u0161te ste nevytvorili aplik\u00e1ciu. Aby ste vytvorili webov\u00fa aplik\u00e1ciu, mus\u00edte ju skompilova\u0165 a zabalit' do nasadite\u013en\u00e9ho bal\u00edkov\u00e9ho form\u00e1tu alebo ju spusti\u0165 ako spustite\u013en\u00fd s\u00fabor. (V\u0161imnite si, \u017ee interpretovan\u00fd programovac\u00ed jazyk, ako JavaScript alebo PHP, nevy\u017eaduje kompil\u00e1ciu).<\/p>\n

Vyu\u017eite n\u00e1stroj na automatiz\u00e1ciu zostavovania. Bez oh\u013eadu na to, ktor\u00fd n\u00e1stroj na automatiz\u00e1ciu zostavovania sa rozhodnete pou\u017ei\u0165, v\u0161etky sleduj\u00fa rovnak\u00fd cie\u013e: zostavi\u0165 zdrojov\u00fd k\u00f3d do nejak\u00e9ho po\u017eadovan\u00e9ho form\u00e1tu a automatizova\u0165 \u00falohy \u010distenia, kompil\u00e1cie, testovania a nasadzovania v ur\u010ditej prostred\u00ed. N\u00e1stroje zostavovania sa bud\u00fa l\u00ed\u0161i\u0165 v z\u00e1vislosti od v\u00e1\u0161ho programovacieho jazyka, ale tu s\u00fa niektor\u00e9 be\u017en\u00e9 mo\u017enosti s otvoren\u00fdm zdrojom.<\/p>\n

N\u00e1zov
\nLicencia
\nProgramovac\u00ed jazyk<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

Super! M\u00f4\u017eete umiestni\u0165 konfigura\u010dn\u00e9 s\u00fabory n\u00e1stroja na automatiz\u00e1ciu zostavovania do syst\u00e9mu spr\u00e1vy zdrojov\u00e9ho k\u00f3du a umo\u017eni\u0165 svojmu CI\/CD n\u00e1stroju v\u0161etko posklada\u0165 dohromady.<\/p>\n

\"Pr\u00edru\u010dka<\/p>\n

V\u0161etko je v poriadku, nie? Ale kde nasadi\u0165 va\u0161u aplik\u00e1ciu?<\/p>\n

Krok 4: Server pre webov\u00e9 aplik\u00e1cie<\/h3>\n

\nZatia\u013e m\u00e1te zabalen\u00fd s\u00fabor, ktor\u00fd m\u00f4\u017ee by\u0165 bu\u010f spustite\u013en\u00fd, alebo in\u0161talovate\u013en\u00fd. Aby aplik\u00e1cia bola skuto\u010dne u\u017eito\u010dn\u00e1, mus\u00ed poskytova\u0165 nejak\u00fa slu\u017ebu alebo rozhranie, ale potrebujete kontajner na umiestnenie va\u0161ej aplik\u00e1cie.<\/p>\n

Server pre webov\u00e9 aplik\u00e1cie je presne tak\u00fdmto kontajnerom. Server poskytuje prostredie, v ktorom m\u00f4\u017ee by\u0165 definovan\u00e1 logika nasadite\u013en\u00e9ho bal\u00edka. Taktie\u017e server poskytuje rozhranie a pon\u00faka webov\u00e9 slu\u017eby, otv\u00e1raj\u00fac sokety pre vonkaj\u0161\u00ed svet. Potrebujete HTTP server, ako aj nejak\u00e9 prostredie (napr\u00edklad virtu\u00e1lnu ma\u0161inu) na jeho in\u0161tal\u00e1ciu. A zatia\u013e predpokladajme, \u017ee sa o tom dozviete \u010falej (aj ke\u010f o kontajneroch poviem ni\u017e\u0161ie).<\/p>\n

Existuje nieko\u013eko serverov pre webov\u00e9 aplik\u00e1cie s otvoren\u00fdm zdrojom.<\/p>\n

N\u00e1zov
\nLicencia
\nProgramovac\u00ed jazyk<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

V\u00e1\u0161 DevOps pipeline je takmer pripraven\u00fd na pou\u017eitie. Dobr\u00e1 pr\u00e1ca!<\/p>\n

\"Pr\u00edru\u010dka<\/p>\n

Aj ke\u010f sa tu m\u00f4\u017eete zastavi\u0165 a zaobera\u0165 sa integr\u00e1ciou sami, kvalita k\u00f3du je pre v\u00fdvoj\u00e1rov aplik\u00e1ci\u00ed d\u00f4le\u017eit\u00e1 a je potrebn\u00e9 sa o \u0148u stara\u0165.<\/p>\n

Krok 5: Pokrytie testovania k\u00f3du<\/h3>\n

\nImplement\u00e1cia testov m\u00f4\u017ee by\u0165 \u010fal\u0161\u00edm n\u00e1ro\u010dn\u00fdm po\u017eiadavkom, ale v\u00fdvoj\u00e1ri by mali zachyti\u0165 ak\u00e9ko\u013evek chyby v aplik\u00e1cii v ran\u00fdch f\u00e1zach a zlep\u0161i\u0165 kvalitu k\u00f3du, aby zabezpe\u010dili, \u017ee kone\u010dn\u00ed u\u017e\u00edvatelia bud\u00fa spokojn\u00ed. Na\u0161\u0165astie existuje mno\u017estvo n\u00e1strojov s otvoren\u00fdm zdrojov\u00fdm k\u00f3dom na testovanie v\u00e1\u0161ho k\u00f3du a na generovanie odpor\u00fa\u010dan\u00ed na zlep\u0161enie jeho kvality. E\u0161te lep\u0161ie je, \u017ee v\u00e4\u010d\u0161ina n\u00e1strojov CI\/CD sa m\u00f4\u017ee pripoji\u0165 k t\u00fdmto n\u00e1strojom a automatizova\u0165 proces.<\/p>\n

Testovanie k\u00f3du pozost\u00e1va z dvoch \u010dast\u00ed: r\u00e1mce na testovanie k\u00f3du, ktor\u00e9 pom\u00e1haj\u00fa p\u00edsa\u0165 a sp\u00fa\u0161\u0165a\u0165 testy, a n\u00e1stroje na generovanie n\u00e1vrhov, ktor\u00e9 pom\u00e1haj\u00fa zlep\u0161i\u0165 kvalitu k\u00f3du.<\/p>\n

Syst\u00e9my testovania k\u00f3du<\/b><\/p>\n

N\u00e1zov
\nLicencia
\nProgramovac\u00ed jazyk<\/p>\n

JUnit
\nEclipse Public License
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Syst\u00e9my odpor\u00fa\u010dan\u00ed na zlep\u0161enie k\u00f3du<\/b><\/p>\n

N\u00e1zov
\nLicencia
\nProgramovac\u00ed jazyk<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nCommon Public License
\nJava<\/p>\n

JaCoCo
\n Eclipse Public License
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

V\u0161imnite si, \u017ee v\u00e4\u010d\u0161ina n\u00e1strojov a r\u00e1mcov uveden\u00fdch vy\u0161\u0161ie je nap\u00edsan\u00e1 pre Java, Python a JavaScript, preto\u017ee C++ a C# s\u00fa propriet\u00e1rne programovacie jazyky (aj ke\u010f GCC m\u00e1 otvoren\u00fd zdrojov\u00fd k\u00f3d).<\/p>\n

Teraz, ke\u010f ste implementovali n\u00e1stroje na pokrytie k\u00f3du testami, mal by v\u00e1\u0161 DevOps pipeline vyzera\u0165 ako diagram zobrazen\u00fd na za\u010diatku tejto pr\u00edru\u010dky.<\/p>\n

\u010eal\u0161ie kroky<\/h3>\n

\nKontajnery<\/b><\/p>\n

Ako som u\u017e povedal, m\u00f4\u017eete hosti\u0165 svoj server na virtu\u00e1lnom stroji alebo servery, ale kontajnery s\u00fa popul\u00e1rnym rie\u0161en\u00edm.<\/p>\n

\u010co s\u00fa kontajnery? Stru\u010dn\u00e9 vysvetlenie je tak\u00e9, \u017ee virtu\u00e1lny stroj potrebuje obrovsk\u00e9 mno\u017estvo pam\u00e4te opera\u010dn\u00e9ho syst\u00e9mu, ktor\u00fd prevy\u0161uje ve\u013ekos\u0165 aplik\u00e1cie, zatia\u013e \u010do kontajner potrebuje len nieko\u013eko kni\u017en\u00edc a konfigur\u00e1ci\u00ed na spustenie aplik\u00e1cie. Je zrejm\u00e9, \u017ee virtu\u00e1lny stroj m\u00e1 st\u00e1le d\u00f4le\u017eit\u00e9 oblasti aplik\u00e1cie, ale kontajner je \u013eahk\u00e9 rie\u0161enie na hosting aplik\u00e1cie, vr\u00e1tane aplika\u010dn\u00e9ho servera.<\/p>\n

Aj ke\u010f existuj\u00fa aj in\u00e9 varianty kontajnerov, najpopul\u00e1rnej\u0161ie s\u00fa Docker a Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Prostredky automatiz\u00e1cie<\/b><\/p>\n

N\u00e1\u0161 DevOps pipeline je preva\u017ene zameran\u00fd na spolo\u010dn\u00e9 vytv\u00e1ranie a nasadzovanie aplik\u00e1ci\u00ed, ale existuje mno\u017estvo \u010fal\u0161\u00edch vec\u00ed, ktor\u00e9 mo\u017eno robi\u0165 pomocou DevOps n\u00e1strojov. Jednou z nich je pou\u017e\u00edvanie n\u00e1strojov Infrastructure as Code (IaC), ktor\u00e9 s\u00fa tie\u017e zn\u00e1me ako prostriedky medzi automatiz\u00e1ciou. Tieto n\u00e1stroje pom\u00e1haj\u00fa automatizova\u0165 in\u0161tal\u00e1ciu, spr\u00e1vu a \u010fal\u0161ie \u00falohy pre medziserverov\u00fd softv\u00e9r. Napr\u00edklad automatiza\u010dn\u00fd n\u00e1stroj m\u00f4\u017ee extrahova\u0165 aplik\u00e1cie ako server webov\u00fdch aplik\u00e1ci\u00ed, datab\u00e1zu a monitorovac\u00ed n\u00e1stroj s spr\u00e1vnymi konfigur\u00e1ciami a nasadi\u0165 ich na aplika\u010dnom serveri.<\/p>\n

Tu s\u00fa niektor\u00e9 n\u00e1stroje medzi automatiz\u00e1ciou s otvoren\u00fdm zdrojov\u00fdm k\u00f3dom:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache alebo GPL<\/p>\n

\"Pr\u00edru\u010dka<\/p>\n

Zistite podrobnosti, ako z\u00edska\u0165 po\u017eadovan\u00fa profesiu od nuly alebo si zlep\u0161ite zru\u010dnosti a plat absolvovan\u00edm platen\u00fdch online kurzov SkillFactory:<\/p>\n