{"id":32526,"date":"2019-10-31T21:47:32","date_gmt":"2019-10-31T18:47:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci\/"},"modified":"2019-10-31T21:47:32","modified_gmt":"2019-10-31T18:47:32","slug":"protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Postopek razvoja in testiranja z Docker in Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Predlagam, da se seznanite s transkripcijo poro\u010dila Alexandera Sigacheva iz Inventos \u201ePostopek razvoja in testiranja s Docker + Gitlab CI\u201c<\/strong><\/p>\n

<\/p>\n

Tisti, ki \u0161ele za\u010denjajo uvajati postopek razvoja in testiranja na osnovi Docker + Gitlab CI, pogosto postavljajo osnovna vpra\u0161anja. Kje za\u010deti? Kako organizirati? Kako testirati?<\/p>\n

<\/p>\n

To poro\u010dilo je dobro, ker strukturirano opisuje postopek razvoja in testiranja z uporabo Docker in Gitlab CI. Samo poro\u010dilo je iz leta 2017. Mislim, da lahko iz tega poro\u010dila pridobite osnove, metodologijo, idejo, izku\u0161nje z uporabo. <\/p>\n

\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Kdor je zainteresiran, naj se preseli pod kat. <\/a><\/noindex><\/p>\n

<\/p>\n

Moje ime je Aleksandr Siga\u010dev. Delam v podjetju Inventos. Povedal bom o svojih izku\u0161njah z uporabo Dockerja in o tem, kako ga postopoma uvajamo v projekte v podjetju.<\/p>\n

<\/p>\n

Tema poro\u010dila: Postopek razvoja z uporabo Docker in Gitlab CI. <\/p>\n

<\/p>\n

\"Postopek<\/p>\n

<\/p>\n

To je moje drugo poro\u010dilo o Dockerju. Ob \u010dasu prvega poro\u010dila smo uporabljali Docker zgolj v razvoju na ra\u010dunalnikih razvijalcev. \u0160tevilo zaposlenih, ki so uporabljali Docker, je bilo okoli 2-3 osebe. Postopoma smo pridobili izku\u0161nje in nekoliko napredovali. Povezava na na\u0161e prvo poro\u010dilo<\/a><\/noindex>.<\/p>\n

<\/p>\n

Kaj bo v tem poro\u010dilu? Delili bomo izku\u0161nje o tem, katere pasti smo naleteli, kako smo re\u0161evali te\u017eave. Ni vedno potekalo gladko, a nam je omogo\u010dilo, da smo napredovali.<\/p>\n

<\/p>\n

Na\u0161a deviza: dockeriziraj vse, do \u010desar lahko pridemo.<\/p>\n

<\/p>\n

\"Postopek<\/p>\n

<\/p>\n

Katere te\u017eave re\u0161ujemo?<\/p>\n

<\/p>\n

Ko je v podjetju ve\u010d ekip, je programer deljena sredstva. V\u010dasih pride do faz, ko programerja preusmerijo iz enega projekta na drugega za dolo\u010den \u010das.<\/p>\n

<\/p>\n

Da se programer hitro vklju\u010di, mora prenesti izvorno kodo projekta in \u010dim hitreje zagnati okolje, ki mu omogo\u010da nadaljnje napredovanje pri re\u0161evanju nalog tega projekta.<\/p>\n

<\/p>\n

Obi\u010dajno, \u010de za\u010dnemo od za\u010detka, je dokumentacije v projektu malo. Informacije o tem, kako nastaviti, ima samo nekaj starej\u0161ih uslu\u017ebencev. Zaposleni si obi\u010dajno nastavijo svoje delovno mesto v enem do dveh dneh. Da bi to pospe\u0161ili, smo uporabili Docker.<\/p>\n

<\/p>\n

Naslednji razlog \u2014 standardizacija nastavitev v razvoju. Po mojem mnenju razvijalci vedno izra\u017eajo pobudo. V vsakem petem primeru se uvede po meri prirejen domen, na primer vasja.dev. Ob njem je sosed Petja, ki ima domeno petja.dev. Razvijajo spletno mesto ali nek komponent sistema, ki uporablja to domeno.<\/p>\n

