Saupoudrez un peu de GenAI sur vos Merge Requests
🔨

Saupoudrez un peu de GenAI sur vos Merge Requests

Dans le précédent article, je vous dévoilais comment la GenAI transforme le métier de DevOps, en évoquant quelques cas d’usages.

Aujourd’hui, laissez-moi vous expliquer ce qu’il se passe quand on associe une bonne idée à un concept récurrent de la vie de DevOps : la merge request.

Vous êtes prêts ? Installez-vous confortablement sur votre chaise, on s’occupe du reste.

🎵 Jeffrey ? Remets-nous des glaçons 🎵

C’est quoi une merge request ?

Chers confrères, vous savez peut-être déjà ce qu’est une merge request (MR). Je te prie de bien vouloir m’en excuser, accepte ce bisou 💋 avant de sauter fissa dans la prochaine section.

Pour les autres, un bisou aussi, mais pas avant d’être arrivés au bout de cet article.

Une merge request, comme le nom l’indique, est une requête pour fusionner une branche de développement avec une autre.

Voilà. Et comme nous sommes des DevOps, nous introduisons des changements dans les infrastructures en créant une branche qui décrit un changement (A), et on ouvre une merge request (plus ou moins grosse) lorsque le moment est venu de la fusionner avec la branche principale.

Exemple d’une merge request :

image

Les merge requests servent à collaborer plus efficacement. En encapsulant un jeu de modifications dans un abstract appelé merge request ou pull request, il est ensuite possible d’interagir, échanger, commenter à l’intérieur de celles-ci et de programmer le déclenchement de ces modifications, tout en assurant une traçabilité ou la capacité de rollback (revert) un changement.

Jusqu’ici, rien de nouveau sous le soleil, c’est une primitive utilisée quotidiennement par des millions de softwares engineers et de DevOps.

Cas d’usage GenAI #1 - La revue de code

La revue de code, c’est le fait de relire le code proposé par une personne dans une merge request.

Grâce à ce procédé, on espère isoler et corriger les typos, les erreurs de syntaxes, les bugs, et conseiller l’auteur vers des approches plus efficientes, souples ou optimisées.

La revue de code n’a pas forcément lieu à chaque fois, mais elle est conseillée pour éviter d’introduire inopinément des bugs en prod.

Est-ce que ce screenshot sert à montrer que chez Skale-5, on contribue aussi à des projets open-source comme
Est-ce que ce screenshot sert à montrer que chez Skale-5, on contribue aussi à des projets open-source comme Steampipe ? Peut-être 🙂.

La revue de code, bien qu’étant un processus très sain, consomme du temps-homme.

Saupoudrons tout ça d’un peu de GenAI, si vous le voulez bien.

Démo

Voici la revue de code écrite par notre bot dans la merge request évoquée en début d’article (déploiement d’une nouvelle application dans un cluster Kubernetes)

DevOps Bot 🤖 a écrit le commentaire suivant dans la merge request :
  1. Sécurité - Mot de passe admin Grafana en dur :
    • Fichier : manifests/monitoring/grafana/overlays/aws-exploit/kustomization.yaml
    • Problème : stockage des credentials dans le repository.
    • Solution : utilise plutôt du chiffrement et/ou le Secret Manager du Cloud Provider.
    • Code :
      • configMapGenerator:
  - name: grafana-config
    literals:
      - GF_SMTP_ENABLED=true
      - GF_SMTP_HOST=<redacted-for-blog-post>
      - GF_SMTP_USER=<redacted-for-blog-post>
      - GF_SECURITY_ADMIN_USER=admin  
      - GF_SECURITY_ADMIN_PASSWORD=TuEsPlutotChoucrouteOuPaella?
  2. Mise à jour du module Terraform EKS :
    • Fichier : eks/fargate/terraform/main.tf
    • Le type d'instance à la demande pourrait générer un coût plus élevé, vérifie si tu veux vraiment changer de SPOT à ON_DEMAND.
    • Code :
      • module "eks" {
  ...
  node_group = {
    ...
    capacity_type  = "ON_DEMAND"
    ...
  }
  ...
}
  3. Taille de l'instance :
    • Fichier : eks/fargate/terraform/tfvars/aws-exploit.tfvars .
    • Passer de t3a.medium à t3a.xlarge pourrait être surdimensionné, vérifie la capacité requise et ajuste en conséquence.
  4. Utiliser des versions spécifiques des images :
    • Fichier : manifests/sockshop/values/aws-exploit/values.yaml .
    • L'utilisation de tags latest peut amener des instabilités, toujours préférer des versions spécifiques.
  5. .gitlab-ci.yml Chemin d'accès :
    • Le chemin d'accès pour inclure .gitlab-ci.custom.yml a été modifié et doit commencer par ./ pour maintenir la cohérence avec les autres inclusions.
    • Code :

      • include: - .gitlab-ci.custom.yml .

Signé,

BotSecOps

Merci pour le travail déjà effectué !

⭐ 🌟 🎉 Wow wow wow ! 🎉 🌟 ⭐ 

Par où commencer ? 😱

  1. Il a vu qu’un mot de passe était en clair dans un fichier → No Bueno.
  2. Il a vu qu’on bascule de SPOT à ON_DEMAND, ce qui a un impact tarifaire.
  3. Idem pour les types d’instances.
  4. Il a même compris que notre DevOps n’avait pas suivi les précédentes conventions pour poursuivre des inclusions dans un fichier YML.

Dois-je rappeler que cette revue de code est :

  • Systématique ?
  • Coûte quelques centimes d’API chez le provider d’inférence ?
  • Commente les aspects les plus saillants de notre merge request composée de +50 fichiers modifiés pour +2000 lignes de code ajoutées ?
  • A pris quelques secondes à générer et être postée ?
  • Et qu’elle peut être complétée par une autre revue de code par un humain ?

Personnellement, je suis hyper enthousiaste, et c’est une démarche que nous souhaitons généraliser.

Comment ça marche ?

Rien de fou. Le prompt ressemble à ceci :

Tu es un sorcier harry DevOps. Tutoie ton interlocuteur. Pas la peine d’être pédant, garde tes phrases concises, on est des experts. N’oublie pas de remercier ton interlocuteur, on n’est pas des ours 🐻. Ton rôle est de faire la revue de code d’une merge request dont voici les informations : Titre : <titre de la MR> Description : <description de la MR> Auteur : <auteur de la MR> Contente toi d’écrire un commentaire en format markdown, c’est moi qui me chargerai de le poster automatiquement dans la MR. Voici nos conventions de code : <lui donner ici toutes nos conventions. Par exemple : on nomme tous nos objets en camelCase, on utilise que des modules Terraform pour ceci ou cela, ou on ne déploie que les soirs de pleine lune au milieu de 12 statuettes enroulées dans du jambon> Voici le git diff : <concaténation du git diff>

Il ne reste plus qu’à enrober tout ça dans de l’event driven afin de systématiser l’invocation de l’agent dès qu’une merge request est postée par un DevOps 🙂.

Cas d’usage #2 - Le Changelog

Maintenant que vous avez compris le concept, ça va aller beaucoup plus vite, car on va le recycler.

Il s’agit toujours de fournir un service systématique par-dessus les merge requests, mais cette fois-ci en générant des changelogs.

Jusqu’ici, les changelogs étaient générés :

  • Manuellement, par quelqu’un qui a envie de lire tout le code source modifié et de le traduire en langage naturel.
  • Automatiquement, si tous les développeurs respectent un certain nombre de conventions contraignantes.

Si tu es dans le premier cas, merci à toi, tu as notre reconnaissance éternelle.

Si tu es dans le second cas, tu sais de quoi je parle quand j’évoque des conventions contraignantes.

