Pourquoi votre code a besoin d'un dépôt partagé avant même de penser au CI/CD
Vous travaillez seul sur une application. Tout le code vit sur votre ordinateur portable. Vous pouvez modifier n'importe quoi, à tout moment, sans jamais craindre de casser le travail de quelqu'un d'autre. Cela semble simple, propre et sous contrôle.
Puis une deuxième personne rejoint le projet. Vous avez désormais tous les deux des copies du code sur vos propres machines. Vous corrigez un bug un vendredi après-midi. Votre collègue repart d'une version plus ancienne le lundi matin et écrase accidentellement votre correction. Aucun de vous ne sait ce qui s'est passé jusqu'à ce que quelqu'un remarque que le bug est de retour. Vous perdez des heures à déterminer quelle copie contient le bon code.
C'est le moment où « sauvegarder en local » cesse de fonctionner.
Le problème qui grandit avec votre équipe
La situation empire lorsque de vrais utilisateurs commencent à dépendre de votre application. Vous devez corriger des bugs, ajouter des fonctionnalités, mettre à jour des bibliothèques et gérer des correctifs de sécurité. Tous ces changements doivent se faire de manière coordonnée. Vous ne pouvez pas continuer à échanger des fichiers par messages ou pièces jointes. Cette approche est fragile, facile à perdre et ne laisse aucune trace de qui a modifié quoi et quand.
Sans système partagé, chaque livraison devient un cauchemar de coordination manuelle. Quelqu'un doit collecter le code de tout le monde, le fusionner à la main et espérer qu'il n'y a pas de conflit. Le processus est épuisant, sujet aux erreurs et impossible à reproduire de manière cohérente.
Ce que fait réellement le contrôle de source
Le contrôle de source est un système de stockage pour le code auquel chaque membre de l'équipe peut accéder. Cela semble simple, mais les implications sont énormes.
Il existe un endroit central qui contient le code de l'application. Cet endroit s'appelle un dépôt (repository). Chaque membre de l'équipe peut tirer (pull) une copie du code depuis le dépôt vers sa propre machine. Lorsqu'il a terminé ses modifications, il pousse (push) ces modifications vers le dépôt. Le dépôt enregistre chaque poussée comme un commit -- un instantané qui marque l'état du code à un moment précis.
Avec ce système, votre équipe n'a jamais à demander « qui a la dernière version ? » ou « quel fichier as-tu modifié ? ». Tout est enregistré dans le dépôt. Il suffit de consulter l'historique des commits pour voir les dernières avancées.
Les avantages pratiques sont immédiats :
- Chaque modification est tracée. Vous savez qui a fait la modification, quand il l'a faite et ce qu'il a changé.
- Vous pouvez revenir en arrière. Si quelque chose casse, vous pouvez consulter l'historique et revenir à une version antérieure.
- Plus d'écrasements accidentels. Plusieurs personnes peuvent travailler sur la même base de code sans détruire accidentellement le travail des autres.
- Une source de vérité unique. Tout le monde s'accorde sur le fait que le dépôt contient le code réel et actuel.
Pourquoi le contrôle de source est le fondement du CI/CD
Voici ce qui compte pour les pipelines de livraison. Avant qu'un pipeline automatisé puisse s'exécuter, il doit savoir quel code traiter. Le pipeline doit lire le code depuis un endroit, exécuter des tests, construire des artefacts et les envoyer vers les serveurs. Rien de tout cela n'est possible si le code est dispersé sur des ordinateurs individuels.
Le contrôle de source fournit un endroit unique auquel le pipeline peut faire confiance. Le pipeline tire le code du dépôt, le traite et produit le résultat. C'est pourquoi le contrôle de source n'est pas optionnel pour le CI/CD -- c'est un prérequis. Sans dépôt partagé, il n'y a pas de source de vérité unique sur laquelle l'automatisation peut s'appuyer.
Pensez à ce qui se passerait sans cela. Chaque fois que quelqu'un fait une modification, quelqu'un doit rassembler manuellement le code de tout le monde, le fusionner et espérer qu'il n'y a pas de conflits. Le processus est lent, peu fiable et ne peut pas être automatisé. Vous vous retrouvez avec un processus de livraison qui dépend de la mémoire humaine et de la coordination manuelle.
Le flux dans la réalité
Voici comment cela fonctionne en pratique :
- Vous écrivez du code sur votre machine.
- Vous commitez vos modifications localement avec un message décrivant ce que vous avez fait.
- Vous poussez vos commits vers le dépôt partagé.
- Les autres membres de l'équipe tirent vos modifications dans leurs propres copies.
- Le dépôt conserve un enregistrement permanent de chaque commit.
Ce flux remplace l'ancien modèle « envoie-moi le fichier » ou « je l'ai sauvegardé sur le disque partagé ». Il donne à l'équipe un historique fiable et une compréhension claire de ce qui se passe avec la base de code.
La suite
Une fois que votre code vit dans un dépôt partagé, une nouvelle question apparaît : comment gérer les modifications encore en cours ? Toutes les modifications ne doivent pas aller directement dans le code principal. Le travail en cours de développement doit être séparé du code stable dont dépendent les utilisateurs.
C'est là que les branches entrent en jeu. Une branche est une ligne de développement distincte qui vous permet de travailler sur des modifications sans affecter le code principal. Vous pouvez expérimenter, faire des erreurs et corriger les choses en isolation. Lorsque le travail est prêt, vous le fusionnez dans la branche principale.
Le branching est l'étape naturelle après le contrôle de source. Il vous donne la capacité de travailler en parallèle sans chaos. Mais c'est un sujet pour un autre article.
Liste de vérification pratique
Avant de mettre en place un pipeline CI/CD, assurez-vous que ces bases sont en place :
- Tout le code de l'application vit dans un dépôt partagé accessible à chaque membre de l'équipe
- Chaque membre de l'équipe sait comment tirer, commiter et pousser des modifications
- Les messages de commit décrivent ce qui a changé et pourquoi, pas seulement « correction » ou « mise à jour »
- L'équipe s'accorde sur la branche qui représente le code stable et prêt pour la production
- L'accès au dépôt est contrôlé -- tout le monde ne peut pas pousser directement sur la branche principale
Ce qu'il faut retenir
Le contrôle de source n'est pas un luxe ou une bonne pratique. C'est le socle de tout processus de livraison fiable. Sans lui, votre équipe passera plus de temps à coordonner le code qu'à construire des fonctionnalités. Avec lui, vous avez une source de vérité unique à laquelle votre équipe et votre automatisation peuvent faire confiance. Commencez par là avant de vous soucier des pipelines, des stratégies de déploiement ou de toute autre partie du CI/CD.