Il est des incontournables dans la boite à outils des dev /devOps et affiliés et git fait partis de ceux-là… Mais qu’est-ce que git ?
Essayons d’imager un peu. N’avez-vous jamais eu ce fameux document Word que vous modifiez et reprenez inlassablement ? Ce même document que vous historisez au gré de vos modifications, avec pour conséquence d’avoir 275 documents Word dans votre répertoire de travail pour seulement 1 seul fichier « final » ?
On peut aussi citer le cas d’usage où pour chaque modification vous envoyez le document courant par mail avec l’historique de vos modifications dans le corps du message. Je parlais de 275 documents… On peut penser qu’il y a autant de mails à garder pour conserver l’historique complet !
Imaginez maintenant un outil qui garderait en mémoire les évolutions apportées et que pour chaque enregistrement vous puissiez joindre un commentaire :
Chaque lignes soumises (commit) sont liées à un identifiant unique (commit-id), vous avez donc la possibilité de « naviguer » dans toutes ces versions. A partir de ce moment-là tout est imaginable, comme notamment venir récupérer des éléments d’un commit A et les merger avec un commit D. et bien sûr pas de duplication des fichiers nécessaires.
L’étendue de ce que l’on peut faire avec cet outil est bien plus large que cela, et même si j’ai pris un document Word comme exemple, l’outil fonctionne sur à peu près tout…
L’autre avantage est qu’il est décentralisé via un dépôt distant. Plusieurs solutions existent, gratuites comme payantes : GitHub, Gitlab, BitBucket, etc…
Dans mon cas, son utilisation a commencé par le tracking de scripts LoadRunner, l’intérêt étant de créer une branche spécifique pour chaque release testées. Il était ainsi facile de switcher sur une configuration des scripts et scénarios bien précise.
Une fois la campagne terminée, on vient merger sa branche de travail sur master et on pousse tout ça sur le dépôt > Au passage la sauvegarde est assurée. !
Je parle là d’un cas où finalement je suis seul,
mais la vraie force de cet outil est dans la collaboration. On peut alors faire
travailler toute une équipe sur un même projet.
Chaque collaborateur développant son petit bout dans son coin prendra
soin de récupérer les modifications des autres et viendra pousser les siennes.
Le projet va s’étoffer en prenant en compte les modifications de tous.
Des outils comme Neoload ou LoadRunner embarquent désormais un client git qui permet de gérer les commit / pull / push directement depuis l’application, il n’y a donc plus d’excuses pour ne pas avoir le réflexe ! 🙂
Exemple avec Neoload :
On peut choisir la branche de destination :
Neoload identifie les éléments qui ont changés et les matérialise par une cache cochée :
Neoload pousse alors les modifications vers le dépôt distant :
Modification que l’on retrouve sur son interface préférée :
LoadRunner propose également son propre client git :
Avec git le partage de code (ou de script de tests) n’a jamais été aussi simple, un dépôt / un commit / un message clair et concis et le tour est joué. Fini l’écrasement sauvage de fichier, la note sur un coin de table, les envois de fichiers par mail (quand ceux-ci ne sont pas bloqués).
Et avec les clients git intégrés aux outils de perfs la prise en main est simplifiée. Plus d’excuse, git fait partis des best practices à ajouter à la liste !