Pour que la génération de changelog automatisée fonctionne, il faut :

  1. Respecter les conventions dans la rédaction de messages de commit.
  2. Nommer les branches de développement correctement.
  3. TOUJOURS le faire. Tu n’as pas le droit à l’erreur, tu n’as pas le droit de faiblir.
  4. Non vraiment, toujours. Ce n’est pas parce que tu testes un truc pour la 50ᵉ fois que tu auras le droit de commit “test” la 51ᵉ fois.

Et s’il existait une autre possibilité ? C’est ici que la GenAI intervient.

Démo

DevOps Bot 🤖 a écrit le commentaire suivant dans la Merge Request :
  • Mise à jour de la version du générateur de configuration CI de 2.16.3 à 2.17.1.
  • Correction dans le fichier .gitlab-ci.yml pour inclure correctement le chemin .gitlab-ci.custom.yml avec un slash devant.
  • Ajout de nouvelles tâches Helm dans le fichier .gitlab-ci.helm.aws-exploit.yml pour les environnements aws-exploit.
  • Suppression des tags steampipe du fichier .gitlab-ci.templates.yml.
  • Mise à jour de l'EKS de terraform pour utiliser des instances de type ON_DEMAND au lieu de SPOT et mise à jour de la version du cluster de 1.21 à 1.28.
  • Mise à jour des types d'instance de t3a.medium à t3a.xlarge dans eks/fargate/terraform/tfvars/aws-exploit.tfvars.
  • Ajout de variables d'environnement GF_SECURITY_ADMIN_USER et GF_SECURITY_ADMIN_PASSWORD pour Grafana.
  • Introduction de la gestion d'état (StatefulSet) pour Grafana dans le namespace monitoring.
  • Création de nouvelles ressources Helm pour l'application sockshop, comprenant des Deployment, Service, Ingress, et autres objets Kubernetes.
  • Ajout d'une nouvelle configuration Helm pour aws-exploit dans manifests/sockshop/values/aws-exploit/values.yaml avec divers ajustements de configurations.

Ce changelog a été généré par une IA. Il n’a quasiment rien coûté, il est systématique à chaque merge request, mais surtout :

Il ne nécessite pas que les dev respectent quelconque convention.

L’agent s’est simplement basé sur le git diff, il s’est donc paluché tout le code source pour traduire en langage naturel la synthèse des modifications apportées. DevOpsBot, tu as notre reconnaissance éternelle ❤️.

Comment ça marche ?

Tout pareil au premier cas d’usage, mais au lieu de lui demander une revue de code, on lui demande un changelog.

Allez, salut !
Allez, salut !

Conclusion

Vive la GenAI ! Pour quelques poignées de centimes de frais d’API, nous proposons désormais à nos clients des revues de code systématiques et qualitatives, ainsi que des changelogs exhaustifs.

Quelle signification pour un acteur comme Skale-5 ?

Faisons un peu de math. Même si toutes les merge requests ne sont pas comparables, et même si tout le monde ne travaille pas à la même vitesse, je vous propose les hypothèses suivantes :

  • 1 revue de code = 5 minutes.
  • 1 changelog = 5 minutes.

Plutôt fair, non ? Je dirais même : conservateur ! Ne vous fatiguez pas à estimer finement ces activités, car ce qui va réellement compter, c’est le passage à l’échelle, soit le nombre moyen de merge request concernées par an.

Chez Skale-5, nous pensons que ce nouvel usage va nous permettre de produire plus de 100 JIA (Jours IA) en 2024.

👉 Rendez-vous la semaine prochaine pour découvrir un nouvel use case GenAI for DevOps ! 👈

💡
Si ces use cases vous intéressent, programmez une démo ! Le virage de la GenAI est déjà entamé, et nous pouvons les déployer chez vous.

Merci pour votre lecture. Cet article vous a plu, partagez sur vos réseaux 😉

Hugo Claria - Le 6 février 2024

image

Le bisous promis est ici 🙂 → 💋