<\/p>\n

Ko se sistem raz\u0161iri in ta imena domen za\u010dnejo prihajati v konfiguracije, nastane konflikt razvojnih okolij in pot do spletne strani se prepisuje.<\/p>\n

<\/p>\n

Enako se dogaja z nastavitvami baze podatkov. Nekdo ne posve\u010da pozornosti varnosti in dela s praznim geslom za root. Drugemu je med namestitvijo MySQL geslo povzro\u010dilo zahtevo in ugotovil je, da je geslo 123. Pogosto se zgodi, da se konfiguracija baze podatkov neprestano spreminja glede na commit razvijalca. Nekdo je popravljen, nekdo ni. Bili so triki, ko smo prenesli neko testno konfiguracijo v .gitignore<\/code> in vsak razvijalec je moral namestiti bazo podatkov. To je ote\u017eilo postopek pri zagonu. Poleg vsega je treba pomisliti tudi na bazo podatkov. Bazo podatkov je treba inicializirati, vnesti geslo, vnesti uporabnika, ustvariti tabelo in tako naprej.<\/p>\n

<\/p>\n

\u0160e ena te\u017eava so razli\u010dne razli\u010dice knji\u017enic. Pogosto se zgodi, da razvijalec dela na razli\u010dnih projektih. Obstaja projekt z dedovanjem, ki smo ga za\u010deli pred petimi leti (od 2017 \u2014 opomba uredni\u0161tva). Ob za\u010detku smo za\u010deli z MySQL 5.5. Obstajajo tudi sodobni projekti, kjer se trudimo vpeljati novej\u0161e razli\u010dice MySQL, na primer 5.7 ali starej\u0161e (v 2017 \u2014 opomba uredni\u0161tva).<\/p>\n

<\/p>\n

Tisti, ki dela z MySQL, ve, da te knji\u017enice prina\u0161ajo s sabo odvisnosti. Zagon dveh baz skupaj je precej zapleten. Vsaj stari odjemalci se te\u017eko pove\u017eejo z novo bazo podatkov. To pa povzro\u010da ve\u010d te\u017eav.<\/p>\n

<\/p>\n

Naslednja te\u017eava je, ko razvijalec dela na lokalnem ra\u010dunalniku, uporablja lokalne vire, lokalne datoteke, lokalni RAM. Vse interakcije med razvojem re\u0161itev potekajo v okviru delovanja na enem ra\u010dunalniku. Primer je, ko imamo v produkciji 3 backend stre\u017enike, razvijalec pa shranjuje datoteke v korenski imenik in od tam nginx pridobiva datoteke za odgovore na zahteve. Ko tak\u0161na koda pride v produkcijo, se izka\u017ee, da je datoteka prisotna na enem od treh stre\u017enikov.<\/p>\n

<\/p>\n

Trenutno se razvija pravac mikroservisa. Kada delimo na\u0161e velike aplikacije na manje komponente koje me\u0111usobno komuniciraju. To omogu\u0107ava da se za odre\u0111eni skup zadataka izaberu tehnologije. Tako\u0111e, to omogu\u0107ava podelu rada i odgovornosti me\u0111u programerima.<\/p>\n

<\/p>\n

Frontend programer, rade\u0107i na JS-u, prakti\u010dno ne uti\u010de na Backend. Backend programer, s druge strane, razvija, u na\u0161em slu\u010daju, Ruby on Rails i ne ometa Frontend. Interakcija se ostvaruje putem API-ja.<\/p>\n

<\/p>\n

Kao bonus, pomo\u0107u Dockera uspeli smo da optimizujemo resurse na Staging-u. Svaki projekat, s obzirom na svoju specifi\u010dnost, zahtevao je odre\u0111ena pode\u0161avanja. Fizi\u010dki je bilo potrebno odvojiti ili po jedan virtualni server i posebno ih konfigurisati, ili deliti neko promenljivo okru\u017eenje, a projekti su mogli zavisiti jedni od drugih u zavisnosti od verzije biblioteka.<\/p>\n

<\/p>\n

\"Postopek<\/p>\n

<\/p>\n

Alati. \u0160ta koristimo? <\/p>\n

<\/p>\n