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

Je vous propose aujourd'hui de partager avec vous un retour d'expérience concernant les SGBDs. Après des années à jouer avec de multiples solutions, il y a un point qui me fait presque toujours préférer SQL Server à d'autres solutions. Il s'agit de la problématique des montées de version.

Oui, c'est beau d'avoir un super projet, avec une base de données que l'on maitrise sur le bout des doits.

Mais que se passe-t-il après quelques années ? Votre SGBD, et la méthode utilisée pour l'héberger vous permettent-ils de ne pas avoir de coupure de service ? Mon équipe a les compétences pour ce travail ?

Vous ne savez pas... ou du moins vous pensez que "ça va bien se passer, car tout le monde utilise cet outil".

La problématique

Aujourd'hui, il y a trois solutions majeures pour disposer d'une base de données :

• Service Cloud.
• Kubernetes on-premise, ou Cloud (AKS, GKS,...).
• On-premise.

Chacun va avoir son processus pour la mise à jour, et nécessite que votre équipe le maitrise. Pour la suite de cet article je vai comparé SQL Server à PosgreSQL, car ce sont les SGBD. Mes motivations sont simples :

• J'ai l'expérience de ces deux SGBD dans l'intégralité des cas présentés aujourd'hui.
• Ce sont les seuls qui trouvent grâce à mes yeux ;)

Oui, même si je préfère m'appuyer sur SQL Server, j'apprécie beaucoup PosgreSQL.

On-premise

Commençons par l'approche historique, le "on premise" :

• SQL Server : coupure du service, on lance le setup, et on se laisse guider.
• PostgreSQL : coupure du service, on lance un script, et on se laisse guider.

Sur SQL Server, si vous avez un super DBA vous pouvez monter une architecture "zero downtime". Mais ce n'est pas donné, et il faut avoir les compétences.

Sur PostgreSQL, les solutions de sync / cutover sont possibles, là encore, il faut un bon DBA, car il y a des subtilités concernant les LOBS, et les séquences.

Kubernetes

C'est certainement sur Kubernetes qu'il y a le plus de différences. Par défaut, si l'on prend les images de bases et que l'on suit la documentation :

• SQL Server : zéro coupure.
• PostgreSQL : coupure du service, exécution d'un script.

Mais si on utilisé CloudNativePG pour sont déploiement de PostgreSQL, on peut effectuer des montés de versions sans coupure de service. Si vous utilisez déjà PostgreSQL sans CloudNativePG, il est possible de procédé à une migration du style sync /cutover (comme on-premise, il faut avoir un bon DBA sous la main).

Si vous ne connaissez pas CloudNativePG, prenez 5 minutes pour aller sur ce site. Cela vaut vraiment le détour. Ensuite, vous ne déploierez plus jamais PostgreSQL autrement ;)

Cloud

Sur le Cloud, là où le SAAS est roi, tous les SGBD ne sont pas logés à la même enseigne :

• SQL Server : Sur Azure, on utilise toujours la dernière version. Il n'y a donc pas d'upgrade à gérer.
• PostgreSQL : Azure, AWS, et GCP permettent de faire des montés der version. Mais il y a toujours une période d'indisponibilités des bases de données.

La seule solution pour approcher d'un upgrade sans coupure est donc de disposer d'un très bon DBA. Celuic- aura la charge de vous monter un plan de sync / cutover entre deux instances. Il faut donc des compétences, et consommer un peu plus de services cloud le temps de l'upgrade.

Conclusion

Seul SQL Serveur fourni des expériences d'upgrade sans coupure de service, sans rien avoir à configurer (Cloud, et K8S). Le nombre de compétences utiles est alors réduit.

Voilà pourquoi j’apprécie autant avoir à maintenir des projets qui utilisent SQL Server ;)

Dès que l'on parle DevOps, et qualité, on s'attends à vir arriver la grosse artillerie. Des solution couteuses, et/ou compliquées.

Fort heureusement avec Azure DevOps, il existe une solution simple et qui fonctionne "out of the box"

Il s'suffit d'activer la couverture de code lors des builds. En plus de rapports très complets, la première page de ceux-ci fourni une indication sur les méthodes qui peuvent poser problèmes (crap code , complexités).

Simple à mettre en place, et rapide à prendre en main.

Bien évidemment, vous n'avez pas tous les raffinements d'un NDepend, ou d'un Sonar mais c'est un début, et cela ne coute rien.

Je profite de cet article pour mettre en avant un petit warning, dont la description est très peu parlante sortie de son contexte :

CS9113: Parameter is unread.

Celui-ci concerne une classe qui utilise un constructeur principal. L'un des arguments du constructeur n'est pas utilisé. Il peut donc être supprimé.

Petite référence vers la documentation : Resolve errors related to constructor declarations and module initializers - C# reference | Microsoft Learn

En soi, rien de bien compliqué. Mais je trouve la description "CS9113: Parameter is unread" un peu courte. Dans mon cas, je venais de modifier le code concerné. J'ai donc vite compris l'origine du problème. Hors contexte, j'aurai préféré une description un peu plus longue comme le "CS0168: The variable 'var' is declared but never used".

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.