{"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":"Il processo di sviluppo e testing con Docker e Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u0430 \u0421\u0438\u0433\u0430\u0447\u0435\u0432\u0430 \u0438\u0437 Inventos «\u041f\u0440\u043e\u0446\u0435\u0441\u0441 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 Docker + Gitlab CI»<\/strong><\/p>\n

<\/p>\n

Chi inizia a implementare il processo di sviluppo e testing basato su Docker + Gitlab CI spesso si pone domande fondamentali. Da dove cominciare? Come organizzare? Come testare?<\/p>\n

<\/p>\n

Questa presentazione \u00e8 utile perch\u00e9 spiega in modo strutturato il processo di sviluppo e testing utilizzando Docker e Gitlab CI. La presentazione risale al 2017. Penso che da questo documento si possano trarre le basi, la metodologia, l'idea e l\u2019esperienza d'uso. <\/p>\n

\n

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

Chi \u00e8 interessato, prosegua oltre. <\/a><\/noindex><\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

\"Il<\/p>\n

<\/p>\n

Questa \u00e8 la mia seconda presentazione su Docker. Al momento della mia prima presentazione, utilizzavamo Docker solo in fase di sviluppo sui computer degli sviluppatori. Il numero di dipendenti che utilizzavano Docker era di circa 2-3 persone. Gradualmente abbiamo accumulato esperienza e abbiamo fatto qualche passo avanti. Ecco il link al nostro prima presentazione<\/a><\/noindex>.<\/p>\n

<\/p>\n

Cosa ci sar\u00e0 in questa presentazione? Condivideremo la nostra esperienza su quali ostacoli abbiamo incontrato e come abbiamo risolto diversi problemi. Non \u00e8 stato sempre facile, ma ci ha permesso di andare avanti.<\/p>\n

<\/p>\n

Il nostro motto: containerizza tutto ci\u00f2 che ci passa per le mani.<\/p>\n

<\/p>\n

\"Il<\/p>\n

<\/p>\n

Quali problemi risolviamo?<\/p>\n

<\/p>\n

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

<\/p>\n

Per permettere al programmatore di integrarsi rapidamente, \u00e8 necessario che scarichi il codice sorgente del progetto e avvii il prima possibile un ambiente che gli permetta di procedere affrontando le attivit\u00e0 di quel progetto.<\/p>\n

<\/p>\n

Di solito, se si inizia da zero, la documentazione del progetto \u00e8 scarsa. Le informazioni su come configurare sono disponibili solo da chi \u00e8 gi\u00e0 presente da tempo. I collaboratori generalmente configurano il proprio ambiente di lavoro in uno o due giorni. Per accelerare questo processo, abbiamo utilizzato Docker.<\/p>\n

<\/p>\n

Il motivo successivo \u00e8 la standardizzazione delle impostazioni in Development. Dalla mia esperienza, gli sviluppatori tendono sempre a prendere l'iniziativa. In un caso su cinque si introduce un dominio personalizzato, ad esempio vasya.dev. Vicino c'\u00e8 il vicino Petya, che ha il dominio petya.dev. Stanno sviluppando un sito o un componente del sistema utilizzando questo nome di dominio.<\/p>\n

<\/p>\n

Quando il sistema si espande e questi nomi di dominio iniziano a comparire nelle configurazioni, si verifica un conflitto negli ambienti di Development e viene sovrascritto il percorso del sito.<\/p>\n

<\/p>\n

Lo stesso accade con le impostazioni del database. Qualcuno non si preoccupa della sicurezza e lavora con la password vuota di root. Qualcun altro, durante l'installazione, ha trovato che MySQL richiedeva una password e la password era semplice, come 123. Spesso accade che la configurazione del database cambi in continuazione a seconda del commit dello sviluppatore. Qualcuno ha corretto, qualcun altro no. Ci sono stati stratagemmi in cui portavamo qualche configurazione di test in .gitignore<\/code> ogni sviluppatore doveva installare un database. Questo complicava il processo di avvio. Oltre a tutto ci\u00f2, \u00e8 importante tenere a mente il database. Il database deve essere inizializzato, \u00e8 necessario specificare una password, un nome utente, creare una tabella e cos\u00ec via.<\/p>\n

<\/p>\n

Un'altra problematica riguarda le diverse versioni delle librerie. Spesso gli sviluppatori lavorano su progetti diversi. C'\u00e8 un progetto legacy che \u00e8 stato avviato cinque anni fa (dal 2017 - nota del curatore). All'inizio si part\u00ec con MySQL 5.5. Ci sono anche progetti moderni, dove cerchiamo di implementare versioni pi\u00f9 recenti di MySQL, come 5.7 o superiore (nel 2017 - nota del curatore).<\/p>\n

<\/p>\n

Chi lavora con MySQL sa che queste librerie portano con s\u00e9 delle dipendenze. \u00c8 piuttosto complicato avviare due database insieme. Almeno, \u00e8 problematico connettere i vecchi client a un nuovo database. Questo, a sua volta, crea diverse problematiche.<\/p>\n

<\/p>\n

Il problema successivo si verifica quando uno sviluppatore lavora su una macchina locale, utilizzando risorse locali, file locali e RAM locale. Tutta l'interazione durante lo sviluppo delle soluzioni avviene all'interno di un unico sistema. Un esempio \u00e8 rappresentato dalla situazione in cui abbiamo 3 server backend in produzione, mentre lo sviluppatore salva i file nella directory radice, da cui nginx preleva i file per rispondere alle richieste. Quando questo codice viene trasferito 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 suddividiamo le nostre grandi applicazioni in piccoli componenti che interagiscono tra loro. Questo consente di scegliere tecnologie specifiche per il particolare stack di compiti. Inoltre, permette di separare il lavoro e le aree di responsabilit\u00e0 tra gli sviluppatori.<\/p>\n

<\/p>\n

Uno sviluppatore frontend, lavorando in JS, ha un'influenza minima sul backend. Lo sviluppatore backend, a sua volta, sta sviluppando, nel nostro caso, su 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 gestire le risorse su Staging. Ogni progetto, a causa della sua specificit\u00e0, richiedeva configurazioni particolari. Fisicamente, era necessario dedicare un server virtuale per ciascun progetto e configurarli separatamente, oppure condividere un ambiente variabile, potendo influenzare reciprocamente i progetti in base alle versioni delle librerie.<\/p>\n

<\/p>\n

\"Il<\/p>\n

<\/p>\n

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

<\/p>\n