Automatiser sa production avec GitLab – partie 1

Automatiser la production avec Gitlab

Automatiser sa production

Découvrez dans cet article comment automatiser tout le processus de déploiement et de contrôle qualité d'un projet, permettant ainsi à la fois d'améliorer la qualité du code et de gagner du temps.

Préambule

Avant de commencer cet article, je tiens d’abord à nuancer mes propos. En effet, bien que le titre soit « Automatiser sa production avec GitLab », je ne vais pas vous présenter la solution parfaite, capable de résoudre tous vos problèmes ni même de faire votre café.
Je vais plutôt vous présenter l’architecture que nous utilisons en interne pour notre système d’intégration continue, permettant de transformer chaque « commit » en une nouvelle installation propre et visible pour le client.
Cela permet ainsi de surveiller l’évolution des projets en temps réel, et d’échanger avec les clients sur telle ou telle fonctionnalité dès qu’elle est visible plutôt que d’attendre la prochaine release qui ne viendra que dans 3 mois. Ce n’est peut-être pas si loin de la perfection, non ?

Comme il y a beaucoup à dire sur ce sujet, il a été divisé en 3 parties.

  1. Ce premier article décrit tout ce qui se passe dès que nous écrivons le code jusqu’au moment où il est réceptionné et stocké sur notre système.
  2. La seconde partie se concentrera presque exclusivement sur la puissance de GitLab et du fichier « .gitlab-ci.yml ». C’est là que l’on orchestre le tour de magie.
  3. Enfin la dernière partie concernera le déploiement, les tests et la mise en ligne.

Enfin, cet article a été rédigé pour être compréhensible par tous et non uniquement par des développeurs. C’est pour cela que j’ai volontairement pris des raccourcis ou passé certaines informations sous silence.
Enfin, pour les développeurs qui souhaiteraient comprendre mieux le sujet, vous pouvez retrouver un diagramme de ce workflow, réalisé pour l’occasion.
Maintenant que les présentations sont faites, commençons !


Chapitre 1 : Le code

Comme vous le savez peut-être, les sites internet sont faits de code, et en général, cela nécessite de rédiger des dizaines ou centaines de milliers de lignes pour avoir quelque chose qui fonctionne parfaitement. Cela peut prendre des mois voire des années.
C’est pourquoi les développeurs sauvegardent l’évolution de leur code sur des plateformes faites précisément pour ça. De notre côté nous utilisons un serveur GitLab sur lequel nous stockons chaque bout de code ajouté ou modifié, et côté serveur, le fichier final est la somme de tous ces petits bouts de code envoyés pendant des mois.

La sauvegarde avec GIT

La sauvegarde s’effectue depuis nos machines de développement avec GIT, une application permettant de gérer l’évolution de fichiers. Ainsi nous sélectionnons simplement les fichiers qui ont changés, ajoutons/retirons des lignes de code que nous souhaiterions sauvegarder ou ignorer, ensuite nous ajoutons à ce « rassemblement de changements », appelé « commit », un titre décrivant les modifications qu’il contient afin de pouvoir le retrouver facilement.

Une fois que cela est fait, le commit est envoyé sur le serveur qui va le réceptionner, l’ouvrir, prendre chaque changement présent et les appliquer à la version des fichiers qui sont stockés de son côté. Ainsi, après chaque envoi de commit, les fichiers présents sur le serveur sont à jour.

Les branches

Autre fonctionnalité pratique de GIT : la création de « branches » qui permettent de regrouper plusieurs versions d’un même projet, au même moment, sans pour autant modifier les autres versions.

Il faut l’imaginer comme si chaque commit rajoutait une couche de bois de 1cm à une souche d’arbre. A chaque commit, la souche grandit et gagne de la hauteur. Puis, on décide de créer une branche. Alors les commits qui affluent sur cette branche font pousser le bois sur le côté alors que les autres commits continuent de faire grandir l’arbre. Enfin, à un moment donné certaines branches reviennent vers le milieu et fortifient le tronc alors que d’autres continuent à évoluer dans une autre direction.

Il y a plusieurs manières d’utiliser les branches de GIT, dont voici les 2 façons les plus connues :

  • Chaque facette d’un même projet dans des branches différentes qui ne se rejoindront jamais.
  • Une nouvelle branche pour travailler sur une fonctionnalité, puis lui faire rejoindre le tronc lorsque la fonctionnalité est terminée.

Chez WAX, nous utilisons ces 2 façons de manière mélangées. Ainsi, il nous arrive souvent d’avoir une branche dédiée au magnifique front HTML/CSS/JS que rédige ma collègue Mylène Chandelier, tout en ayant d’autres branches pour des fonctionnalités complexes qui rejoignent le tronc lorsqu’elles sont terminées.

Cette notion de branches est assez importante pour la 3ème partie de cet article (en tout cas, le fait de savoir qu’une branche puisse revenir vers le tronc lorsqu’elle est suffisamment mûre).

Les tests

Autre point à savoir, par mesure de sécurité et en fonction du projet, nous rédigeons des tests unitaires et fonctionnels qui permettent de tester le code existant et de vérifier si quelque chose qui fonctionnait avant n’est pas soudainement cassé avec notre dernière modification que l’on vient d’apporter au projet. Je ne vais pas trop m’étendre sur le sujet des tests, il n’est pas important de comprendre comment cela fonctionne, juste savoir qu’ils testent le code existant, à la recherche d’une potentielle régression. Si vous souhaitez en savoir plus sur les tests unitaires et fonctionnels, vous pouvez toujours consulter mon autre article sur ce sujet (attention, article plutôt technique, pour public averti).

Ces tests sont « commités » avec le restant du code du projet afin de vivre (et mourir) avec les fichiers qu’ils sont sensés surveiller.

Cette notion de tests est elle-aussi importante pour la 3ème partie de l’article (en tout cas, comprendre le fait que les tests contrôlent le code qui leur est associé).

A présent que nos changements sont « commités » dans une branche dédiée, avec leurs tests respectifs, que le tout est envoyé vers notre serveur GitLab qui récupère ces changements et met à jour sa version du projet de son côté, nous pouvons passer au chapitre 2 : GitLab-CI.

Rendez-vous le 11 septembre pour la deuxième partie de cet article !

Michael Barbey
Publié le par
Michael Barbey
0 Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *