Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Je souhaiterais aborder aujourd'hui un sujet qui me trotte dans la tête depuis quelques mois : le rôle des Pull Requests en entreprise à l'ère de l'IA.

Spoiler alerte :

Contrairement à mes mauvaises habitudes, je ne donnerai pas mon avis définitif avant la conclusion. Il va donc falloir lire cet article pour comprendre (article rédigé sans IA, un véritable article Bio… na!)

Un petit regard dans le rétroviseur

Pour être parfaitement honnête avec vous, je dois commencer par un petit avertissement. Je n'aime pas les Pull Requests (PR) en entreprise. Je comprends parfaitement leur rôle dans le domaine de l'Open Source, où les contributions doivent rester sous contrôle pour éviter toute dérive du projet, ou tout acte malveillant (même si par le passé, des projets se sont fait pirater malgré les PR).

En entreprise, chacun partage un objectif commun. Forcer l'usage des PR peut avoir des effets pervers :

• Déresponsabilisation.
• Goulot d'étranglement.
• Nivellement de l'équipe vers le bas … (déjà vécu du fait d'une personne qui avait pris l'ascendant sur l'équipe, mais qui n'avait pas le niveau technique attendu).
• Livraisons retardées du fait de PR en attente depuis trop longtemps…et devenues difficiles à fusionner

Un grand pas en avant

Mais avec l'arrivée des Agents IA, il faut bien revoir sa copie. On ne peut pas permettre à une IA de pousser du code sans contrôle.

Deux cas se présentent à nous :

