Git, commit, MEP informatique... 5 minutes pour comprendre les gestes quotidiens d'un développeur

L’outil de versioning

Quand les développeurs travaillent sur un projet, ils utilisent un outil de contrôle de version, ou versioning. Ce type d’outil gère les versions des fichiers, et donc permet d’éviter ça :

Cet outil va permettre à tous les développeurs de travailler ensemble sur le même projet, tout en gardant une trace des modifications effectuées sur les fichiers.

Un outil similaire est utilisé sur Google sheets par exemple :

On va ici simplifier le processus mais garder les termes techniques, ce qui vous permettra de communiquer avec des techs dans un langage commun.

Le développement local

Un développeur travaille sur un environnement “local”, qui est installé sur son ordinateur pour simuler le produit. Il a une copie du code du produit sur son ordinateur, et fait ses modifications sur cette copie. Cette copie se trouve dans un dossier surveillé par le logiciel de versionning, appelé repo (pour repository, ou dépôt en français, terme moins utilisé). Ce repo qui se trouve sur l’ordinateur du développeur est le repo local.

Pour l’exemple, on va prendre un développeur qui veut ajouter un bouton sur son site, qui fait apparaître un cookie (le gâteau, pas le tracker) à l’écran de l’utilisateur. Ceci s’appelle une feature.

Pour cela, il va modifier la copie du code du site stockée sur son ordinateur, pour ajouter un bouton au site, créer la fonction qui va faire apparaître un cookie, et activer la fonction quand on clique sur le bouton.

Quand il est satisfait de ses modifications et qu’il les a testées sur son environnement local, le développeur va signaler ces modifications au logiciel de versionning, via un add (la commande utilisée est “git add”).

L’ajout du code au repo partagé

Il va ensuite demander au logiciel de versionning de mettre à jour la copie du code qui se trouve dans le repo local, pour ajouter ces mises à jour, en faisant un commit (en utilisant la commande “git commit”, vous comprenez la logique).

On a donc un développeur qui a un repo local qui contient le code du site, plus sa fonction qui fait apparaître un cookie. Notre développeur va maintenant vouloir intégrer sa modification au code du produit. Pour cela, il va devoir mettre à jour le repo partagé (on en avait pas encore parlé de celui-là mais pas de panique) qui est stocké sur une plateforme en ligne, généralement GitLab ou GitHub, et qui contient le code de référence du projet, sur lequel collaborent tous les développeurs.

Pour résumer, chaque développeur travaille sur une copie locale du code du projet, puis intègre ses modifications au code partagé. Pour intégrer ces modifications, il va faire un push (oui, on s’en doute, grâce à la commande “git push”) pour mettre à jour le repo partagé.

En revanche, il ne va pas mettre à jour directement le code source du projet : il risquerait d’y introduire des bugs. Il va passer par une branche, qui est une version alternative du code. Sur un projet, on peut par exemple avoir la branche “master” (qui est par convention le code source mis en production), et la branche “dev” utilisée par les développeurs pour appliquer leurs modifications.

La mise en production (MEP)

Le fait d’avoir plusieurs branches permet aux développeurs d’intégrer toutes leurs modifications sur la branche “dev”, de tester le code de “dev” sur un environnement spécial (soyons fous, appelons-le “l’env de dev”), et, une fois qu’on est satisfait du code de la branche dev, de mettre à jour le code de master avec les modifications apportées.

Ce processus est une mise en production (ou “mise en prod’”, ou encore MEP), et est une étape cruciale pour une entreprise : c’est le moment où le travail des développeurs devient accessible à l’utilisateur (le client du produit, par exemple).

Petit aparté : une mise en prod peut avoir lieu une fois tous les quelques mois, pour des entreprises ayant généralement un faible niveau d’intégration DevOps, à plusieurs fois par jour ou automatiquement à la demande des développeurs, pour les entreprises ayant investi dans une approche DevOps et un processus de CI/CD efficace.

Notre développeur va donc ajouter sa modification à une branche dédiée.

La convention dépend des projets, et est généralement d’avoir une branche par feature (“dev-BoutonQuiFaitPopDesCookiesSurLEcranDeMonUtilisateurPourLuiDonnerFaim” <- c’est un peu long, mais vous voyez l’idée), et, dans le cas où plusieurs développeurs travaillent sur la même feature, d’avoir une sous-branche par développeur (“dev-BoutonQuiFaitPopDesCookiesSurLEcranDeMonUtilisateurPourLuiDonnerFaim-Paul”).

Il va ensuite demander l’intégration de cette branche au code de la branche partagée (la branche “dev” par exemple), au moyen d’une fonctionnalité de la plateforme de gestion de code utilisée, la merge request (sur GitLab, appelée pull request sur GitHub). Cela demande une validation supplémentaire pour acter la mise à jour de la branche, et permet de mettre en place un processus de code review, c’est-à-dire une validation par un autre développeur du code ajouté, ce qui permet de limiter les erreurs.

Une fois que la merge request (ou MR, PR pour pull request) est validée, la modification est appliquée et la feature ajoutée au code de la branche “dev” ! Le code de cette branche sera ensuite déployé sur un environnement de test (par exemple hébergé sur www.dev.monsite.fr, et accessible uniquement aux développeurs).

Quand les développeurs auront répété ce processus, ajouté un certain nombre de fonctionnalités et testé sur l’env de dev que le code fonctionne bien, ils pourront mettre leur code en prod en faisant une MR de dev vers master (vous voyez comment ça claque comme phrase ?), et déployer master sur l’env de prod (qui est l’environnement utilisé par les utilisateurs, hébergé par exemple sur www.monsite.fr)

Conclusion

Ce processus est itératif et asynchrone : les développeurs travaillent en permanence sur des nouvelles features en passant par ces étapes, de la création de la feature sur leur environnement local à son intégration sur la branche de dev (aussi appelée “staging” ou “pré-prod” selon les projets). L’utilisation d’une plateforme de versioning permet à un grand nombre de développeurs de travailler simultanément, seuls ou à plusieurs sur une feature.

La fréquence des mises en production dépend de beaucoup de contraintes de sécurité, de test, de prérequis opérationnels… Et varie donc énormément selon les entreprises.

Félicitations, vous pouvez maintenant parler comme un tech ! Voici quelques phrases (que vous devriez maintenant comprendre) que vous pouvez utiliser :

• “Faut pas s’étonner de se retrouver avec des bugs sur cette feature si personne n’a review la MR"
• “C’est normal qu’on n’ait pas ce formulaire sur dev, [X] est parti hier sans push son code”
• “On a une MEP prévue cette aprèm, vous avez bien fait vos commits ?”