Comment j’utilise la commande Git for-each-ref pour DevOps

Pour la plupart des développeurs d’aujourd’hui, utiliser Git s’apparente à respirer, dans le sens où vous ne pouvez pas vous en passer. Parallèlement au contrôle de version, l’utilisation de Git s’est même étendue ces dernières années au domaine de GitOps, ou à la gestion et à la gestion des versions via Git. Ce que beaucoup d’utilisateurs ne réalisent pas ou ne pensent pas, c’est que Git suit non seulement les modifications de fichiers pour chaque commit, mais également de nombreuses métadonnées autour des commits et des branches. Votre DevOps peut exploiter ces données ou automatiser les opérations informatiques en utilisant les meilleures pratiques de développement logiciel, comme avec CI/CD.

Dans mon cas, j’utilise un processus automatisé (DevOps) par lequel une nouvelle branche est créée chaque fois que je fais la promotion d’une image dans un environnement CI/CD en aval (espace de noms) dans Kubernetes (voici une prise éhontée de mon Opensource.com article décrivant le processus). Cela me permet de modifier les descripteurs de déploiement pour un déploiement particulier dans un environnement CI/CD en aval indépendamment des autres environnements et me permet de versionner ces changements (GitOps).

Je vais discuter d’un scénario typique où un bogue de rupture est découvert dans QA, et personne n’est sûr de la version qui a introduit le bogue. Je ne peux pas et ne veux pas m’appuyer sur les métadonnées d’image pour trouver la branche dans Git qui contient les descripteurs de déploiement appropriés pour plusieurs raisons, en particulier compte tenu du fait que je pourrais avoir besoin de rechercher un référentiel local ou plusieurs images distantes. Alors, comment puis-je facilement exploiter les informations d’un référentiel Git pour trouver ce que je recherche ?

Utilisez la commande for-each-ref

Ce scénario est celui où le for-each-ref commande est d’une réelle utilité. Cela me permet de rechercher toutes les branches de mon référentiel Git filtrées par la convention de nommage que j’utilise (une bonne raison d’appliquer les conventions de nommage lors de la création de branches) et renvoie les branches les plus récemment modifiées dans l’ordre de tri décroissant. Par exemple:

$ git clone git@github.com:elcicd/Test-CICD1.git
$ cd Test-CICD1
$ git for-each-ref --format='%(refname:short) (%(committerdate))' \
                   --sort='-committerdate' \
                   'refs/remotes/**/deployment-qa-*'
origin/deployment-qa-c6e94a5 (Wed May 12 19:40:46 2021 -0500)
origin/deployment-qa-b70b438 (Fri Apr 23 15:42:30 2021 -0500)
origin/deployment-qa-347fc1d (Thu Apr 15 17:11:25 2021 -0500)
origin/deployment-qa-c1df9dd (Wed Apr 7 11:10:32 2021 -0500)
origin/deployment-qa-260f8f1 (Tue Apr 6 15:50:05 2021 -0500)

Les commandes ci-dessus clonent un référentiel que j’utilise souvent pour tester les déploiements Kubernetes. j’utilise alors git for-each-ref pour rechercher les branches en fonction de la date de la dernière validation, limitez la recherche aux branches qui correspondent à la convention de dénomination des branches de déploiement pour l’environnement QA et renvoyez les cinq dernières. Celles-ci correspondent approximativement (c’est-à-dire pas nécessairement, mais assez proches) aux cinq dernières versions du composant/microservice que je souhaite redéployer.

deployment-qa-* est basé sur la convention de nommage :

<descriptive-prefix>-<deployment-env>-<dev-branch-commit-hash>

Les informations renvoyées peuvent être utilisées par les développeurs ou le personnel d’assurance qualité lors de l’exécution du pipeline de redéploiement CI/CD pour décider de la version à restaurer/transférer dans un espace de noms Kubernetes et ainsi éventuellement revenir à un bon état connu. Ce processus précise quand et ce qui a introduit le bogue de rupture dans le scénario artificiel.

Bien que la convention de dénomination et le scénario ci-dessus soient particuliers aux besoins et aux processus CI/CD automatisés, il existe d’autres moyens plus généralement utiles d’utiliser for-each-ref. De nombreuses organisations ont des conventions de dénomination de branche similaires à ce qui suit :

<version>-<feature-or-bug>-<feature-or-bug-id>

le identifiant la valeur fait référence à l’ID décrivant la fonctionnalité ou le bogue dans un système de gestion de projet comme Rally ou Jira ; par exemple:

v1.23-feature-12345

Cet ID permet aux utilisateurs d’obtenir facilement et rapidement une visibilité supplémentaire sur l’historique de développement plus large du référentiel et du projet (à l’aide refs/remotes/**/v.123-feature-*), en fonction du processus de développement et des politiques de convention de dénomination des branches. Le processus fonctionne également sur les balises, de sorte que la liste des dernières pré-prod, prod ou autres versions spécifiques peut être effectuée presque aussi facilement (toutes les balises ne sont pas extraites par défaut).

Emballer

Il ne s’agit là que d’exemples particuliers et étroits d’utilisation des for-each-ref. Des auteurs aux messages de commit, le documents officiels fournit un aperçu de nombreux détails qui peuvent être recherchés, filtrés et signalés.