{"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\/no\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Utviklings- og testprosess med Docker og Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Eg tilbyr ei oversikt over utgreiinga av rapporten fr\u00e5 Aleksandr Sigachev fr\u00e5 Inventos \u00abUtviklings- og testprosess med Docker + Gitlab CI\u00bb<\/strong><\/p>\n

<\/p>\n

De som nettopp begynner \u00e5 implementere utviklings- og testprosessen basert p\u00e5 Docker + Gitlab CI har ofte grunnleggende sp\u00f8rsm\u00e5l. Hvor skal man begynne? Hvordan organisere? Hvordan teste?<\/p>\n

<\/p>\n

Denne rapporten er god fordi den systematisk forklarer utviklings- og testprosessen ved bruk av Docker og Gitlab CI. Selve rapporten er fra 2017. Jeg tror man kan hente ut grunnleggende prinsipper, metodologi, ideer og erfaring fra denne rapporten. <\/p>\n

\n

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

De som er interessert, vennligst klikk her. <\/a><\/noindex><\/p>\n

<\/p>\n

Jeg heter Alexander Sigachev. Jeg jobber i selskapet Inventos. Jeg vil fortelle om min erfaring med \u00e5 bruke Docker og hvordan vi gradvis implementerer det i prosjektene v\u00e5re.<\/p>\n

<\/p>\n

Temaet for rapporten: Utviklingsprosess med bruk av Docker og Gitlab CI. <\/p>\n

<\/p>\n

\"Utviklings-<\/p>\n

<\/p>\n

Dette er min andre rapport om Docker. P\u00e5 tidspunktet for den f\u00f8rste rapporten brukte vi Docker kun i utviklingsmilj\u00f8ene til utviklerne. Antallet ansatte som brukte Docker var rundt 2-3 personer. Erfaring har blitt opparbeidet gradvis, og vi har gjort noen fremskritt. Lenke til v\u00e5r f\u00f8rste rapport<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hva vil vi dekke i denne rapporten? Vi vil dele erfaringer om hvilke problemer vi har st\u00f8tt p\u00e5 og hvordan vi l\u00f8ste dem. Det var ikke alltid pent, men det tillot oss \u00e5 komme videre.<\/p>\n

<\/p>\n

V\u00e5rt motto: dockeriser alt vi kommer i kontakt med.<\/p>\n

<\/p>\n

\"Utviklings-<\/p>\n

<\/p>\n

Hvilke problemer l\u00f8ser vi?<\/p>\n

<\/p>\n

N\u00e5r det er flere team i selskapet, er programmereren en delt ressurs. Det kan v\u00e6re faser der programmereren blir hentet fra ett prosjekt og midlertidig flyttet til et annet prosjekt.<\/p>\n

<\/p>\n

For at programmereren raskt skal sette seg inn i prosjektet, m\u00e5 han laste ned koden og f\u00e5 opp et milj\u00f8 s\u00e5 raskt som mulig som lar ham fortsette med \u00e5 l\u00f8se oppgavene i dette prosjektet.<\/p>\n

<\/p>\n

Vanligvis, hvis man starter fra bunnen av, er dokumentasjonen i prosjektet sparsom. Informasjon om hvordan man konfigurerer, finnes kun hos de erfarne. Ansatte setter vanligvis opp arbeidsplassen sin p\u00e5 en til to dager. For \u00e5 akselerere dette har vi brukt Docker.<\/p>\n

<\/p>\n

Den neste grunnen er standardisering av innstillinger i Development. Etter min erfaring viser utviklere alltid initiativ. I hvert femte tilfelle blir det introdusert et egendefinert domene, for eksempel vasya.dev. Ved siden av sitter naboen Petja, som har domenet petya.dev. De utvikler et nettsted eller en del av systemet ved \u00e5 bruke dette domenet.<\/p>\n

<\/p>\n

N\u00e5r systemet vokser og disse domenene begynner \u00e5 komme inn i konfigurasjonene, oppst\u00e5r det konflikt i Development-milj\u00f8ene, og nettstedets bane blir overskrevet.<\/p>\n

<\/p>\n

Det samme skjer med databasinnstillingene. Noen tenker ikke p\u00e5 sikkerhet og jobber med et tomt root-passord. Noen ganger krever MySQL-passordet under installasjonen et passord, og det blir et enkelt 123. Det skjer ofte at databasekonfigurasjonen stadig blir endret avhengig av utviklerens commit. Noen korrigerer, noen glemmer \u00e5 rette opp konfigurasjonen. Det var underlige l\u00f8sninger der vi flyttet en testkonfigurasjon til .gitignore<\/code> og hver utvikler m\u00e5tte installere databasen. Dette kompliserte oppstartsprosessen. I tillegg til alt annet, m\u00e5 man huske p\u00e5 databasen. Databasen m\u00e5 initialiseres, man m\u00e5 oppgi passord, oppgi bruker, opprette en tabell og s\u00e5 videre.<\/p>\n

<\/p>\n

Et annet problem er forskjellige versjoner av biblioteker. Det skjer ofte at utviklerne jobber med forskjellige prosjekter. Det er et Legacy-prosjekt som ble startet for fem \u00e5r siden (fra 2017 \u2014 red. anm.). Ved starten ble det startet med MySQL 5.5. Det finnes ogs\u00e5 moderne prosjekter, der vi pr\u00f8ver \u00e5 implementere mer moderne versjoner av MySQL, for eksempel 5.7 eller eldre (i 2017 \u2014 red. anm.)<\/p>\n

<\/p>\n

De som jobber med MySQL vet at disse bibliotekene drar med seg avhengigheter. Det er ganske problematisk \u00e5 kj\u00f8re 2 databaser sammen. I hvert fall er det problematisk \u00e5 koble gamle kunder til en ny database. Dette f\u00f8rer i sin tur til flere problemer.<\/p>\n

<\/p>\n

Det neste problemet er n\u00e5r utvikleren jobber p\u00e5 en lokal maskin, bruker lokale ressurser, lokale filer, lokal RAM. All interaksjon under utviklingen av l\u00f8sningen skjer innenfor rammen av at det fungerer p\u00e5 \u00e9n maskin. Et eksempel kan v\u00e6re n\u00e5r vi har 3 backend-servere i produksjon, og utvikleren lagrer filer i rotkatalogen, og derfra henter nginx filer for \u00e5 svare p\u00e5 anrop. N\u00e5r slik kode g\u00e5r i produksjon, viser det seg at filen finnes p\u00e5 en av de 3 serverne.<\/p>\n

<\/p>\n

N\u00e5 utvikles feltet mikroservices. N\u00e5r vi deler v\u00e5re store applikasjoner inn i mindre komponenter som interagerer med hverandre. Dette lar oss velge teknologier i henhold til spesifikke oppgaver. Det gj\u00f8r det ogs\u00e5 mulig \u00e5 dele arbeidet og ansvarsomr\u00e5dene mellom utviklerne.<\/p>\n

<\/p>\n

Frontend-utvikleren, ved \u00e5 utvikle p\u00e5 JS, p\u00e5virker praktisk talt ikke backend. Backend-utvikleren, i v\u00e5rt tilfelle, utvikler Ruby on Rails og forstyrrer ikke frontend. Interaksjonen skjer ved hjelp av API.<\/p>\n

<\/p>\n

Som en bonus har vi med Docker klart \u00e5 utnytte ressursene p\u00e5 Staging. Hvert prosjekt krever sine spesifikke innstillinger p\u00e5 grunn av sin natur. Fysisk m\u00e5tte vi tildele enten \u00e9n virtuell server og konfigurere dem separat, eller dele et variabelt milj\u00f8, og prosjektene kunne, avhengig av versjonen av bibliotekene, p\u00e5virke hverandre.<\/p>\n

<\/p>\n

\"Utviklings-<\/p>\n

<\/p>\n

Verkt\u00f8y. Hva bruker vi? <\/p>\n

<\/p>\n