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

Jeg vil gerne pr\u00e6sentere transkriptet af Alexander Sigachevs rapport fra Inventos \"Udviklings- og testprocessen med Docker + Gitlab CI\"<\/strong><\/p>\n

<\/p>\n

De, der lige er begyndt at implementere udviklings- og testprocessen baseret p\u00e5 Docker + Gitlab CI, stiller ofte grundl\u00e6ggende sp\u00f8rgsm\u00e5l. Hvor skal man starte? Hvordan organiserer man det? Hvordan tester man?<\/p>\n

<\/p>\n

Dette foredrag er v\u00e6rdifuldt, da det struktureret fort\u00e6ller om udvikling og test med brug af Docker og Gitlab CI. Selve foredraget er fra 2017. Jeg tror, at man kan hente grundl\u00e6ggende viden, metodologi, id\u00e9 og erfaring fra dette foredrag. <\/p>\n

\n

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

Hvis nogen er interesseret, s\u00e5 kom ind under kat. <\/a><\/noindex><\/p>\n

<\/p>\n

Mit navn er Alexander Sigachev. Jeg arbejder i virksomheden Inventos. Jeg vil fort\u00e6lle om min erfaring med Docker og hvordan vi langsomt implementerer det i projekter i virksomheden.<\/p>\n

<\/p>\n

Emnet for foredraget: Udviklingsprocessen med brug af Docker og Gitlab CI. <\/p>\n

<\/p>\n

\"Udviklings-<\/p>\n

<\/p>\n

Dette er mit andet foredrag om Docker. P\u00e5 tidspunktet for det f\u00f8rste foredrag brugte vi Docker kun i udviklingen p\u00e5 udviklernes maskiner. Antallet af medarbejdere, der brugte Docker, var omkring 2-3 personer. Gradvis har vi opn\u00e5et erfaring, og vi er kommet lidt videre. Link til vores f\u00f8rste foredrag<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hvad vil der v\u00e6re i dette foredrag? Vi vil dele vores erfaring omkring hvilke udfordringer vi har samlet, hvilke problemer vi har l\u00f8st. Det har ikke altid v\u00e6ret smukt, men det har gjort det muligt at komme videre.<\/p>\n

<\/p>\n

Vores motto: dockeriser alt, hvad vores h\u00e6nder r\u00e6kker ud efter.<\/p>\n

<\/p>\n

\"Udviklings-<\/p>\n

<\/p>\n

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

<\/p>\n

N\u00e5r der er flere teams i virksomheden, er programm\u00f8ren en delt ressource. Der er tidspunkter, hvor programm\u00f8ren tr\u00e6kkes ud af et projekt og gives til et andet projekt i en periode.<\/p>\n

<\/p>\n

For at programm\u00f8ren hurtigt kan s\u00e6tte sig ind i det, er det n\u00f8dvendigt at downloade koden fra projektet og s\u00e5 hurtigt som muligt starte et milj\u00f8, der g\u00f8r det muligt for ham at forts\u00e6tte med at l\u00f8se opgaverne i dette projekt.<\/p>\n

<\/p>\n

Normalt, hvis man starter fra bunden, er der ikke meget dokumentation i projektet. Oplysninger om, hvordan man konfigurerer, findes kun hos de erfarne. Medarbejdere ops\u00e6tter selv deres arbejdsplads p\u00e5 en til to dage. For at fremskynde dette har vi anvendt Docker.<\/p>\n

<\/p>\n

Den n\u00e6ste \u00e5rsag er standardiseringen af indstillinger i udviklingen. Efter min erfaring tager udviklerne altid initiativ. I hver femte sag introduceres et brugerdefineret dom\u00e6ne, for eksempel vasya.dev. Ved siden af sidder naboen Petja, der har dom\u00e6net petya.dev. De udvikler en hjemmeside eller et systemkomponent ved at bruge dette dom\u00e6nenavn.<\/p>\n

<\/p>\n

N\u00e5r systemet vokser, og disse dom\u00e6nenavne begynder at komme ind i konfigurationerne, opst\u00e5r der konflikter i udviklingsmilj\u00f8erne, og stien til hjemmesiden bliver overskrevet.<\/p>\n

