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

Jag f\u00f6resl\u00e5r att ni bekantar er med transkriptionen av Alexander Sigachevs rapport fr\u00e5n Inventos \"Processen f\u00f6r utveckling och testning med Docker + Gitlab CI\"<\/strong><\/p>\n

<\/p>\n

De som just har b\u00f6rjat implementera utvecklings- och testprocessen baserad p\u00e5 Docker + Gitlab CI st\u00e4ller ofta grundl\u00e4ggande fr\u00e5gor. Hur ska man b\u00f6rja? Hur ska man organisera det? Hur ska man testa?<\/p>\n

<\/p>\n

Detta f\u00f6redrag \u00e4r bra eftersom det strukturerat beskriver utvecklings- och testprocessen med hj\u00e4lp av Docker och Gitlab CI. Sj\u00e4lva f\u00f6redraget \u00e4r fr\u00e5n 2017. Jag tror att man kan h\u00e4mta grundl\u00e4ggande principer, metodik, id\u00e9er och erfarenheter fr\u00e5n detta f\u00f6redrag. <\/p>\n

\n

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

Den som \u00e4r intresserad, v\u00e4nligen l\u00e4s vidare. <\/a><\/noindex><\/p>\n

<\/p>\n

Jag heter Alexander Sigachev. Jag arbetar p\u00e5 f\u00f6retaget Inventos. Jag kommer att ber\u00e4tta om min erfarenhet av att anv\u00e4nda Docker och hur vi gradvis implementerar det i v\u00e5ra projekt.<\/p>\n

<\/p>\n

\u00c4mnet f\u00f6r f\u00f6redraget: Utvecklingsprocessen med anv\u00e4ndning av Docker och Gitlab CI. <\/p>\n

<\/p>\n

\"Utvecklings-<\/p>\n

<\/p>\n

Detta \u00e4r mitt andra f\u00f6redrag om Docker. Vid tidpunkten f\u00f6r det f\u00f6rsta f\u00f6redraget anv\u00e4nde vi Docker endast i utveckling p\u00e5 utvecklarnas maskiner. Antalet anst\u00e4llda som anv\u00e4nde Docker var ungef\u00e4r 2-3 personer. Successivt har vi samlat erfarenhet och gjort sm\u00e5 framsteg. L\u00e4nk till v\u00e5rt f\u00f6rsta f\u00f6redrag<\/a><\/noindex>.<\/p>\n

<\/p>\n

Vad kommer att tas upp i detta f\u00f6redrag? Vi kommer att dela med oss av erfarenheter kring de fallgropar vi har st\u00f6tt p\u00e5, vilka problem vi har l\u00f6st. Det var inte alltid vackert, men det har till\u00e5tit oss att g\u00e5 vidare.<\/p>\n

<\/p>\n

V\u00e5r slogan: dockerisera allt vi kommer \u00e5t.<\/p>\n

<\/p>\n

\"Utvecklings-<\/p>\n

<\/p>\n

Vilka problem l\u00f6ser vi?<\/p>\n

<\/p>\n

N\u00e4r det finns flera team i f\u00f6retaget s\u00e5 \u00e4r programmeraren en delad resurs. Det finns faser n\u00e4r en programmerare dras ut fr\u00e5n ett projekt och tillf\u00e4lligt ges till ett annat projekt.<\/p>\n

<\/p>\n

F\u00f6r att en programmerare snabbt ska kunna s\u00e4tta sig in i projektet beh\u00f6ver hen ladda ner projektets k\u00e4llkod och s\u00e5 snabbt som m\u00f6jligt starta en milj\u00f6 som g\u00f6r att hen kan forts\u00e4tta och l\u00f6sa uppgifterna i det aktuella projektet.<\/p>\n

<\/p>\n

Vanligtvis, om man b\u00f6rjar fr\u00e5n b\u00f6rjan, finns det lite dokumentation i projektet. Informationen om hur man konfigurerar finns endast hos veteranerna. Anst\u00e4llda st\u00e4ller oftast in sin arbetsplats p\u00e5 en eller tv\u00e5 dagar. F\u00f6r att snabba upp detta har vi anv\u00e4nt Docker.<\/p>\n

<\/p>\n

Den n\u00e4sta anledningen \u00e4r standardisering av inst\u00e4llningar i Development. Utifr\u00e5n min erfarenhet visar utvecklarna alltid initiativ. I vart femte fall inf\u00f6rs en anpassad dom\u00e4n, som vasya.dev. Bredvid sitter grannen Petya, som har dom\u00e4nen petya.dev. De utvecklar en webbplats eller n\u00e5gon komponent av systemet med hj\u00e4lp av detta dom\u00e4nnamn.<\/p>\n

<\/p>\n