• On utilise exclusivement les agents sur son PC. On doit alors valider localement la branche modifiée avant de demander sa  fusion (ex : VS Code Agents…. j'adore!!!! )
• On utilise une solution déportée comme GitHub Copilot, et ses agents cloud. On doit alors valider les PR émises par les agents.

Le second scénario ne serait pas envisageable sans PR. Même moi, je suis enchanté d'utiliser la PR de la sorte. J'étais comme un gamin quand j'ai vu ma première PR proposée par GitHub Copilot.

Le danger imprévisible (ou pas)

Il y a un élément que je n'avais pas envisagé…

Aujourd'hui, avec l'habitude, j'ai appris à réduire les codes, et commentaires inutiles produits par l'IA. Plus, tout ce que l'on a tendance à classer dans la catégorie "Slop". L'IA me fait perdre moins de temps que par le passé. Oui, au début, je perdais du temps en utilisant l'IA, je n'ai pas honte de le dire. Mais je ne m'attendais pas à ce que l'on utilise volontairement l'IA pour générer du Slop. À ma grande surprise, il existe maintenant une tendance dite du Workslop. Pour certain, le Workslop est involontaire, pour d'autres, il l'est.

Et là,… mon monde s'effondre. La PR peut devenir plus chronophage que jamais à cause des personnes qui vont utiliser l'IA.

Conclusion

Oui, la PR peut présenter un grand intérêt en entreprise. Mais il va falloir recadrer son usage :

• Limiter sa portée.
• Limiter le nombre de lignes, et de classes impactées.
• Ne pas limiter la validation des PR à un seul groupe de personnes, ou à une seule personne.

On notera que j'ai fait un très gros effort pour ne pas parler de Vibe Pull Request. Mais le vrai danger est là.

Avez-vous, vous aussi, la fâcheuse tendance de partager le code que l'IA a généré pour vous sur LinkedIn ?

Si tel est le cas, arrêtez tout de suite.

Pourquoi ?

Partager ce code, c'est un peu comme partager une photo de la dernière bêtise de vos enfants, ou toute autre absurdité que vous ou votre entourage risquez de trainer à vie comme de grosses casseroles.

… Oui j'annonce la tonalité de cet article. Certain le prendront pour un coup de guelfe, d'autre pour une mise en garde. Je pense que la vérité se trouve un peu entre les deux.

Mes observations

LinkedIn est un formidable outil de communication. Mais certains en font un peu trop quand il s'agit de parler de l'IA, ou de son usage. On nous parle :

• D'applications professionnelles réalisées en un jour.
• De juniors qui font le travail de trois séniors en un jour avec une qualité de code exceptionnelle.
• De pipelines de CI/CD qui s'écrivent tout seuls.
• De repos git qui voient le nombre de leurs commits quotidiens multiplient par 100 depuis que l'IA est utilisée.
• D'agents qui découvrent des bugs.
• D'agents qui résolvent des problèmes insolubles.
• etc.

Il y du vrai, et un parfois peu d'esbroufe. Mais il a aussi ce moment exceptionnel, où certains partagent un code, un lien vers un repos, ou une vidéo : “l'IA nous a permis d'écrire le code le plus innovant qui soit !”

Et là, c'est le drame :

• Anti-patterns à gogo.
• Boucles imbriquées.
• Multiples conventions de nommages.
• Nommage des variables incomprehensible.
• Librairies obsolètes.
• Dépendances qui font double usage.
• Documentation des entêtes de méthode inutilement verbeuse.
• Méthode inutilisée.
• Doublons.
• Secrets dans le repos.
• Beaucoup de commit inutiles pour faire un pas en avant, et deux pas en arrière.
• etc.

Tout ce qu'un développeur expérimenté n'a pas envie de voir.

Pour faire simple :

Un code tout neuf, et déjà considéré comme "legacy".

Conclusion

Utiliser l'IA, c'est sympa. Mais il faut savoir la dompter, et cela ne se fait pas en cinq minutes.

Pour les développeurs qui manquent peut-être un peu d'expérience, je recommande vivement de doubler l'usage de l’IA avec de vraies vraies recherches, et d'utiliser des d'outils fiables pour valider le code produit.

Pour le développeur .net, on se rappellera que :

• Microsft Learn peut être utilisé par l'IA comme source de vérité.
• L'IA peut suivre et respecter facilement un TDD (avec Moq, solutions d'injection fournies en standard par .net, et tests d'intégrations).
• Code Analysis est obligatoire
• NDepend est le "must have" si vous voulez être en mode "ceinture et bretelle".

Plus les règles applicable à tout language.

• Le code produit par l'IA doit compiler sans warnings.
• 100% du code produit doit être relu avant fusion.

Depuis sa version 7.15.2, OAuth2 Proxy dispose d'un nouveau flag permettant de renforcer sa sécurité : --trusted-proxy-ip. Celui-ci définit les reverse-proxy autorisés à envoyer des entêtes X-Forwarded-*. Ce flag doit être renseigné avec des IPs, ou une plage d'IP.

Dans le cas d'un cluster Kubernetes, les reverse-proxy à autoriser sont fournis par les Ingress, ou Gateway API. Pour connaitre les IPs, il faut donc interroger son cluster afin d'obtenir la plage d'IP affectée aux pods d'Ingress / Gateway API.

Par exemple : sur un cluster RKE2 utilisant Traefik, les pods intéressants sont dans le namepace kube-system. On peut utiliser la commande suivante pour obtenir la liste des pods avec leurs IPs :

Pour Windows

kubectl get pod -n kube-system -o wide | Select-String traefik

Pour Linux

kubectl get pod -n kube-system -o wide | grep traefik

Exemple de sortie :

helm-install-rke2-traefik-xxx1 0/1     Completed   0                3d5h   10.42.3.44    xx1    <none>           <none>
helm-install-rke2-traefik-xxx2 0/1     Completed   0                3d5h   10.42.0.117   xx2    <none>           <none>
rke2-traefik-xxx1                       1/1     Running     0                3d5h   10.42.3.88    xx1    <none>           <none>
rke2-traefik-xxx2                       1/1     Running     0                3d5h   10.42.0.120   xx2    <none>           <none>
rke2-traefik-xxx3                       1/1     Running     0                3d5h   10.42.2.107   xx3    <none>           <none>
rke2-traefik-xxx4                       1/1     Running     0                3d5h   10.42.1.232   xx4    <none>           <none>

On peut en conclure que les Ips utilisées seront sur la plage 10.42.0.0/16.

Dans le fichier de déploiement de OAuth2 Proxy il suffit d'ajouter la variable d'environnement OAUTH2_PROXY_TRUSTED_PROXY_IPS avec la valeur 10.42.0.0/16.

Exemple :

env:
  # Reverse proxy
  - name: OAUTH2_PROXY_REVERSE_PROXY
    value: "true"
  - name: OAUTH2_PROXY_TRUSTED_PROXY_IPS
    value: "10.42.0.0/16"

Depuis plusieurs mois, la communauté Kubernetes s'agite autour de Geteway API, et de différentes annonces de dépréciation des Ingress. On nous vente les mérites de la Gaeway API. On nous explique comment déclarer les Gateway, et les routes. Mais rarement on répond aux questions du monde réel.

Mon constat

À force d’en discuter, je me suis rendu compte qu'il y avait quelques sujets qui n'étaient pas clairs pour tout le monde.

Par exemple :

• Oui, on peut faire cohabiter Ingress, et Gateway API.
• Oui, il y a des produits qui fournissent à la foi Ingress, et GateWay API.
• Non, les Ingress ne vont pas disparaitre (du moins cela n'a pas encore été annoncé).
• Non, la totalité des templates Helm ne supporte pas Gateway API (cela risque de prendre un peu de temps avant que la communauté ne change ses habitudes… et ce, même pour les projets maintenus par de grands éditeurs).
• Non, tous les contrôleurs ne supportent pas tout Gateway API.

En pratique

Personnellement, j'ai opté pour une démarche s'inscrivant dans le temps (oui, désolé, je ne maintiens plus de cluster pro, juste mes clusters pour mes usages personnels, RKE2 /AKS). Ne pouvant passer un temps fou à gérer la bascule, et ne pouvant la faire en une foi, j'ai opté pour une démarche par itérations sur plusieurs mois. La totalité des applications reste disponible durant toute la durée des opérations.

1. Installer un cluster de test pour valider la cohabitation Ingress / Gateway API, et choisir l'outil idéal (le nouveau contrôleur d'Ingress dans un premier temps).
2. Tester, tester, tester (galérer, galérer, galérer jusqu'à trouver le contrôleur d'Ingress qui fait aussi très bien de la Gateway API).
3. Installer la solution miracle sur le cluster de production.
4. Basculer les Ingress existants vers le nouveau contrôleur d'Ingress.
5. Supprimer l'ancien contrôleur d'Ingress.
6. Déclarer une, ou plusieurs Gateway.
7. Basculer progressivement les applications d'Ingress vers HttpRoute (utiliser une solution GitOps comme Argo CD, pour se simplifier la vie).
8. Identifier les templates Helm qui ne supportent pas Gateway API. Supprimer les Ingress intégrés aux templates, et déclarer des Ingress custom (là encore GitOps "est ton ami"). Personnaliser les Ingress si besoin (pour l'authentification par exemple), puis les remplacer par des routes.

Dans mon cas, j'ai choisi Traefik. Venant de Haproxy, je n'étais pas concerné par la problématique de dépréciation de nginx. Mais j'ai préféré Traefk pour une raison simple : contrairement aux autres contrôleurs d'Iingress qui privilégient les annotations, Trafik sait utiliser des CRD (middleware). Ces middlewares peuvent être utilisés avec Ingress, et Gateway API. Autre avantage, les middlewares peuvent être partagés entre Ingress, et namspaces. J'ai donc créé quelques middlewares pour inclure une authentification, et pour personnaliser quelques entêtes HTTP.

Après avoir compris comment convertir une annotation du contrôleur d'Ingress précédent vers le middleware, il n'y avait plus rien à faire. Horsmis binder les middlewares vers mes nouveaux Ingress. Lors de la migration, le middleware était conservé, et associé à la nouvelle route. Seul l'Ingress disparaissait.

Conclusion

Il y a certainement d'autres approches possibles. Celle-ci me semble intéressante, car elle privilégie la stabilité, la sécurité, et la confiance. À aucun moment on ne peut ressentir l'impression d'avoir une épée de Damoclès au-dessus de soi. À aucun moment, on ne court le risque de perdre une fonctionnalité qui n'est pas encore supportée par Gateway API. Plus important encore, à aucun moment on ne reste avec un contrôleur d'Ingress déprécié en production.

La qualité de code a toujours été un sujet épineux. Nombre de sociétés qui ne s'y sont jamais vraiment intéressées, et qui veulent soudainement sauter le pas, passent d'un outillage quasi inexistant à un outillage qui finit par décourager les développeurs.

Dans une démarche DevOps, ceci n'est pas envisageable. Heureusement, il existe un juste milieu. Du moins, un bon outil dédié à la qualité de code est censé nous permette d'avoir le contrôle sur les règles appliquées (sélection, affichage, documentation, aide à la résolution...). Avant de mettre en place un tel outil, il faut donc prendre un peu de temps pour découvrir ses possibilités, et vérifier qu'elles sont bien en adéquation avec le besoin. Ceci ne se fait pas en 5 minutes, car plus on a de projets, et de technologies différentes, et plus on a de prérequis à valider.

La solution 100% .net

En attendant, pour les développeurs .net il est possible d'améliorer la qualité de son code sans installer quoi que ce soit. Il suffit de configurer Code Analysis. La fonctionnalité n'est pas nouvelle, mais je suis toujours étonnée de rencontrer des développeurs ne la connaissant pas.

En pratique

Pour profiter de Code Analysis pour la totalité des projets d'une solution, le plus simple consiste créer un fichier Directory.Build.props à côté de sa solution, et d'y glisser les propriétés suivantes (pour forcer l'analyse lors de la build) :

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
<AnalysisMode>minimum</AnalysisMode>

On peut ensuite jouer avec la propriété AnlasysisMode comme spécifié ici : Code analysis in .NET | Microsoft Learn

La documentation peut aussi vous permettre de choisir des règles à appliquer au cas par cas.

Pour aller un peu plus loin

Si vous n'avez jamais utilisé Code Analysis, il ne faut pas avoir peur de procéder par paliers. Dans un premier temps on peut choisir un niveau minimum. Dès que la solution est conforme, on peut passer au niveau suivant.

Personnellement, je préfère ne pas casser la build alors qu'une équipe adopte Code Analysis. J'opte donc pour une solution en deux temps :

1. La compilation en mode Release doit se faire avec un niveau de règle accepté par tous.
2. La compilation en mode Debug peut se faire avec un mode un peu plus exigeant.

De la sorte, lors de leur travail quotidien, les développeurs ont un IDE qui leur remonte des warnings pour les encourager à améliorer le niveau de qualité du projet. Attention : on parle de quelques warnings, pas des milliers. Il ne faut pas décourager les développeurs.

Exemple de configuration possible pour cela :

<PropertyGroup Condition="$(Configuration)=='Debug'">
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisMode>recommended</AnalysisMode>
</PropertyGroup>
<PropertyGroup Condition="$(Configuration)=='Release'">
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisMode>minimum</AnalysisMode>
</PropertyGroup>

Les plus téméraires voudront peut-être ajouter un EnforceCodeStyleInBuild. C'est une histoire de gouts. Mais attention, il faut que l'équipe adhère à cette pratique. Il ne faut pas qu'elle le subisse. Faute de quoi, le niveau de qualité ne pourra pas augmenter.

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>