<\/p>\n

Det samme sker med databaseindstillingerne. Nogen t\u00e6nker ikke over sikkerheden og arbejder med root-adgangskoden som tom. For nogen, da MySQL blev installeret, blev der kr\u00e6vet en adgangskode, og den viste sig at v\u00e6re 123. Det sker ofte, at databasekonfigurationen konstant bliver \u00e6ndret afh\u00e6ngigt af udviklerens commit. Nogen har rettet det, nogen har ikke rettet konfigureringen. Der var tricks, hvor vi tog en testkonfiguration og .gitignore<\/code> hver udvikler skulle installere databasen. Det gjorde opstartsprocessen mere kompliceret. Udover alt andet skal man huske p\u00e5 databasen. Databasen skal initialiseres, adgangskoden skal angives, brugeren skal angives, tabellen skal oprettes og s\u00e5 videre.<\/p>\n

<\/p>\n

En anden af problemerne er de forskellige versioner af bibliotekerne. Det sker ofte, at udvikleren arbejder med forskellige projekter. Der er et Legacy-projekt, som blev p\u00e5begyndt for fem \u00e5r siden (fra 2017 \u2014 bem\u00e6rk red.). P\u00e5 tidspunktet for starten, blev der startet med MySQL 5.5. Der er ogs\u00e5 moderne projekter, hvor vi fors\u00f8ger at implementere mere moderne versioner af MySQL, for eksempel 5.7 eller nyere (i 2017 \u2014 bem\u00e6rk red.).<\/p>\n

<\/p>\n

Den, der arbejder med MySQL, ved, at disse biblioteker medf\u00f8rer afh\u00e6ngigheder. Det er ret problematisk at k\u00f8re to databaser sammen. I det mindste er det problematisk at forbinde gamle klienter til den nye database. Dette skaber i sin tur flere problemer.<\/p>\n

<\/p>\n

Det n\u00e6ste problem er, at n\u00e5r udvikleren arbejder p\u00e5 sin lokale maskine, bruger han lokale ressourcer, lokale filer, lokal RAM. Al interaktion under udviklingen af l\u00f8sningen foreg\u00e5r inden for rammerne af, at det k\u00f8rer p\u00e5 \u00e9n maskine. Et eksempel kunne v\u00e6re, n\u00e5r vi har 3 backend-servere i produktion, og udvikleren gemmer filer i roden, som nginx henter for at svare p\u00e5 foresp\u00f8rgsler. N\u00e5r s\u00e5dan en kode g\u00e5r i produktion, f\u00e5r vi, at filen kun er tilg\u00e6ngelig p\u00e5 en af de 3 servere.<\/p>\n

<\/p>\n

I \u00f8jeblikket udvikles retningen mod mikrotjenester. N\u00e5r vi opdeler vores store applikationer i mindre komponenter, der interagerer med hinanden. Dette muligg\u00f8r at v\u00e6lge teknologier specifikt til den givne opgave. Det g\u00f8r ogs\u00e5, at arbejdet og ansvarsomr\u00e5derne kan opdeles blandt udviklerne.<\/p>\n

<\/p>\n

Frontend-udvikleren, der udvikler i JS, p\u00e5virker praktisk talt ikke Backend. Backend-udvikleren udvikler i vores tilf\u00e6lde Ruby on Rails og forstyrrer ikke Frontend. Interaktionen sker via API.<\/p>\n

<\/p>\n

Som en bonus har vi ved hj\u00e6lp af Docker v\u00e6ret i stand til at optimere ressourcerne p\u00e5 Staging. Hver projekt kr\u00e6ver bestemte indstillinger p\u00e5 grund af sin specifik. Fysisk skulle der allokeres enten en virtuel server, der skulle konfigureres hver for sig, eller man skulle dele et n\u00e6rt milj\u00f8, og projekterne kunne p\u00e5virke hinanden afh\u00e6ngigt af versionerne af bibliotekerne.<\/p>\n

<\/p>\n

\"Udviklings-<\/p>\n

<\/p>\n

V\u00e6rkt\u00f8jer. Hvad bruger vi? <\/p>\n

<\/p>\n