N\u00e4r systemet v\u00e4xer och dessa dom\u00e4nnamn b\u00f6rjar dyka upp i konfigurationerna, uppst\u00e5r det en konflikt i Development-milj\u00f6er och s\u00f6kv\u00e4gen till webbplatsen skrivs om.<\/p>\n

<\/p>\n

Detsamma h\u00e4nder med inst\u00e4llningarna f\u00f6r databasen. N\u00e5gon bekymrar sig inte f\u00f6r s\u00e4kerheten och arbetar med ett tomt root-l\u00f6senord. N\u00e5gon annan, vid installationen av MySQL, kr\u00e4vdes l\u00f6senord och det blev 123. Det h\u00e4nder ofta att databasens konfiguration st\u00e4ndigt \u00e4ndras beroende p\u00e5 utvecklarens commit. N\u00e5gon har fixat, n\u00e5gon har inte fixat konfigurationen. Det fanns knep f\u00f6r att vi tog ut en testkonfiguration i .gitignore<\/code> och varje utvecklare var tvungen att installera databasen. Det f\u00f6rsv\u00e5rade startprocessen. F\u00f6rutom allt annat m\u00e5ste man komma ih\u00e5g databasen. Databasen beh\u00f6ver initieras, man m\u00e5ste ange l\u00f6senord, man m\u00e5ste ange anv\u00e4ndare, skapa tabeller och s\u00e5 vidare.<\/p>\n

<\/p>\n

Ett annat problem \u00e4r olika versioner av bibliotek. Det \u00e4r ofta s\u00e5 att utvecklaren arbetar med olika projekt. Det finns ett Legacy-projekt som startades f\u00f6r fem \u00e5r sedan (fr\u00e5n 2017 - anm. red.). Vid starten anv\u00e4nde vi MySQL 5.5. Det finns \u00e4ven moderna projekt d\u00e4r vi str\u00e4var efter att inf\u00f6ra mer moderna versioner av MySQL, till exempel 5.7 eller senare (fr\u00e5n 2017 - anm. red.)<\/p>\n

<\/p>\n

Den som arbetar med MySQL vet att dessa bibliotek tar med sig beroenden. Det \u00e4r ganska problematiskt att k\u00f6ra tv\u00e5 databaser samtidigt. \u00c5tminstone \u00e4r det problematiskt att f\u00e5 gamla kunder att ansluta till den nya databasen. Detta ger i sin tur upphov till flera problem.<\/p>\n

<\/p>\n

Ett vanligt problem \u00e4r n\u00e4r utvecklaren arbetar p\u00e5 en lokal maskin och anv\u00e4nder lokala resurser, lokala filer och lokalt RAM. All interaktion under utvecklingen av l\u00f6sningar sker p\u00e5 grundval av att allt fungerar p\u00e5 en och samma maskin. Ett exempel kan vara n\u00e4r vi har tre backend-servrar i produktion, men utvecklaren sparar filer i rotkatalogen och d\u00e4rifr\u00e5n h\u00e4mtar nginx filerna f\u00f6r att svara p\u00e5 f\u00f6rfr\u00e5gningar. N\u00e4r denna kod hamnar i produktion, visar det sig att filen finns p\u00e5 en av de tre servrarna.<\/p>\n

<\/p>\n

F\u00f6r n\u00e4rvarande utvecklas mikrotj\u00e4nster. N\u00e4r vi delar upp v\u00e5ra stora applikationer i mindre komponenter som interagerar med varandra. Detta g\u00f6r det m\u00f6jligt att v\u00e4lja teknologier specifikt f\u00f6r den uppgiftstablett. Det g\u00f6r det ocks\u00e5 m\u00f6jligt att dela arbete och ansvarsomr\u00e5den mellan utvecklarna.<\/p>\n

<\/p>\n

En frontend-utvecklare, som utvecklar i JS, p\u00e5verkar i stort sett inte backend. Backend-utvecklaren arbetar i sin tur med Ruby on Rails i v\u00e5rt fall och st\u00f6r inte frontend. Interaktionen sker via API.<\/p>\n

<\/p>\n

Som en bonus har vi kunnat optimera resurser p\u00e5 Staging med hj\u00e4lp av Docker. Varje projekt kr\u00e4vde p\u00e5 grund av sin specifika karakt\u00e4r vissa inst\u00e4llningar. Fysiskt beh\u00f6vdes det antingen att avs\u00e4tta en virtuell server och konfigurera den separat, eller att dela n\u00e5gra tillf\u00e4lliga milj\u00f6er, och projekten kunde p\u00e5verka varandra beroende p\u00e5 versionerna av biblioteken.<\/p>\n

<\/p>\n

\"Utvecklings-<\/p>\n

<\/p>\n

Verktyg. Vad anv\u00e4nder vi? <\/p>\n

<\/p>\n