{"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\/it\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Processo di sviluppo e test con Docker e Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ti invitiamo a prendere visione della trascrizione della relazione di Alexander Sigachev di Inventos \"Il processo di sviluppo e testing con Docker + Gitlab CI\"<\/strong><\/p>\n

<\/p>\n

Coloro che iniziano a implementare il processo di sviluppo e testing basato su Docker + Gitlab CI spesso pongono domande fondamentali. Da dove iniziare? Come organizzare? Come testare?<\/p>\n

<\/p>\n

Questa relazione \u00e8 interessante perch\u00e9 descrive in modo strutturato il processo di sviluppo e testing utilizzando Docker e Gitlab CI. La relazione risale al 2017. Penso che si possano trarre da essa le basi, la metodologia, l'idea e le esperienze di utilizzo. <\/p>\n

\n

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

Chi \u00e8 interessato, prego di proseguire. <\/a><\/noindex><\/p>\n

<\/p>\n

Mi chiamo Aleksandr Sigacev. Lavoro per l'azienda Inventos. Condivider\u00f2 la mia esperienza nell'uso di Docker e come gradualmente lo stiamo implementando nei progetti dell'azienda.<\/p>\n

<\/p>\n

Tema della relazione: Il processo di sviluppo utilizzando Docker e Gitlab CI. <\/p>\n

<\/p>\n

\"Processo<\/p>\n

<\/p>\n

Questa \u00e8 la mia seconda relazione su Docker. Al momento della prima relazione, usavamo Docker solo in sviluppo sulle macchine degli sviluppatori. Il numero di dipendenti che utilizzavano Docker era di circa 2-3 persone. Gradualmente abbiamo accumulato esperienza e siamo progrediti. Ecco il link alla nostra prima relazione<\/a><\/noindex>.<\/p>\n

<\/p>\n

Cosa ci sar\u00e0 in questa relazione? Condivideremo le esperienze su quali ostacoli abbiamo incontrato e come abbiamo risolto i problemi. Non sempre \u00e8 stato semplice, ma ci ha permesso di andare avanti.<\/p>\n

<\/p>\n

Il nostro motto: dockerizza tutto ci\u00f2 che riusciamo a toccare.<\/p>\n

<\/p>\n

\"Processo<\/p>\n

<\/p>\n

Quali problemi risolviamo?<\/p>\n

<\/p>\n

Quando in un'azienda ci sono pi\u00f9 team, il programmatore diventa una risorsa condivisa. Ci sono fasi in cui il programmatore viene estratto da un progetto e assegnato per un certo periodo a un altro progetto.<\/p>\n

<\/p>\n

Per consentire al programmatore di orientarsi rapidamente, \u00e8 necessario che scarichi il codice sorgente del progetto e avvii il pi\u00f9 velocemente possibile un ambiente che gli permetta di avanzare risolvendo le attivit\u00e0 di quel progetto.<\/p>\n

<\/p>\n

Di solito, se si inizia da zero, la documentazione nel progetto \u00e8 scarsa. Le informazioni su come configurare sono disponibili solo per i veterani. I dipendenti configurano autonomamente il proprio posto di lavoro in uno o due giorni. Per velocizzare questo processo, abbiamo utilizzato Docker.<\/p>\n

<\/p>\n

Un altro motivo \u00e8 la standardizzazione delle configurazioni in sviluppo. Dalla mia esperienza, gli sviluppatori sono sempre proattivi. In ogni quinto caso viene introdotto un dominio personalizzato, ad esempio vasya.dev. Vicino c'\u00e8 l'amico Petya, che ha il dominio petya.dev. Sviluppano un sito o un componente del sistema utilizzando questo nome di dominio.<\/p>\n

<\/p>\n

Quando il sistema cresce e questi nomi di dominio iniziano a comparire nelle configurazioni, sorge un conflitto negli ambienti di sviluppo e il percorso del sito viene riscritto.<\/p>\n

<\/p>\n

Lo stesso accade con le impostazioni del database. Alcuni non si preoccupano della sicurezza e lavorano con una password root vuota. Qualcuno, durante l'installazione, ha richiesto una password MySQL e si \u00e8 rivelata 123. Spesso accade che la configurazione del database cambi continuamente a seconda del commit dello sviluppatore. Qualcuno l'ha corretta, qualcun altro no. Ci sono stati artifici quando abbiamo estratto una configurazione di test in .gitignore<\/code> e ogni sviluppatore doveva installare il database. Questo complicava il processo di partenza. Oltre a tutto il resto, \u00e8 necessario tenere a mente il database. Il database deve essere inizializzato, \u00e8 necessario specificare la password, \u00e8 necessario specificare l'utente, creare una tabella e cos\u00ec via.<\/p>\n

<\/p>\n

Un altro problema \u00e8 rappresentato dalle diverse versioni delle librerie. Spesso succede che uno sviluppatore lavori su diversi progetti. C'\u00e8 un progetto Legacy, iniziato cinque anni fa (dal 2017 \u2013 nota dell'editore). All'inizio si part\u00ec con MySQL 5.5. Ci sono anche progetti moderni in cui tentiamo di implementare versioni MySQL pi\u00f9 recenti, come 5.7 o superiori (nel 2017 \u2013 nota dell'editore).<\/p>\n

<\/p>\n

Chi lavora con MySQL sa che queste librerie portano con s\u00e9 delle dipendenze. \u00c8 abbastanza problematico far funzionare insieme 2 database. Almeno, \u00e8 problematico collegare vecchi client a un nuovo database. Questo genera a sua volta diversi problemi.<\/p>\n

<\/p>\n

Il problema successivo \u00e8 quando lo sviluppatore lavora su una macchina locale, utilizza risorse locali, file locali, RAM locale. Tutta l'interazione durante lo sviluppo delle soluzioni avviene nell'ambito del funzionamento su una sola macchina. Un esempio pu\u00f2 essere quando abbiamo in produzione 3 server backend, mentre lo sviluppatore salva i file nella cartella radice e nginx prende i file da l\u00ec per rispondere alle richieste. Quando questo codice arriva in produzione, si scopre che il file \u00e8 presente su uno dei 3 server.<\/p>\n

<\/p>\n

Attualmente si sta sviluppando la direzione dei microservizi. Quando dividiamo le nostre grandi applicazioni in piccole componenti che interagiscono tra loro. Questo consente di scegliere le tecnologie specifiche per un determinato stack di compiti. Inoltre, consente di suddividere il lavoro e l'area di responsabilit\u00e0 tra gli sviluppatori.<\/p>\n

<\/p>\n

Lo sviluppatore Frontend, lavorando con JS, non influisce praticamente sul Backend. Lo sviluppatore Backend, a sua volta, sviluppa, nel nostro caso, Ruby on Rails e non interferisce con il Frontend. L'interazione avviene tramite API.<\/p>\n

<\/p>\n

Come bonus, grazie a Docker siamo riusciti a ottimizzare le risorse su Staging. Ogni progetto, a causa della sua specificit\u00e0, richiedeva impostazioni particolari. Era necessario dedicare un server virtuale oppure dividere un ambiente variabile, e i progetti potevano influenzarsi a vicenda a seconda della versione delle librerie.<\/p>\n

<\/p>\n

\"Processo<\/p>\n

<\/p>\n

Strumenti. Cosa usiamo? <\/p>\n

<\/p>\n