{"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\/fr\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Le processus de d\u00e9veloppement et de test avec Docker et Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Je vous invite \u00e0 prendre connaissance de la transcription de la pr\u00e9sentation d'Alexander Sigachev d'Inventos \u00ab Le processus de d\u00e9veloppement et de test avec Docker + Gitlab CI \u00bb<\/strong><\/p>\n

<\/p>\n

Ceux qui commencent \u00e0 mettre en \u0153uvre le processus de d\u00e9veloppement et de test bas\u00e9 sur Docker + Gitlab CI posent souvent des questions basiques. Par o\u00f9 commencer ? Comment s'organiser ? Comment tester ?<\/p>\n

<\/p>\n

Cette pr\u00e9sentation est bonne car elle d\u00e9crit de mani\u00e8re structur\u00e9e le processus de d\u00e9veloppement et de test utilisant Docker et Gitlab CI. La pr\u00e9sentation date de 2017. Je pense que l'on peut tirer des bases, de la m\u00e9thodologie, de l'id\u00e9e et des exp\u00e9riences d'utilisation de cette pr\u00e9sentation. <\/p>\n

\n

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

Pour ceux que cela int\u00e9resse, je vous invite \u00e0 lire la suite. <\/a><\/noindex><\/p>\n

<\/p>\n

Je m'appelle Alexandre Sigatchev. Je travaille chez Inventos. Je vais parler de mon exp\u00e9rience d'utilisation de Docker et de la mani\u00e8re dont nous l'int\u00e9grons progressivement dans nos projets.<\/p>\n

<\/p>\n

Th\u00e8me de la pr\u00e9sentation : Processus de d\u00e9veloppement avec Docker et Gitlab CI. <\/p>\n

<\/p>\n

\"Le<\/p>\n

<\/p>\n

C'est ma deuxi\u00e8me pr\u00e9sentation sur Docker. Au moment de la premi\u00e8re pr\u00e9sentation, nous utilisions Docker uniquement dans le d\u00e9veloppement sur les machines des d\u00e9veloppeurs. Le nombre d'employ\u00e9s utilisant Docker \u00e9tait d'environ 2-3 personnes. Petit \u00e0 petit, nous avons accumul\u00e9 de l'exp\u00e9rience et progress\u00e9 un peu plus loin. Lien vers notre premi\u00e8re pr\u00e9sentation<\/a><\/noindex>.<\/p>\n

<\/p>\n

Que contiendra cette pr\u00e9sentation ? Nous partagerons notre exp\u00e9rience sur les obstacles rencontr\u00e9s et comment nous avons r\u00e9solu certains probl\u00e8mes. Ce n'\u00e9tait pas toujours id\u00e9al, mais cela nous a permis d'avancer.<\/p>\n

<\/p>\n

Notre devise : dockeriser tout ce qui nous passe par les mains.<\/p>\n

<\/p>\n

\"Le<\/p>\n

<\/p>\n

Quels probl\u00e8mes r\u00e9solvons-nous ?<\/p>\n

<\/p>\n

Lorsque plusieurs \u00e9quipes sont pr\u00e9sentes dans l'entreprise, le programmeur est une ressource partag\u00e9e. Il arrive qu'un programmeur soit extrait d'un projet et affect\u00e9 temporairement \u00e0 un autre projet.<\/p>\n

<\/p>\n

Pour qu'un programmeur puisse s'int\u00e9grer rapidement, il doit t\u00e9l\u00e9charger le code source du projet et mettre en place un environnement le plus rapidement possible afin de r\u00e9soudre les probl\u00e8mes du projet.<\/p>\n

<\/p>\n

En g\u00e9n\u00e9ral, si l'on commence de z\u00e9ro, la documentation dans le projet est rare. Les informations sur la configuration ne sont disponibles que pour les v\u00e9t\u00e9rans. Les employ\u00e9s configurent leur poste de travail en un ou deux jours. Pour acc\u00e9l\u00e9rer ce processus, nous avons utilis\u00e9 Docker.<\/p>\n

<\/p>\n

La raison suivante concerne la normalisation des param\u00e8tres en d\u00e9veloppement. D'apr\u00e8s mon exp\u00e9rience, les d\u00e9veloppeurs prennent souvent des initiatives. Dans un cas sur cinq, un domaine personnalis\u00e9 est introduit, par exemple vasya.dev. \u00c0 c\u00f4t\u00e9, se trouve le voisin Petya, qui a le domaine petya.dev. Ils d\u00e9veloppent un site ou un composant du syst\u00e8me en utilisant ce nom de domaine.<\/p>\n

<\/p>\n

Lorsque le syst\u00e8me se d\u00e9veloppe et que ces noms de domaine commencent \u00e0 figurer dans les configurations, un conflit d'environnements de d\u00e9veloppement se produit et le chemin du site est r\u00e9\u00e9crit.<\/p>\n

<\/p>\n

Il en va de m\u00eame pour les param\u00e8tres de la base de donn\u00e9es. Certaines personnes ne pensent pas \u00e0 la s\u00e9curit\u00e9 et travaillent avec un mot de passe root vide. D'autres, lors de l'installation, la configuration MySQL a exig\u00e9 un mot de passe, qui s'est r\u00e9v\u00e9l\u00e9 \u00eatre 123. Il arrive souvent que la configuration de la base de donn\u00e9es change constamment en fonction des commits du d\u00e9veloppeur. Quelqu'un a corrig\u00e9, quelqu'un ne l'a pas fait. Il y avait des astuces o\u00f9 nous avons sorti une configuration de test dans .gitignore<\/code> et chaque d\u00e9veloppeur devait installer la base de donn\u00e9es. Cela compliquait le processus de d\u00e9marrage. Il faut, entre autres, se rappeler de la base de donn\u00e9es. La base de donn\u00e9es doit \u00eatre initialis\u00e9e, il faut indiquer un mot de passe, un utilisateur \u00e0 cr\u00e9er, une table, etc.<\/p>\n

<\/p>\n

Un autre probl\u00e8me est la diversit\u00e9 des versions des biblioth\u00e8ques. Il arrive souvent qu'un d\u00e9veloppeur travaille sur diff\u00e9rents projets. Il y a un projet Legacy, qui a commenc\u00e9 il y a cinq ans (de 2017 \u2014 note de la r\u00e9daction). Lors du d\u00e9marrage, nous avons commenc\u00e9 avec MySQL 5.5. Il y a aussi des projets modernes, o\u00f9 nous essayons d'int\u00e9grer des versions de MySQL plus r\u00e9centes, comme 5.7 ou plus (en 2017 \u2014 note de la r\u00e9daction).<\/p>\n

<\/p>\n

Celui qui travaille avec MySQL sait que ces biblioth\u00e8ques entra\u00eenent des d\u00e9pendances. Il est assez probl\u00e9matique de lancer deux bases en m\u00eame temps. Du moins, il est probl\u00e9matique de connecter de vieux clients \u00e0 une nouvelle base de donn\u00e9es. Cela engendre \u00e0 son tour plusieurs probl\u00e8mes.<\/p>\n

<\/p>\n

Le prochain probl\u00e8me survient lorsque le d\u00e9veloppeur travaille sur sa machine locale, utilisant des ressources locales, des fichiers locaux et de la RAM locale. Toute interaction pendant le d\u00e9veloppement des solutions se d\u00e9roule dans le cadre de ce qui fonctionne sur une seule machine. Par exemple, nous pouvons avoir 3 serveurs backend en production, mais le d\u00e9veloppeur enregistre des fichiers dans le r\u00e9pertoire racine, et c'est de l\u00e0 qu'Nginx prend les fichiers pour r\u00e9pondre aux demandes. Lorsque ce code atteint la production, il s'av\u00e8re que le fichier est pr\u00e9sent sur l'un des 3 serveurs.<\/p>\n

<\/p>\n

Actuellement, le d\u00e9veloppement des microservices est en plein essor. Lorsque nous divisons nos grandes applications en petits composants interagissant entre eux. Cela permet de s\u00e9lectionner des technologies sp\u00e9cifiques pour chaque ensemble de t\u00e2ches. Cela permet \u00e9galement de r\u00e9partir le travail et les zones de responsabilit\u00e9 entre les d\u00e9veloppeurs.<\/p>\n

<\/p>\n

Un d\u00e9veloppeur frontend travaillant en JS n'influence pratiquement pas le backend. Le d\u00e9veloppeur backend, quant \u00e0 lui, d\u00e9veloppe, dans notre cas, avec Ruby on Rails et ne g\u00eane pas le frontend. L'interaction s'effectue via l'API.<\/p>\n

<\/p>\n

Comme bonus, gr\u00e2ce \u00e0 Docker, nous avons pu optimiser les ressources sur Staging. Chaque projet, en raison de sa sp\u00e9cificit\u00e9, n\u00e9cessitait des configurations particuli\u00e8res. Il fallait physiquement allouer soit un serveur virtuel et les configurer s\u00e9par\u00e9ment, soit partager un environnement variable, ce qui pouvait influencer les projets les uns sur les autres selon les versions des biblioth\u00e8ques.<\/p>\n

<\/p>\n

\"Le<\/p>\n

<\/p>\n

Outils. Que utilisons-nous ? <\/p>\n

<\/p>\n