Forem: Jérémy Chauvin

Git hooks: not everything is worth blocking for

Jérémy Chauvin — Thu, 30 Apr 2026 21:09:22 +0000

Git hooks are a practice we see more and more in projects. We often adopt them because we've seen them elsewhere, or because they seem like a good idea to ensure code quality. But is that really the case?

Before going further, let's explain what a git hook is. With git, you can run scripts when you want to create a commit, push, etc. (pre-commit, pre-push, etc.).

💡 Husky is a great tool to discover and create your first hooks

By using a pre-commit hook, when you run the "git commit" command, a script is executed. If it fails, the commit is cancelled. You're then forced to fix the problem before you can commit.

To make collaboration easier within the team, you might think "Great, I'll be able to check that":

all my tests pass
my linter passes
my formatter passes
my commit name follows conventions

That's where the problems start. Because yes, the feedback will be faster, but at what cost?

A commit is not a delivery

With hooks, we run tests, the linter, the formatter, and commit name validation every time we want to commit. Making a commit becomes slow and frustrating. We're in our flow, we've made progress on our feature, and we have to wait for everything to pass before we can share our work.

And what happens in the end? If we end up bypassing hooks with --no-verify, it's to get back to a fast dev flow.

💡 Git has a --no-verify option on its commands to skip hooks

The other problem is that hooks push us toward "perfect" code at every commit. But a commit is not a delivery. Let's take a concrete example: we're working in TDD, we've just written a red test that describes the behavior we want to implement. We want to commit this test before moving on to the implementation. Except the pre-commit hook runs the build or the linter or the type check, it fails, and the commit is blocked. We're forced to either implement right away or use --no-verify. The red-green-refactor cycle, which relies precisely on intermediate states, becomes painful.

That's the whole point of a commit: saving a state so we can go back if needed. With overly strict hooks, we're asked for perfect code at every save. We lose that freedom.

And the problem doesn't stop at the commit. Even when the pre-commit hook is limited to lint and build, we often find tests in a pre-push hook. Result: we can commit locally, but can't push until the tests pass. If we're doing pair or mob programming and want to share a work-in-progress state, it's blocked. If we need a colleague's opinion on an approach before continuing, it's blocked. We fall back into the same logic: "perfect" code just to be able to collaborate.

And that's not the only problem...

Double pain, zero gain

The other issue we create with hooks is duplication. The same checks run locally via hooks, then a second time in the pipeline (GitHub Actions, GitLab CI, etc.). We wait for the hooks to pass, then wait for CI to run the exact same thing. We don't save time, we lose it.

And it's not just a matter of time. We end up maintaining checks in two places: the hook config and the pipeline. We update an option in a command on the CI side but forget to do it on the hook side, or vice versa. The two diverge, and we only notice when something breaks.

On top of that, we risk falling into the "it works on my machine" trap, or the exact opposite. The local environment and CI are not the same thing. Tool versions, dependencies, config... there are many reasons the result could be different. We add cognitive load trying to understand why it passes locally but fails in the pipeline, or vice versa.

Ultimately, it's the CI that decides whether we can merge or not. It's the source of truth. If we trust it to block a merge, why duplicate that work locally?

But then, if hooks cause so many problems, why do we keep using them?

What we're really compensating for

The real problem is our CI's feedback loop. The pipeline takes 20 minutes, we don't get any notification on failure, and most importantly, everything stays very opaque. Because we have one big step that mixes a bunch of things, and to find out what broke we have to dig through logs. It's frustrating.

Hooks are a response to that frustration. We want faster, clearer feedback, closer to us. And that makes sense.

In any case, hooks are a band-aid, not a solution. We're treating the symptom but not the cause. The real question isn't "how to get faster feedback locally", it's "why is my feedback slow and unclear in the first place".

If the pipeline takes 20 minutes, adding hooks locally doesn't make the pipeline faster. We've just moved the problem. The day the hook passes but CI fails, we're at the same point as before, except we've wasted more time.

And if CI feedback isn't clear, it's rarely a tooling problem. It's often that we have one big step doing too many things, that errors are buried in logs, that nobody took the time to make it readable. Hooks don't solve any of that.

The real question is: how do we reduce the feedback loop time and make it clearer when it fails. And the answer is rarely "add another layer locally". So what do we do?

Fixing the source

Rather than compensating locally, we should invest in the Developer eXperience of our pipeline.

First, split CI into clear, parallelized steps. One step for lint, one for tests, one for the build. If lint fails, we see it immediately — no need to dig through logs of a monolithic step. And if steps run in parallel, we reduce total time.

Next, have notifications when CI fails. We shouldn't have to manually check whether the pipeline passed. A Slack message, an email, a GitHub notification... whatever, but we need to know quickly.

And finally, make errors readable. When something fails, we should understand why in a few seconds, not after 5 minutes of reading logs. It's a one-time effort that benefits the whole team, unlike hooks which remain an individual solution.

💡 If you still want a hook while improving CI, lint-staged lets you run formatting and linting only on staged files, with automatic fixing. It doesn't block the flow — it's an acceptable compromise during the transition.

But be careful not to put everything in the hook. Formatting and linting work well in pre-commit because they're fast and auto-fixable: run, fix, move on. Secret detection is another legitimate case: if CI catches it, it's already too late — the secret is in the git history. The pre-commit hook is the only place where blocking makes sense. Tests are different. They're slow, they fail for legitimate reasons (a red test in TDD for example), and they have nothing to auto-fix. Putting them in a hook, whether pre-commit or pre-push, is falling back into the problem we're trying to solve: blocking the flow to force "perfect" code before being able to collaborate. Tests are CI's job.

But with the arrival of AI agents, the problem takes on a whole new dimension.

AI amplifies the problem, the commit changes its role

With AI, the commit is no longer just a save — it's a supervision mechanism. AI moves fast, it touches many files, and we don't read every line in real time. We need small increments to stay in control: reviewing a readable diff rather than 20 files changed at once, doing a precise revert if the AI goes in the wrong direction. The faster the AI goes, the more we need to commit often. And the more we commit, the more hooks become a bottleneck. It's a paradox: the tool meant to "ensure quality" is precisely what prevents the mechanism that lets us control the quality of the AI's work.

And when a developer uses --no-verify, you might think they're in a rush or being careless. But when an AI — with no ego, no impatience, no laziness — also bypasses hooks, that says something else. Concrete example: we ask the AI to add a field to a form. An unrelated test fails in the pre-commit hook. The AI can't commit. We told it not to touch the tests. But the hook blocks it. So it does what a dev would do: it works around it. It adds code to make the test pass without directly modifying it, or it uses --no-verify. The result: the AI spirals, code quality degrades, and we end up having to revert everything because we couldn't commit before things went off the rails. If even an emotionless agent bypasses hooks, the mechanism is the problem, not the people.

Yet, we still want the AI to run tests, to check the lint. The problem isn't the checks — it's that git hooks are a single mechanism for two actors with opposing needs. Humans want freedom: commit an intermediate state, try something, go back. AI needs checks, but adapted to it, with feedback we control.

The AI still needs to actually run those checks, though. With Claude Code for example, you can write instructions in the project's CLAUDE.md that the agent follows every session, like "run tests after every modification". And if the conversation context gets compacted and instructions might be lost, you can put them in a dedicated skill to make sure they're always there.

The remaining question is: what happens when it fails? That's where it gets interesting. Tools like Claude Code offer lifecycle hooks internal to the agent: you can configure a script that runs when a command fails (for example tests), and that injects context into the agent's conversation. Concretely, when tests fail, instead of blocking the commit, the hook guides the AI: "Analyze whether this failure is related to your changes. If yes, fix it. If not, inform the developer." It's not a rigid rule, it's guidance. The AI receives the context and makes a judgment. If the failing test is directly related to what it just modified, it fixes it on its own and continues. If it's an unrelated test, it commits to save the current state and informs us: "This test failed but it has nothing to do with my changes. Want to look at it together?"

The git hook applies a blind rule — it passes or it blocks, for everyone, without distinction. The agent hook provides context and leaves judgment to the AI, while returning control to the developer. And it doesn't stop at local: the agent can also react to CI events, receive a failure notification, and analyze or fix the error automatically.

Concretely, with Claude Code, it looks like this in the project's .claude/settings.json:

{
  "hooks": {
    "PostToolUseFailure": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(npm run test|vitest)",
            "command": "echo '{\"additionalContext\": \"Some tests failed. Analyze whether these failures are related to your changes. If yes, fix them. If not, commit your changes and inform the developer about the failing tests unrelated to your work.\"}'"
          }
        ]
      }
    ]
  }
}

The hook only triggers when npm run test or vitest fails. It doesn't inject a rule — it injects context that the AI uses to decide on the course of action.

💡 To go further on Claude Code hooks (PostToolUseFailure, additionalContext, matcher, etc.), the full documentation is available here: https://code.claude.com/docs/hooks-guide

One tool, multiple contexts

What I'm describing here applies to a specific context: a team in a company, with CI, and developers who work together daily. In this setting, hooks compensate for a problem we have the means to solve differently.

But git hooks didn't come from nowhere. They were designed for projects where contributors are numerous, at very different skill levels, and where nobody has a grasp on the entire project. That's exactly the case with open source.

On an open source project, the constraints are different. Contributors don't necessarily know the project's conventions, they have very different local setups, and they sometimes only contribute once. An occasional contributor who opens a PR isn't going to spend 20 minutes figuring out why the pipeline failed. If a hook fixes their formatting and flags a lint error before they even push, that's time saved for everyone: for them and for the maintainers who review.

In this context, hooks don't compensate for a bad CI. They serve as an accessible safety net that reduces noise in PRs and accelerates feedback for people who might only contribute once. It's a legitimate use, and that's why we find them in many well-maintained open source projects. Next.js, Angular, webpack, Storybook, NestJS, Prisma... all use hooks to run formatting and linting on staged files before each commit. Not tests, not the build. Just what's fast and auto-fixable.

Git hooks aren't a bad tool. In open source, they're a proven safety net. But in a company team, with CI and the means to invest in it, using them to compensate for a slow feedback loop is putting on a band-aid. The problem isn't local — it's in the pipeline. That's where we need to act.

Git hooks : tout n'est pas bon à bloquer

Jérémy Chauvin — Tue, 28 Apr 2026 06:01:05 +0000

Les git hooks, c’est une pratique qu’on voit de plus en plus dans les projets. On l’adopte souvent parce qu’on l’a vu ailleurs, ou parce que ça semble être une bonne idée pour garantir la qualité du code. Mais est-ce que c’est vraiment le cas ?

Avant d’aller plus loin, il faut expliquer ce qu’est un hook git. Avec git on peut exécuter des scripts lorsqu’on veut créer un commit, push etc (pre-commit, pre-push etc).

💡 Husky est un très bon outil pour découvrir et faire ses premiers hooks

En utilisant un pre-commit hook, lorsque l’on entre la commande “git commit”, un script est joué. Si celui-ci échoue, le commit est annulé. On est alors obligé de résoudre le problème afin de pouvoir commit.

Pour faciliter la collaboration dans l'équipe, on pourrait alors se dire "Super, je vais pouvoir vérifier que" :

que tous mes tests passent
que mon linter passe
que mon formateur passe
que le nom de mon commit respecte bien les conventions

C’est là que les problèmes commencent. Parce que oui, le feedback sera plus rapide, mais à quel prix ?

Le commit n'est pas une livraison

Avec les hooks, on lance les tests, le linter, le formateur et la vérification du nom de commit à chaque fois qu'on veut commit. Faire un commit devient lent et frustrant. On est dans notre flow, on a avancé sur notre feature, et on doit attendre que tout passe avant de pouvoir partager notre travail.

Et au final qu’est-ce qui se passe ? Si on finit par contourner les hooks avec --no-verify, c’est pour retrouver un flow de dev rapide.

💡 Git a une option --no-verify sur ses commandes pour ignorer les hooks

L’autre problème c’est que les hooks nous poussent vers du code “parfait” à chaque commit. Mais un commit ce n’est pas une livraison. Prenons un exemple concret : on travaille en TDD, on vient d’écrire un test rouge qui décrit le comportement qu’on veut implémenter. On veut commit ce test avant de passer à l’implémentation. Sauf que le hook pre-commit lance le build ou le linter ou le type check, ça échoue, et le commit est bloqué. On est forcé soit d’implémenter dans la foulée, soit de faire --no-verify. Le cycle red-green-refactor, qui repose justement sur des états intermédiaires, devient pénible.

C’est le principe même du commit : sauvegarder un état pour pouvoir revenir en arrière si besoin. Avec des hooks trop stricts, on nous demande du code parfait à chaque sauvegarde. On perd cette liberté.

Et le problème ne s’arrête pas au commit. Même quand le hook pre-commit se limite au lint et au build, on retrouve souvent les tests dans un hook pre-push. Résultat : on peut commit en local, mais impossible de push tant que les tests ne passent pas. Si on fait du pair ou du mob programming et qu’on veut partager un état de travail en cours, c’est bloqué. Si on a besoin d’un avis d’un collègue sur une approche avant de continuer, c’est bloqué. On retombe dans la même logique : du code “parfait” pour pouvoir collaborer.

Et ce n'est pas le seul problème…

Double pain, zero gain

L’autre problématique qu’on crée avec les hooks, c’est la duplication. Les mêmes vérifications tournent en local via les hooks, puis une deuxième fois dans la pipeline (Github Actions, Gitlab CI etc). On attend que les hooks passent, puis on attend que la CI relance exactement la même chose. On ne gagne pas de temps, on en perd.

Et ce n’est pas juste une question de temps. On se retrouve à maintenir les checks à deux endroits : la config des hooks et la pipeline. On met à jour une option dans une commande côté CI mais on oublie de le faire côté hooks, ou l’inverse. Les deux divergent, et on ne s’en rend compte que quand ça casse.

De plus, on risque de retomber dans le piège du "ça marche sur ma machine", ou justement l’inverse. L’environnement local et la CI ce n’est pas la même chose. Les versions des outils, les dépendances, la config... il y a de nombreuses raisons pour que le résultat soit différent. On se rajoute une charge cognitive en plus pour comprendre pourquoi ça passe chez nous et pas dans la pipeline, ou l’inverse.

Finalement, c’est la CI qui décide si on peut merge ou pas. C’est elle la source de vérité. Si on lui fait confiance pour bloquer un merge, pourquoi dupliquer ce travail en local ?

Mais alors, si les hooks posent autant de problèmes, pourquoi on continue à les utiliser ?

Ce qu'on compense vraiment

Le vrai problème c’est la feedback loop de notre CI. La pipeline prend 20 minutes, on ne reçoit aucune notification en cas d’échec, et surtout, tout reste très obscur. Car on a une grosse étape qui mélange plein de trucs et pour savoir ce qui a cassé on doit aller fouiller dans les logs. C’est frustrant.

Les hooks c’est une réponse à cette frustration. On veut un feedback plus rapide, plus clair, plus proche de nous. Et ça se comprend.

Dans tous les cas, les hooks c’est un pansement, pas une solution. On traite le symptôme mais pas la cause. Le vrai sujet c’est pas "comment avoir un feedback plus vite en local", c’est "pourquoi mon feedback est lent et pas clair à la base".

Si la pipeline met 20 minutes, rajouter des hooks en local ça ne rend pas la pipeline plus rapide. On a juste déplacé le problème. Le jour où le hook passe mais la CI échoue, on est au même point qu’avant, sauf qu’on a perdu du temps en plus.

Et si le feedback de la CI n’est pas clair, c’est rarement un problème d’outillage. C’est souvent qu’on a une grosse étape qui fait trop de choses, que les erreurs sont noyées dans les logs, que personne n’a pris le temps de rendre ça lisible. Les hooks ne résolvent rien de tout ça.

La vraie problématique c’est : comment réduire le temps du feedback loop et le rendre plus clair quand ça échoue. Et la réponse, c’est rarement "rajouter une couche en local". Alors on fait quoi ?

Réparer la source

Plutôt que de compenser en local, on devrait investir dans la Developer eXperience de notre pipeline.

Déjà, découper la CI en étapes claires et parallélisées. Une étape pour le lint, une pour les tests, une pour le build. Si le lint échoue, on le voit tout de suite, on n’a pas besoin d’aller fouiller dans les logs d’une étape monolithique. Et si les étapes tournent en parallèle, on réduit le temps total.

Ensuite, avoir des notifications quand la CI échoue. On ne devrait pas avoir à aller vérifier manuellement si la pipeline est passée. Un message Slack, un mail, une notif Github... peu importe, mais on doit le savoir rapidement.

Et enfin, rendre les erreurs lisibles. Quand ça échoue, on doit comprendre pourquoi en quelques secondes, pas en 5 minutes de lecture de logs. C’est un effort qui se fait une fois et qui profite à toute l’équipe, contrairement aux hooks qui restent une solution individuelle.

💡 Si on veut quand même un hook en attendant d’améliorer la CI, lint-staged permet de ne lancer le formatage et le lint que sur les fichiers stagés, avec correction automatique. Ça ne bloque pas le flow, c’est un compromis acceptable le temps de la transition.

Mais attention à ne pas tout mettre dans le hook. Le formatage et le lint fonctionnent bien en pre-commit parce qu’ils sont rapides et auto-corrigeables : on lance, ça corrige, on continue. La détection de secrets c’est un autre cas légitime : si la CI l’attrape, c’est déjà trop tard, le secret est dans l’historique git. Le hook pre-commit est le seul endroit où le bloquer a du sens. Les tests, c’est différent. Ils sont lents, ils échouent pour des raisons légitimes (un test rouge en TDD par exemple), et ils n’ont rien à corriger automatiquement. Les mettre dans un hook, que ce soit en pre-commit ou en pre-push, c’est retomber dans le problème qu’on essaie de résoudre : bloquer le flow pour forcer du code "parfait" avant de pouvoir collaborer. Les tests, c’est le rôle de la CI.

Mais avec l’arrivée des agents IA, le problème prend une autre dimension.

L’IA amplifie le problème, le commit change de rôle

Avec l’IA, le commit n’est plus juste une sauvegarde, c’est un mécanisme de supervision. L’IA va vite, elle touche beaucoup de fichiers, et on ne lit pas chaque ligne en temps réel. On a besoin de petits incréments pour garder le contrôle : relire un diff lisible plutôt que 20 fichiers changés d’un coup, faire un revert précis si l’IA part dans la mauvaise direction. Plus l’IA va vite, plus on a besoin de commiter souvent. Et plus on commit souvent, plus les hooks deviennent un frein. C’est un paradoxe : l’outil censé "garantir la qualité" empêche justement le mécanisme qui nous permet de contrôler la qualité du travail de l’IA.

Et quand un développeur fait --no-verify, on peut se dire qu’il est pressé ou négligent. Mais quand une IA — sans ego, sans impatience, sans flemme — contourne aussi les hooks, ça dit autre chose. Exemple concret : on demande à l’IA d’ajouter un champ dans un formulaire. Un test sans rapport échoue dans le hook pre-commit. L’IA ne peut pas commiter. On lui a dit de ne pas toucher aux tests. Mais le hook la bloque. Alors elle fait ce qu’un dev ferait : elle contourne. Elle rajoute du code pour faire passer le test sans le modifier directement, ou elle fait --no-verify. Le résultat : l’IA part en roue libre, le code se dégrade, et on finit par devoir tout revert parce qu’on n’a pas pu commiter avant que ça dérape. Si même un agent sans émotion contourne les hooks, c’est que le mécanisme est le problème, pas les gens.

Pourtant, on veut quand même que l’IA lance les tests, qu’elle vérifie le lint. Le problème c’est pas les vérifications, c’est que les git hooks sont un mécanisme unique pour deux acteurs aux besoins opposés. L’humain veut de la liberté : commiter un état intermédiaire, essayer un truc, revenir en arrière. L’IA a besoin de vérifications, mais adaptées à elle, avec un feedback qu’on contrôle.

Encore faut-il que l’IA lance les vérifications. Avec Claude Code par exemple, on peut écrire dans le CLAUDE.md du projet des instructions que l’agent suit à chaque session, comme "lance les tests après chaque modification". Et si le contexte de conversation est compacté et que les instructions risquent d’être perdues, on peut les mettre dans un skill dédié pour être sûr qu’elles sont toujours là.

Reste la question : que se passe-t-il quand ça échoue ? C’est là que ça devient intéressant. Des outils comme Claude Code proposent des hooks de cycle de vie internes à l’agent : on peut configurer un script qui s’exécute quand une commande échoue (par exemple les tests), et qui injecte du contexte dans la conversation de l’agent. Concrètement, quand les tests échouent, au lieu de bloquer le commit, le hook guide l’IA : "Analyse si cet échec est lié à tes changements. Si oui, corrige. Si non, informe le développeur." Ce n’est pas une règle rigide, c’est du guidage. L’IA reçoit le contexte et juge. Si le test qui échoue est directement lié à ce qu’elle vient de modifier, elle le corrige toute seule et continue. Si c’est un test sans rapport, elle commit pour sauvegarder l’état actuel et nous informe : "Ce test a échoué mais ça n’a rien à voir avec mes changements. Tu veux qu’on regarde ensemble ?"

Le git hook applique une règle aveugle — ça passe ou ça bloque, pour tout le monde, sans distinction. Le hook d’agent donne du contexte et laisse le jugement à l’IA, tout en rendant le contrôle au développeur. Et ça ne s’arrête pas au local : l’agent peut aussi réagir aux événements de la CI, recevoir une notification d’échec et analyser ou corriger l’erreur automatiquement.

Concrètement, avec Claude Code, ça ressemble à ça dans le .claude/settings.json du projet :

{
  "hooks": {
    "PostToolUseFailure": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(npm run test|vitest)",
            "command": "echo '{\"additionalContext\": \"Des tests ont échoué. Analyse si ces échecs sont liés à tes changements. Si oui, corrige-les. Si non, commit tes changements et informe le développeur des tests qui échouent sans rapport avec ton travail.\"}'"
          }
        ]
      }
    ]
  }
}

Le hook ne se déclenche que quand npm run test ou vitest échoue. Il n'injecte pas une règle, il injecte du contexte que l'IA utilise pour juger de la marche à suivre.

💡 Pour aller plus loin sur les hooks Claude Code (PostToolUseFailure, additionalContext, matcher, etc.), la documentation complète est disponible ici : https://code.claude.com/docs/fr/hooks-guide

Un outil, plusieurs contextes

Ce que je décris ici s’applique à un contexte précis : une équipe en entreprise, avec une CI, et des développeurs qui travaillent ensemble au quotidien. Dans ce cadre, les hooks compensent un problème qu’on a les moyens de résoudre autrement.

Mais les git hooks ne viennent pas de nulle part. Ils ont été pensés pour des projets où les contributeurs sont nombreux, de niveaux très différents, et où personne ne maîtrise l’ensemble du projet. C’est exactement le cas de l’open source.

Sur un projet open source, les contraintes sont autres. Les contributeurs ne connaissent pas forcément les conventions du projet, ils ont des setups locaux très différents, et ils ne contribuent parfois qu’une seule fois. Un contributeur occasionnel qui ouvre une PR ne va pas passer 20 minutes à comprendre pourquoi la pipeline a échoué. Si un hook lui corrige le formatage et lui signale une erreur de lint avant même de push, c’est du temps gagné pour tout le monde : pour lui et pour les mainteneurs qui relisent.

Dans ce contexte, les hooks ne compensent pas une mauvaise CI. Ils servent de filet de sécurité accessible, qui réduit le bruit dans les PRs et accélère le feedback pour des gens qui ne contribuent peut-être qu’une seule fois. C’est un usage légitime, et c’est d’ailleurs pour ça qu’on les retrouve dans beaucoup de projets open source bien maintenus. Next.js, Angular, webpack, Storybook, NestJS, Prisma... tous utilisent des hooks pour lancer le formatage et le lint sur les fichiers stagés avant chaque commit. Pas les tests, pas le build. Juste ce qui est rapide et auto-corrigeable.

Les git hooks ce n’est pas un mauvais outil. En open source, c’est un filet de sécurité qui a fait ses preuves. Mais dans une équipe en entreprise, avec une CI et les moyens d’investir dedans, s’en servir pour compenser un feedback loop lent c’est mettre un pansement. Le problème n’est pas en local, il est dans la pipeline. C’est là qu’il faut agir.

Tester son interface efficacement : des patterns pour des tests d’UI robustes

Jérémy Chauvin — Thu, 13 Mar 2025 16:53:40 +0000

Article co-écrit avec @manon_carbonnel

Tester l’interface (UI) est un défi : les tests doivent être fiables, lisibles et maintenables dans le temps, tout en restant suffisamment souples pour suivre les évolutions du produit. Malheureusement, l’UI est amenée à évoluer régulièrement, et ces tests sont souvent fragiles et difficiles à faire évoluer si leur conception n’est pas rigoureuse. Nous voulons également des tests cohérents avec des parcours réalistes.

Cet article explore des patterns éprouvés pour améliorer la qualité des tests d’UI. Ces tests sont aussi l’occasion de se mettre à la place des utilisateur·ices de nos applications.

User Facing Attributes

Ce pattern propose d’utiliser des sélecteurs basés sur des attributs ou propriétés visibles par l’utilisateur·ice (rôles accessibles, labels, textes, etc.) pour identifier et interagir avec les éléments de l'interface. Cela permet de rendre les tests plus intuitifs et orientés vers l'expérience réelle de l'utilisateur·ice, en étant moins dépendants de CSS, tout en favorisant des pratiques de développement prenant en compte l’accessibilité.

💡 C’est aujourd’hui l’approche préconisée par la majorité des outils d’automatisation de navigateur comme Playwright.
Si vous utilisez Cypress, bien que la documentation évoque Testing Library, elle préconise l’utilisation de data-test-id.
Mais nous ne sommes pas d’accord avec cette recommandation :D.
Dans la même idée, utiliser des locators basés sur le CSS ou le XPath ne sont pas recommandés, car le DOM peut souvent changer, ce qui conduit à des tests non résilients.

Exemples de code pour accéder aux éléments du DOM d’une page web

Exemple d’utilisation avec Testing Library

// tests/homepage.spec.ts
import { describe, it, expect } from 'vitest';
import { screen } from '@testing-library/dom';

describe('HomePage - User Facing Attributes', () => {
  it('devrait afficher un titre contenant "Playwright" et un lien "Get started" visible', () => {
    await this.page.goto('https://playwright.dev/');

    // Sélection basée sur des attributs exposés à l'utilisateur·ice
    const header = screen.getByRole('heading', { level: 1, name: /Playwright/i });
    expect(header).toBeInTheDocument();

    const getStartedLink = screen.getByRole('link', { name: /Get started/i });
    expect(getStartedLink).toBeVisible();
  });
});

Exemple d’utilisation avec Playwright

// tests/homepage.spec.ts
import { test, expect, Page, Locator } from '@playwright/test';
import { PlaywrightHomePage } from '../pages/PlaywrightHomePage';

test.describe('Test du site Playwright via User Facing Attributes', () => {
  test('Vérifier que le titre principal contient "Playwright" et que le lien "Get started" est visible', async ({ page }) => {
    await this.page.goto('https://playwright.dev/');

    // Sélection basée sur des attributs exposés à l'utilisateur·ice
    const header = this.page.getByRole('heading', { level: 1 });
    const getStartedLink = this.page.getByRole('link', { name: /Get started/i });

    await expect(header).toContainText('Playwright');
    await expect(getStartedLink).toBeVisible();
  });
});

Avantages

Robustesse des tests :

Les tests sont moins susceptibles de casser lors de modifications techniques (comme des changements d'attributs CSS ou ordre des balises dans le DOM).
Alignement avec l'UX :

Les sélecteurs utilisés correspondent à ce que voit et utilise réellement l'utilisateur·ice, améliorant ainsi la pertinence des tests.
Promotion des bonnes pratiques d'accessibilité :

Toutes les interfaces ne sont pas toujours dotées d'attributs ou de rôles pertinents, ce pattern incite donc développer des interfaces accessibles et bien structurées.
Lisibilité et clarté :

Les tests sont plus explicites, car ils décrivent les éléments de l'interface tels qu'une personne les perçoit.

Inconvénients

Dépendance au contenu textuel :

Les tests peuvent devenir fragiles si les libellés ou textes changent fréquemment, même si la fonctionnalité reste correcte.
Moins de contrôle sur des sélecteurs complexes :

Pour certaines interactions spécifiques ou des éléments très dynamiques (comme un élément dans un tableau ou une liste de données), il peut être nécessaire d'utiliser des sélecteurs techniques en complément ou remplacement.

Page Object Model

Son objectif principal est de séparer la logique de test (les scénarios et assertions) de la logique d'interaction avec l'interface.

Exemples de code avec Playwright

// pages/PlaywrightHomePage.ts
import { Page, Locator } from '@playwright/test';

export class PlaywrightHomePage {
  readonly page: Page;
  readonly header: Locator;

  constructor(page: Page) {
    this.page = page;
    // On cible ici le titre principal de la page (par exemple, l'élément h1)
    this.header = page.locator('h1');
  }

  // Méthode pour naviguer vers la page d'accueil
  async navigate(): Promise<void> {
    await this.page.goto('https://playwright.dev/');
  }

  // Méthode pour récupérer le texte du titre
  async getHeaderText(): Promise<string | null> {
    return this.header.textContent();
  }
}

Exemple d’utilisation

// tests/homepage.spec.ts
import { test, expect } from '@playwright/test';
import { PlaywrightHomePage } from '../pages/PlaywrightHomePage';

test.describe('Test du site Playwright', () => {
  test('Vérifier que le titre principal contient "Playwright"', async ({ page }) => {
    // Instanciation de la page via notre Page Object
    const homePage = new PlaywrightHomePage(page);
    await homePage.navigate();

    const headerText = await homePage.getHeaderText();

    expect(headerText).toContain('Playwright');
  });
});

Avantages

Séparation des responsabilités :

Le POM sépare la logique de test de l’implémentation de l’interface. Cela permet aux tests de se concentrer sur la validation du comportement métier.
Modularité et évolutivité :

Chaque page ou composant est représenté par une classe spécifique, facilitant ainsi l’organisation et l’évolution de la suite de tests.
Maintenance facilitée :

Lorsqu'une modification est apportée à l'interface (changement de sélecteur, structure HTML modifiée…), il suffit de mettre à jour la classe correspondante, sans toucher aux tests eux-mêmes.
Réutilisabilité :

Les méthodes et sélecteurs encapsulés dans un objet peuvent être réutilisés dans plusieurs tests, réduisant ainsi la duplication de code.
Lisibilité et clarté des tests :

En déléguant les interactions à des objets dédiés, les scénarios de tests restent concis et lisibles. On peut ainsi comprendre rapidement l’intention du test sans se perdre dans les détails d’implémentation.

Inconvénients

Risque de duplication si mal structuré :

Sans une bonne conception, on peut se retrouver avec des classes qui dupliquent des comportements similaires pour des composants récurrents, au lieu d’extraire des composants communs. Dans le cas où on trouverait plusieurs fois le même composant sur une page, il suffit d’y accéder en précisant le bloc parent dans le sélecteur.
Couplage si contenu dans une librairie à part :

Conserver le POM dans un repository / une librairie à part entraîne des problèmes d’alignement des sélecteurs lors de mise à jour des pages.

Screenplay Pattern : alternative au POM

Le Screenplay Pattern est une approche pour structurer les tests d'UI en mettant l'accent sur les actions et les intentions des utilisateur·ices, plutôt que sur la structure technique des pages. Particulièrement utile pour des suites de tests larges et évolutives

Au lieu de manipuler directement les éléments de l’UI via un Page Object Model (POM), il introduit des "acteur·ices" qui interagissent avec l'interface en utilisant des "tâches" et des "questions".

Exemples de code avec Playwright

import { Page } from '@playwright/test';

// Définition des intéractions
export class EnterText {
  static into(selector: string, text: string) {
    return async (page: Page) => {
      await page.fill(selector, text);
    };
  }
}

export class Click {
  static on(selector: string) {
    return async (page: Page) => {
      await page.click(selector);
    };
  }
}

// Définition des tâches
export class Login {
  static withCredentials(username: string, password: string) {
    return async (page: Page) => {
      await EnterText.into('#username', username)(page);
      await EnterText.into('#password', password)(page);
      await Click.on('#login-button')(page);
    };
  }
}

// Définition des questions
export class IsLoggedIn {
  static async answeredBy(page: Page) {
    return await page.locator('#welcome-message').isVisible();
  }
}

Exemple d’utilisation

// tests/login.spec.ts
import { test, expect } from '@playwright/test';
import { Login, IsLoggedIn } from './login-screenplay';

test('Alice peut se connecter', async ({ page }) => {
  await page.goto('https://example.com/login');

  // L'utilisateur·ice joue le rôle d'un·e acteur·ice réalisant une tâche
  await Login.withCredentials('alice', 'securepassword')(page);

  // Vérification de la connexion
  const loggedIn = await IsLoggedIn.answeredBy(page);
  expect(loggedIn).toBe(true);
});

Avantages

Modularité :

Les interactions et tâches sont réutilisables.
Lisibilité :

Le code ressemble plus à un scénario utilisateur.
Maintenance facilitée :

Modifier l’implémentation d’une interaction ne casse pas toute la suite de tests.
Scalabilité :

Facilite l’ajout de nouvelles tâches sans dupliquer du code.

Inconvénients

Complexité initiale :

Plus de fichiers et d'abstraction qu'un simple Page Object Model qui est parfois suffisant pour de petits tests simple.
Courbe d’apprentissage :

Nécessite de bien comprendre la séparation entre acteurs, tâches et interactions.

Outils et bibliothèques populaires pour des test d’UI

Testing Library

Testing library est une solution légère pour tester des UI en interagissant avec le DOM de manière similaire à une personne. Son approche repose sur la recherche et l'interaction avec les éléments via leurs user-facing attributes.

Playwright

Playwright est un outil d'automatisation de navigateurs conçu pour offrir une developer experience confortable et puissante. Il prend en charge plusieurs langages (TypeScript, JavaScript, Python, C#, Java) et permet de tester des applications sur différents navigateurs (Chromium, Firefox, WebKit) et plateformes (Windows, Linux, macOS). Son API facilite la manipulation du DOM et intègre nativement les user-facing attributes pour interagir avec les éléments. Playwright se distingue également par ses fonctionnalités avancées comme le record & replay, les tests en parallèle, et le debugging interactif avec des outils visuels comme le trace viewer.

Mieux tester en optimisant la génération de données de test : Panorama des patterns

Jérémy Chauvin — Thu, 13 Mar 2025 16:44:47 +0000

Article co-écrit avec @manon_carbonnel

Écrire des tests automatisés efficaces ne se résume pas à vérifier que notre code fonctionne : il faut aussi que les tests soient lisibles, maintenables et rapides à écrire. Pour cela, la manière dont on génère les données de test joue un rôle clé.

Les patterns que nous vous présentons permettent d’éviter de la duplication, de rendre les tests plus clairs et de mieux maîtriser la complexité des objets manipulés.

Dans cet article, nous allons explorer différentes approches, leurs avantages et leurs limites, et cibler la stratégie à adopter selon le contexte.

Pourquoi faire varier ses jeux de données ?

Pour certains tests, il est primordial de rendre visible la variation des données afin d'expliciter la règle métier sous-jacente.

Par exemple, pour déterminer si un utilisateur est majeur, vous devez modifier son âge dans vos tests et créer deux fixtures. Cependant, ce qui vous intéresse réellement, c'est de voir la règle métier apparaître clairement dans vos tests. Il est crucial de bien mettre en évidence l'âge que vous attribuez.

💡 Ces patterns ne sont pas spécifiques au langage TypeScript que nous avons choisi dans nos exemples, et sont implémentables avec n’importe quel langage généraliste.

Utilisation des Fixtures

Les Fixtures sont des ensembles de données préconfigurées utilisées pour initialiser l'état d'un test. Elles permettent de définir des conditions de test spécifiques et de garantir que les tests sont reproductibles.

Exemples de code pour créer et utiliser des Fixtures en TypeScript

// personaFixtures.ts
export const johnDoe: User = {
  id: 1,
  name: 'John Doe',
  email: 'john.doe@example.com'
  // ... your full Persona caracteristics, to be used in several tests
};

// test.ts
import { johnDoe } from './personaFixtures';

test('should create a user', () => {
  const user = createUser(johnDoe);
  // ...code
  expect(user).toEqual(johnDoe);
});

Avantages

Simplicité et facilité d'utilisation.
Reproductibilité des tests.
Utilisation des persona UX

Inconvénients

Peuvent devenir difficiles à gérer pour des ensembles de données complexes.
Moins flexibles pour des variations de données.

Utilisation des Object Mother

Le pattern Object Mother consiste à créer des objets complexes à partir de méthodes de fabrication centralisées. Cela permet de simplifier la création d'objets de test et de garantir la cohérence des données.

Exemples de code pour créer des objets complexes avec des Object Mothers en TypeScript

// objectMother.ts
export class UserMother {
  static create(): User {
    return {
      id: 1,
      name: 'John Doe',
      email: 'john.doe@example.com'
    };
  }
}

// test.ts
import { UserMother } from './objectMother';

test('should create a user', () => {
  const user = UserMother.create();
  expect(user).toEqual({
    id: 1,
    name: 'John Doe',
    email: 'john.doe@example.com'
  });
});

Avec un objet plus complexe :

Les types

// interfaces.ts
export interface Item {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

export interface Order {
  id: number;
  customerName: string;
  items: Item[];
  total: number;
}

Object Mother pour Order

// orderMother.ts
import {Order} from "./interface";

export class OrderMother {
    static with2Items(): Order {
        const items = [{id: 2, name: 'A very specific item', price: 10, quantity: 2}, {id: 3, name: "Another specific item", price: 300, quantity: 1}];
        return {
            id: 25,
            customerName: "Rich customer",
            items: items,
            total: items.reduce((previousValue, currentValue) => previousValue + (currentValue.price * currentValue.quantity), 0)
        }
    }

    static withoutItems(): Order {
        return {
            id: 25,
            customerName: "Poor customer",
            items: [],
            total: 0
        }
    }

    static johnDoeBuysATable(): Order {
        const items = [{id: 1, name: 'Table', price: 500, quantity: 1}];
        return {
            id: 25,
            customerName: "John Doe",
            items: items,
            total: items.reduce((previousValue, currentValue) => previousValue + (currentValue.price * currentValue.quantity), 0)
        }
    }
}

Exemple d’utilisation

// test.ts
import {OrderMother} from "./orderMother";

describe("Order Mother", () => {
    it('should create an order with items', () => {
        const order = OrderMother.with2Items();
        expect(order.items).toHaveLength(2)
        expect(order.total).toBe(320)
    });

    it('should create an order without items', () => {
        const order = OrderMother.withoutItems();
        expect(order.items).toHaveLength(0)
        expect(order.total).toBe(0)
    });
});

Avantages

Centralisation de la création d'objets.
Facilité de maintenance.

Inconvénients

Peut devenir complexe pour des objets très variés.
Moins flexible pour des variations spécifiques.

Utilisation des Factory Functions

Les Factory Functions sont des fonctions qui retournent des objets. Elles sont simples à utiliser et permettent de créer des objets de manière concise.

Exemples de code pour créer des objets avec des Factory Functions en TypeScript

💡 En TypeScript, l'utilisation du type Partial offre un avantage supplémentaire. Le type Partial permet de créer des objets partiels, ce qui signifie que vous pouvez définir uniquement les propriétés nécessaires pour un test spécifique. Cela rend les tests plus lisibles et plus faciles à maintenir. Vous pouvez déstructurer votre type pour rendre votre test plus lisible et explicite.

type User = {
  id: number;
  name: string;
  email: string;
};

export function createUser({ id = 1, name = 'Jane Doe', email = 'jane.doe@example.com' }: Partial<User>): User {
  return {
    id,
    name,
    email,
  };
}

test('should create a user', () => {
    const user = createUser({ name: 'Jonh Doe', email: 'john.doe@example.com' });
    expect(user).toEqual({
      id: 1,
      name: 'Jonh Doe',
      email: 'john.doe@example.com',
    });
  });

Avantages

Simplicité et facilité d'utilisation.
Flexibilité pour créer des objets avec des variations spécifiques.

Inconvénients

Moins adapté pour des objets très complexes.
Peut devenir difficile à gérer pour des ensembles de données importants.

Utilisation des Test Data Builders / Builders

Le pattern Builder permet de construire des objets complexes de manière incrémentale. Il est particulièrement utile pour créer des objets avec des variations spécifiques.

Exemples de code pour créer des objets complexes avec des builders en TypeScript

// userBuilder.ts
export class UserBuilder {
  private user: User = {
    id: 1,
    name: 'John Doe',
    email: 'john.doe@example.com'
  };

  withName(name: string): UserBuilder {
    this.user.name = name;
    return this;
  }

  withEmail(email: string): UserBuilder {
    this.user.email = email;
    return this;
  }

  build(): User {
    return this.user;
  }
}

// test.ts
import { UserBuilder } from './userBuilder';

test('should create a user with custom name', () => {
  const user = new UserBuilder().withName('Jane Doe').build();
  expect(user).toEqual({
    id: 1,
    name: 'Jane Doe',
    email: 'john.doe@example.com'
  });
});

Avec un objet plus complexe:

Les types

// interfaces.ts
export interface Item {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

export interface Order {
  id: number;
  customerName: string;
  items: Item[];
  total: number;
}

Test Data Builder pour Order

// ItemBuilder.ts
import {Item} from "./interface";

export class ItemBuilder {
    private readonly item: Item

    constructor() {
        this.item = {id: 1, name: 'Default Item', price: 100, quantity: 1}
    }

    public withName(name: string): this {
        this.item.name = name
        return this
    }

    public withId(id: number): this {
        this.item.id = id
        return this
    }

    public withPrice(price: number): this {
        this.item.price = price
        return this
    }

    public withQuantity(quantity: number): this {
        this.item.quantity = quantity
        return this
    }

    public build(): Item {
        return this.item
    }
}

import {Item, Order} from "./interface";
import {ItemBuilder} from "./itemBuilder";

export class OrderBuilder {
    private readonly order: Order

    constructor() {
        this.order = {id: 1, items: [new ItemBuilder().withPrice(20).build()], total: 20, customerName: "Alice"}
    }

    public withCustomerName(name: string): this {
        this.order.customerName = name
        return this
    }

    public withItems(...items: Item[]): this {
        this.order.items = items
        this.order.total = items.reduce((previousValue, currentValue) => previousValue + (currentValue.price * currentValue.quantity), 0)
        return this
    }

    public build(): Order {
        return this.order
    }
}

Exemple d’utilisation

describe("Simple test", () => {
    it('should create an order with default builder', () => {
        const order = new OrderBuilder().build()
        expect(order.items).toHaveLength(1)
        expect(order.total).toBe(20)
    });

    it('should create an order with 2 items', () => {
        const order = new OrderBuilder().withItems(
            new ItemBuilder().withPrice(100).build(),
            new ItemBuilder().withPrice(10).withQuantity(5).withId(2).build()
        ).build();
        expect(order.items).toHaveLength(2)
        expect(order.total).toBe(150)
    });

    it("should create a John Doe's order", () => {
        const order = new OrderBuilder().withCustomerName("John Doe").build();
        expect(order.customerName).toBe("John Doe")
    });
});

Avantages

Flexibilité pour créer des objets avec des variations spécifiques.
Facilité de lecture et de maintenance.

💡 Vous pouvez également créer des builders avec des valeurs par défaut. C'est ce que recommande le livre "Growing Object-Oriented Software, Guided by Tests". Vous aurez ainsi une ou plusieurs méthodes statiques qui vous permettront de configurer vos tests à partir de personas ou de cas métiers spécifiques.

Inconvénients

Peut devenir verbeux pour des objets simples.
Nécessite une configuration initiale.

Nos préférences pour la création de jeu de données

Pour nous, ce qui est important, c'est d'avoir une série de tests qui soit lisible et facile à écrire. C'est pourquoi nous mettons en avant trois critères pour choisir le pattern que nous voulons utiliser :

Visibilité des Variations de Données
API Fluide et Lisibilité
Simplicité et Flexibilité

C’est pour cela que nous préférons les patterns Factory Function et Test Data Builder.

💡 Nous avons des préférences pour ces patterns, mais parfois nous allons utiliser une fixture ou un object mother, car le nommage métier peut être plus explicite que la simple variation des données, etc.

Pourquoi le pattern Factory Function ?

Pour des objets simples et sans profondeur, le pattern Factory Function est une approche efficace. Elle permet de créer des objets de manière concise.

L'utilisation du type Partial en TypeScript facilite la création d'objets partiels, ce qui est particulièrement utile pour les tests.

Pourquoi le pattern Test Data Builder ?

Le pattern Builder est particulièrement adapté pour les objets avec plusieurs niveaux de profondeur. Il permet de construire des objets complexes de manière incrémentale, en chaînant des méthodes pour définir les différentes propriétés de l'objet. Cette approche offre une grande flexibilité et permet de voir facilement les variations de données, ce qui est crucial pour valider les tests.

Outils et bibliothèques populaires pour la création de jeux de données

faker.js

Génération de données fictives réalistes.
Idéal pour tester des scénarios avec des données variées.

factory.ts

Création structurée d'objets de test.
Idéal pour des objets complexes et des variations spécifiques.

faker.js

faker.js est une bibliothèque populaire pour générer des données fictives. Elle permet de créer des données réalistes pour les tests.

// fakerExample.ts
import faker from 'faker';
import type { Email } from "./email.js";

test('should generate a fake user', () => {
  const user = {
    id: 1,
    name: faker.name.findName(),
    email: faker.internet.email()
  };
  expect(user).toEqual({
    id: 1,
    name: expect.any(String),
    email: expect.any(Email)
  });
});

factory.ts

factory.ts est une bibliothèque TypeScript pour créer des objets de test de manière structurée.

// factoryExample.ts
import { Factory } from 'factory.ts';

interface User {
  id: number;
  name: string;
  email: string;
}

const userFactory = Factory.Sync.makeFactory<User>({
  id: Factory.each((i) => i),
  name: 'John Doe',
  email: 'john.doe@example.com'
});

test('should create a user with factory.ts', () => {
  const user = userFactory.build();
  expect(user).toEqual({
    id: expect.any(Number),
    name: 'John Doe',
    email: 'john.doe@example.com'
  });
});

Conclusion

À partir de quoi faire varier les données ?

Nous vous recommandons fortement de faire varier vos données à partir de personas UX ou de cas métiers bien identifiés. Ces éléments définiront vos valeurs par défaut pour la plupart des patterns décrits ci-dessus. L'objectif d'avoir ces valeurs par défaut (personas UX ou cas métiers) est de rendre vos tests lisibles et de les utiliser comme documentation.

Où ranger ces patterns dans le code ?

Ces fichiers servant uniquement aux tests, ils ont leur place à leurs côtés. Vous pouvez l’utiliser à côté du test qui l’utilise, mais s’il y a de la réutilisation ailleurs, il faudra créer un dossier et fichier dédié.

/test
    /order
        /order.ts
    /dataBuilders
        /orderBuilder.ts

La création de jeux de données pour les tests est essentielle pour garantir la qualité et la fiabilité du code. Chaque méthode a ses forces et ses limites, et le choix du bon pattern dépend de la complexité des éléments à générer.

Il n’existe pas de solution universelle : la clé réside dans une réflexion collective et des décisions alignées avec les besoins de votre projet.

Pour aller plus loin

Guide pratique de l'utilisation des Linters

Jérémy Chauvin — Wed, 24 Apr 2024 12:30:54 +0000

Nous avons tous déjà vécu un onboarding sur un projet où on fait des copier/coller d’une autre fonctionnalité qui ressemble à ce qu’on veut faire. Nous réadaptons le code, nous commitons et nous pushons. Nous ouvrons la MR/PR et la revue est catastrophique. Le code que nous avons copié-collé est du code legacy, nous avons 15 fois le même commentaire qui nous dit d'utiliser des const pour déclarer nos variables, etc. Tout cela nous fait perdre du temps, et ne nous met pas dans les meilleures conditions pour apprécier le projet.

Dans cet article vous allez (re)découvrir comment les linters peuvent vous éviter ces pièges et vous aider à développer.

Avant d’aborder les avantages d’un linter, nous allons expliquer ce que c’est

Qu’est-ce qu’un linter ?

Techniquement, c’est un outil qui fait de l’analyse statique de votre code donc directement dans votre fichier sans que le code soit build ou soit en train de run.

Cela permet d’avoir une boucle de feedback très courte 🤩

Sévérité

Vous allez retrouver en général deux types de sévérité dans un linter qui sont les Warnings et les Errors.

Les Warnings sont des problèmes potentiels qui n'empêchent pas l'exécution du code, mais indiquent des pratiques à améliorer pour maintenir la qualité et la cohérence du code.

Les Errors sont des problèmes bloquants qui empêchent le code de fonctionner correctement. Elles doivent être corrigées avant de pouvoir compiler ou exécuter le programme.

🧐 Pour information
Dans la plupart des projets, vous allez retrouver la règle no-warning dans notre CI. Ce qui fait que si vous avez une règle en warning qui est détecté alors votre CI va planter.
Personnellement, je n’aime pas cette feature, car elle vous obligent à tout faire d’un coup. Je vous en reparle dans la partie “Mieux refactorer du code legacy”

Rendre l’implicite explicite

En mettant en place un ou des linters, vous allez pouvoir rendre l’implicite explicite, c'est-à-dire faire émerger des règles et des conventions qui peuvent ne pas être documentées ou comprises par tous les membres de l'équipe.

Par exemple, un linter peut vérifier que vos attributs sont dans l’ordre alphabétique, que vos variables sont bien immuables (en JS, n'utiliser que des const), que vous respectez les normes sur le nommage de variable, de classes ou de fonctions dans votre projet. Ces règles peuvent sembler mineures, mais elles contribuent à la lisibilité et à la compréhension du code par tous les membres de l'équipe.

En rendant ces règles explicites grâce à un linter, vous pouvez vous assurer que tout le monde suit les mêmes conventions et que le code soit cohérent et facile à comprendre. Cela peut également faciliter l'intégration de nouveaux membres dans l'équipe, car les règles sont clairement définies et documentées.

Apprendre

En utilisant un linter, vous pouvez apprendre de nouvelles pratiques. Les linters peuvent vous aider à découvrir des règles et des conventions que vous ne connaissiez peut-être pas auparavant, ainsi que les raisons pour lesquelles ces règles sont importantes.

Par exemple, en utilisant un linter pour JavaScript, vous pouvez apprendre que la méthode "reduce" peut être moins performante qu'une boucle "for" dans certaines situations. En comprenant pourquoi cette règle est importante, vous pouvez prendre de meilleures décisions

(https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-array-reduce.md)

De plus, les linters peuvent vous aider à améliorer votre code que ça soit sur la lisibilité, la séparation de la logique, la sécurité (Snyk, Sonar etc) et la performance. En comprenant pourquoi ces règles sont importantes, vous pouvez non seulement écrire du code plus propre et plus efficace, mais également vous améliorer.

Mieux refactorer du code legacy

Lorsque vous travaillez sur une application existante avec du code legacy, un linter peut être un outil très utile pour vous aider à nettoyer et à mettre à jour votre code. Vous pouvez aussi identifier les parties de votre code qui doivent être mises à jour ou supprimées, et suivre votre progression au fil du temps.

Par exemple, supposons que vous souhaitiez supprimer une bibliothèque (comme Lodash) de votre application. Cependant, le faire d'un coup peut être trop risqué ou trop complexe. Dans ce cas, vous pouvez commencer par ajouter une règle de linter en mode warning sur l'utilisation de Lodash. Cela vous permettra de savoir chaque fois que vous utilisez Lodash dans votre code et de commencer à le supprimer progressivement. De plus, l’ajouter en mode warning permet aussi à ce qu’un nouveau ou une personne qui rentre de vacances sache qu’il ne doit plus l’utiliser.

En suivant le nombre d'avertissements de cette règle, vous pouvez suivre votre progression. Aussi, vous pouvez être sûr que tout nouveau code que vous écrivez ne dépendra pas de Lodash, ce qui facilitera la suppression complète de la bibliothèque à l'avenir.

💡 Je vous conseille fortement de ne pas avoir plus d’une règle en warning pour ne pas avoir trop de choses à faire d’un coup

Attention, un linter apporte aussi une certaine complexité, qui peut vous freiner ou être un point de souffrance.

Par exemple, vous avez deux règles qui, individuellement, semblent cohérentes :

Mets en dernier les paramètres qui ont une valeur par défaut
Trie les paramètres dans l’ordre alphabétique

Tant que vous n’avez pas les deux en même temps, il n’y a aucun problème. Mais si vous avez ça:

// Mets en dernier les paramètres qui ont une valeur par défaut
function handleThings(value, opts = {}) {
  // ...
}

// Trie les paramètre dans l'ordre alphabétique
function handleThings(opts = {}, value) { 
     // ...
}

Vos règles vont se marcher dessus. Pour éviter cela, je vous conseille donc de faire attention à ces deux points.

Ajout de règle sans cesse

L'ajout de règles sans limite peut devenir contre-productif et entraver le bon déroulement du projet. Il est important de trouver un équilibre entre la qualité du code et la productivité de l'équipe.
Je vous recommande de ne pas ajouter trop de règles d'un coup, mais plutôt de les introduire progressivement en fonction des besoins du projet et de l'équipe. Il est également utile de régulièrement réévaluer les règles existantes pour s'assurer qu'elles soient toujours pertinentes.

💡 Je vous conseille fortement de faire des discussions régulières pour parler des règles de linter, de choisir si vous devez la garder ou rajouter des règles si besoin. Pendant ces discussions il est important de documenter pourquoi vous mettez en place une règle ou pourquoi vous enlevez une règle

Le nombre idéal de règles dépend du projet et de l'équipe.

La seule question que vous devez vous poser c’est si la règle est pertinente dans votre contexte.

Configuration complexe

La configuration d'un linter peut devenir compliquée avec le temps et nécessitera une maintenance régulière pour rester efficace. Si la configuration n'est pas bien gérée, cela peut entraîner des problèmes tels que des règles contradictoires ou non pertinentes pour le projet.

Il est important de prendre le temps de comprendre l'historique de la configuration du linter avant de faire des modifications ou de critiquer la configuration actuelle. Il peut être utile de discuter avec les membres de l'équipe qui ont travaillé précédemment sur la configuration pour comprendre les raisons derrière certaines décisions.

En outre, il est important de documenter les changements apportés à la configuration du linter et de communiquer ces changements à l'équipe. Cela peut aider à éviter les conflits et à maintenir une configuration cohérente et efficace.

Comment gérer la documentation de son linter ?

Je recommande de stocker la documentation de votre linter à proximité du code, dans le même dépôt git

❓ Pourquoi proche du code ?
Si vous stockez la documentation du linter dans un outil externe tel que Confluence ou un autre référentiel qui génère un site web à partir de fichiers markdown, vous risquez de rencontrer des problèmes de synchronisation.
Par exemple, quelqu'un peut oublier de mettre à jour la documentation ou vous n'y avez pas accès pour une raison quelconque.
En revanche, si vous stockez la documentation du linter au même endroit que le code, vous réduisez considérablement le risque de désynchronisation.
De plus, cela facilite l'accès à la documentation pour les développeurs qui travaillent sur le projet.

Vous pouvez créer un dossier docs à la racine de votre projet. Ce dossier va contenir d’autres dossiers.

💡 N'oubliez pas d'exclure ce dossier de vos outils de build ou autres.

Par exemple, un dossier eslint, qui contiendra un fichier où vous expliquerez pourquoi vous avez utilisé certains plugins eslint et pourquoi vous avez désactivé ou ajouté certaines règles de lint. Bien sûr, n'oubliez pas d'ajouter les dates.

💡 Il est important que toutes les modifications de règles renvoient à la documentation de la règle ou du plugin.

Voici un exemple de fichier :

Quelques linters pour vous lancer

Voici une liste de linters pour vous lancer avec le langage ou le format du fichier :

Langage	Linter
JS/TS	eslint, Biome
Java	checkstyle
Go	GolangCi-lint
Rust	Clippy
Yaml	Yamllint
OpenApi	Spectral

💡 Si vous recherchez un linter pour votre langage ou un format de fichier, je vous conseille de regarder sur Megalinter

Voilà j’espère vous avoir donné envie d’utiliser un linter ou des pistes pour améliorer votre expérience avec les linters 🐵

Tips&Tricks pour améliorer votre CI/CD

Jérémy Chauvin — Tue, 10 Oct 2023 19:45:11 +0000

On a tous déjà ressenti de la frustration envers la pipeline du projet. Parce que la CI est trop lente ou encore elle nous sort des tests flaky et il faut la relancer plusieurs fois pour que ça passe… Tout cela, fait que nous perdons beaucoup de temps avec quelque chose qui est censée nous aider et nous en faire gagner.

💡 Au niveau de chaque point je vais mettre un ou plusieurs icônes pour indiquer le but de ce point :

Icône	Description
🏎️	Permet de gagner du temps
⭐	Important de l’avoir ou de le faire

Avant de vous parler d’astuce pour améliorer votre pipeline nous devons quand même qualifier le terme CI et CD.

Définition CI/CD

Intégration Continue (Continuous Integration)

L’intégration continue est une pratique consistant à exécuter différents contrôles sur tout type de contribution à votre repo.

Nous allons souvent rencontrer ces étapes-là :

Build image ou du binaire
Test
Lint
Scan de vulnérabilités

Déploiement Continu (Continuous Deployment)

Le déploiement continu est la pratique qui consiste à déployer automatiquement des nouvelles versions dans un environnement dédié.

Nous allons souvent rencontrer ces étapes là :

Déploiement de l’image
Génération de la release note
Génération de la version (tag, release, etc)

🏎️ Mise en place de cache de dépendance

Une des premières étapes de la CI consiste à télécharger les dépendances du projet pour pouvoir exécuter les tests ou faire le build. Bref, c’est une étape essentielle pour votre CI.

Cette étape, qui est majeure pour votre CI, prend un certain temps. Plus le projet est gros plus ce temps est important. Il est donc primordial de mettre en place un cache pour gagner du temps.

Il y a quand même plusieurs types de cache de dépendances :

on peut voir le cache de dépendance de pnpm et maven qui consiste à faire un dossier au niveau du user où il ne font simplement qu’un lien symbolique ou une copie dans le projet.
Le deuxième cache consiste à prendre votre fichier de gestion dépendance (exemples : package-lock.json (npm en JS, TS), poetry.lock (poetry en python) …) et de le hasher. Ce qui va vous générer un code unique en fonction du contenu du fichier. Si vous avez une nouvelle dépendance ou une nouvelle version d’une dépendance alors le hash sera différent. Une fois le hash calculé, vous pouvez créer un lien symbolique entre votre dossier du hash et le dossier qui contient les dépendances.

Comment on fait ? 💡

Pour la plupart des outils de CI connus, vous pouvez définir une gestion de cache à partir d’un ou plusieurs fichier comme clé.

Par exemple :

⭐ 🏎️ Paralléliser un maximum

Paralléliser vos stages/job dans votre CI ou votre CD.

Vous devez paralleliser un maximum vos étapes pour gagner du temps. C’est simple dit comme ça, mais il faut y penser. On a tendance à faire beaucoup de synchronisme même dans nos étapes de pipelines, alors que nous pouvons simplement les paralleliser.

Nous pouvons prendre l’exemple du CI qui ne va faire que le build, le test et un lint. Dans environ 80% des CI qui existent nous allons retrouver ça :

Le build en premier
Les tests qui dépendent du build (si le build échoue, on ne lance pas les tests)
La tache de lint qui dépend des tests (si les tests fail on ne lance pas le lint)

La liaison entre le build et les tests peut exister pour les langages compilés. Par contre pour les langages interprétés du type JS, python etc, vous n’avez pas besoin d’attendre la fin du build pour exécuter vos tests.

La liaison entre votre linter et vos tests (ou même implicitement votre build) n’a AUCUNE raison d’exister. Cette tâche peut être lancée en même temps.

Paralléliser vos tests

Comme vous pouvez paralléliser vos jobs ou vos stages dans votre CI, vous pouvez tout aussi bien paralléliser vos tests en utilisant, par exemple, des test runners spécialement conçus à cet effet, tels que AvA en JS/TS.

Avoir une étape de test dans votre CI ne veut pas dire que c’est un fourretout. Vous pouvez créer plusieurs étapes qui peuvent tourner en même temps. Comme par exemple avoir une étape de test unitaire, test d’intégration, etc

On va être un peu plus précis pour les tests d'intégration qui sont complexes. Surtout sur la gestion de la base de données et des données qui y sont contenues.

Premièrement, il incombe aux tests de lancer la base de données et de mettre en place les données nécessaires pour les tests.

Deuxièmement, votre base de données n'est pas obligée d'être vidée et de réinsérer des données. Vous pouvez simplement, vous assurer que vos tests ne s'entremêlent pas en utilisant des données un peu plus aléatoires, comme par exemple des UUID au lieu d'auto-incrément, ce qui réduit les chances que les données entrent en collision si vous effectuez une insertion dans votre test.

Troisièmement, sur des tests d’intégration je vous déconseille de vérifier des données avec des valeurs absolues mais de bien les vérifier à partir d’un objet généré avec des données générées.

Une fois que vous avez fait tout ça, vous pouvez normalement les parralléliser simplement 🙂

⭐ ⭐ Avoir les bonnes dimensions de machines

Il est également très important de bien choisir les ressources que vous accordez à vos runners de votre pipeline.

Si vos runners n'ont pas les ressources minimales pour exécuter certains logiciels, tels que Cypress ou d'autres outils qui peuvent être gourmands en ressources, vous vous retrouverez avec une étape lente ou, pire encore, une étape qui plante et qui va sortir des faux positifs.

Ce qu'il y a de plus frustrant pour vos utilisateurs c’est de devoir relancer certains jobs et d'espérer que ça passe. Ils perdent beaucoup de temps et s'ils se produisent fréquemment, ils peuvent décider de supprimer ou de passer le test qui est en faux positif afin de contourner le problème.

🏎️ 🏎️ Ne pas reproduire deux fois la même chose

Je pense que cette étape est une étape qui peut vous faire gagner beaucoup de temps. Imaginons que nous soyons sur un projet qui utilise le git flow.

Pour les branches de feature, nous n'exécutons que les étapes de notre CI, c'est-à-dire Build, Test et Lint. La CI met en tout 5 minutes à tourner. Lorsque la branche de feature est mergée ou rebasée sur votre branche de develop, la CI retourne également, tout comme lorsque vous arrivez sur votre branche de release. Cela signifie que pour le même commit, donc le même code, nous exécutons la CI 3 fois, ce qui nous donne exactement le même résultat. L'utilisateur doit attendre 5 minutes sur develop avant de pouvoir le déployer sur son environnement, et c'est la même chose sur sa branche de release.

Pour éviter que votre utilisateur ne perde encore plus de temps sur votre pipeline, il y a une solution. Vous pouvez faire la promotion de l'artifact, c'est-à-dire que votre artifact sera créé sur votre branche de feature, en utilisant l'identifiant de votre commit comme identifiant de votre artifact.

💡 Exemple de votre artefact :
application-0de83a78334c64250b18b5191f6cbd6b97e77f84

Le nom de votre artefact peut être plus court si vous utilisez la version courte de l'ID du commit :
application-0de83a7

Mais vous pouvez aussi le combiner avec le futur numéro de version :
application-2.3.1-0de83a7

Dès que votre artefact est prêt, la première étape de votre CI sera de vérifier si l'artefact existe afin de sauter toute la partie CI et passer directement à votre CD sans attendre.

💡 Vous pouvez aussi le faire si vous faites du trunk based 😁

⭐ 🏎️ Lancer vos stages/jobs que quand c’est utile

Imaginons que dans votre projet, vous ayez vos fichiers de configuration de déploiement kubernetes, pour l’exemple on va parler de fichier helm. Ce qui nous donne ceci :

Lorsque vous modifiez uniquement les fichiers du dossier Helm, vous ne devez pas lancer toute la CI du projet. Vous ne devez lancer que la CI de ce dossier en particulier, par exemple un linter pour YAML ou le linter de Helm. De même, si le fichier n'a pas été modifié, vous n'avez pas besoin de lancer la CI de ce dossier. Ce qui signifie pas de tâche de linter Helm ou YAML pour ce dossier.

Si vous suivez cette étape correctement, vous ou vos utilisateurs pourrez faire de petites modifications de configuration sans perdre de temps.

Comment on fait ? 💡

Pour la plupart des outils de CI connus, vous pouvez définir des conditions sur le quand lancer vos étapes/jobs. Et dans ces conditions, il y a la possibilité de choisir si un dossier ou un fichier a été modifié.

Par exemple :

⭐ ⭐ ⭐ Définir une durée maximum au niveau de votre pipeline

Ce tips est, pour moi, un des trois plus important de votre pipeline, il va vous permettre de ne pas (re)tomber dans une pipeline qui dure plus de 20 minutes ou plus.

On va parler de la loi de Parkinson, qui nous apprend que le temps du travail a tendance à s'étendre pour occuper tout le temps disponible pour sa réalisation. En d'autres termes, si vous accordez une certaine quantité de temps pour accomplir une tâche (même si elle pourrait être terminée plus rapidement) elle prendra souvent tout le temps alloué.

Il est donc très important de fixer une durée maximale pour votre CI/CD et également pour vos étapes le plus tôt possible. Car si vous ne le faites pas, le temps va continuer à s'étirer jusqu'à atteindre un point où il devient très compliqué et coûteux de revenir à un environnement stable.

Comment on fait ? 💡

Pour la plupart des outils de CI connus, vous pouvez définir un timeout par job ou steps.

Par exemple:

⭐ ⭐ ⭐ Mise en place d’alerting

Comme le précédent tips, je le considère comme très important et pas seulement pour votre pipeline mais pour tout software.

La mise en place d'un système d'alerte robuste dans votre CI/CD est d'une importance capitale pour garantir la réactivité et la fiabilité de vos opérations de développement et de déploiement. L'alerting permet de surveiller en temps réel chaque étape de votre pipeline CI/CD, identifiant ainsi toute anomalie, tout retard ou tout échec potentiel. En recevant des alertes immédiates lorsqu'un problème survient, l'équipe peut intervenir rapidement pour diagnostiquer, résoudre et rétablir la stabilité du pipeline. Cela réduit considérablement les temps d'arrêt, optimise le temps de réaction et contribue à maintenir la fluidité et l'efficacité de la chaîne de livraison logicielle.

De plus, l'alerting dans la CI/CD favorise une culture de responsabilité et d'amélioration continue au sein de l'équipe de développement. En recevant des alertes en temps réel, chaque membre de l'équipe est informé de l'état du pipeline et de tout incident potentiel. Cela encourage une réactivité immédiate et incite les membres de l'équipe à résoudre les problèmes rapidement et efficacement. De plus, ces alertes fournissent des données exploitables pour effectuer des analyses post-mortem, identifier les problèmes récurrents et itérer constamment le processus afin d'améliorer la robustesse et l'efficacité de la CI/CD. En fin de compte, l'alerting sert non seulement à maintenir des opérations fluides, mais aussi à stimuler l'innovation et l'efficacité de l'équipe de développement.

Comment on fait ? 💡

Pour la plupart des outils de CI connus, vous pouvez récupérer les métriques et les utiliser dans un dashboard datadog ou autre

Par exemple :

Gitlab CI
Github Action
Circle CI :

⚠️ Circle CI ont leur propre solution de monitoring
- Voir les métriques
- Envoyer des notifications

Voilà j’espère vous avoir donner des idées pour améliorer votre pipeline de CI/CD 🐵

Différentes façons de déployer une application front faites en JS

Jérémy Chauvin — Wed, 12 Jul 2023 17:18:19 +0000

Nous avons tous déjà vécu l'expérience de travailler sur un side Project, de coder l'ensemble de l'application, puis de se demander : « Comment vais-je le déployer ? ».

Dans cet article, vous allez (re)découvrir les différentes façons de déployer votre application front, ainsi que les cas où il est plus intéressant d'utiliser telle ou telle méthode.

Mais avant de parler de déploiement, il faut expliquer les différentes implémentations d'application que vous pouvez rencontrer.

Plusieurs implémentations d’application front JS

💡 Ici on va expliquer grossièrement les différences entre les plusieurs types d’implémentations, car certains déploiements ne peuvent être fait avec certaines implémentations

SPA ( Single Page Application )

Ce genre d'implémentation est vraiment simple. Elle est composée d’un fichier HTML qui fait référence à un fichier JS (aussi appelé bundle). Ce bundle permet de charger tout le contenu de la page côté client.

Lorsque vous exécutez votre commande de build pour votre application, vous obtenez:
- index.html
- script.js (un bundle)
- public (un dossier contenant des images et le favicon du site)
- style.css (un bundle de votre CSS)
Ce genre d'implémentation est souvent utilisé dans les nouvelles librairies front telles que React, Vue, Angular ou Svelte (et sûrement d'autres).
SSG ( Static Site Generator )

Cette implémentation permet de générer des pages HTML statiques à partir de fichiers sources, tels que des fichiers Markdown. Le SSG est très souvent utilisé pour créer des blogs ou des sites vitrines.

Pour savoir si vous utilisez un SSG, c'est assez facile. Lorsque vous allez construire votre application, dans votre sortie vous allez voir votre structure de fichier être transformée en fichier HTML, par exemple :

Les bibliothèques/frameworks qui existent pour faire du SSG : GitBook, Docusaurus, Vitepress, Starlight, îles et pleins d'autres.

SSR ( Server Side Rendering )

Cette implémentation permet de générer le rendu HTML côté serveur, comme en PHP ou en Java avec les JSP, et de n'envoyer que le strict minimum à l'utilisateur.

Pour savoir si vous utilisez cette méthode d'implémentation, il faut consulter la documentation de votre framework ou de vos bibliothèques. Il n'y a pas de manière simple de le savoir.

Parmi les frameworks qui proposent du SSR, on retrouve Astro, SvelteKit, Nuxt, Next et d'autres.

Différentes façons de déployer une application front

Lorsqu'il s'agit de déployer une application front, il existe plusieurs méthodes à considérer. Voici les façons les plus courantes de le faire :

💡 J’ai mis en place un tableau dans les méthodes de déploiement pour savoir si elles sont adaptées en fonction de l’implémentation.

Voici la légende du tableau:

Pastille de couleurs	Description
🌟	Solution Idéale
✅	Solution fonctionnelle
❌	Impossible

Utilisation de bucket/S3

Implémentation front	Possible ?
SPA	✅
SSG	🌟
SSR	❌

Vous pouvez utiliser un service de stockage de fichiers (bucket) ou S3 pour héberger votre site web, mais cela n'est possible que pour les applications de type SSG et SPA. Il est impossible de déployer une application SSR sur un bucket car il n'y a pas de serveur node qui permet de générer les pages HTML.

⚠️ Attention pour les SPA, si vous les déployez sur un bucket/S3, vous devez mettre l’index.html en entrée par défaut et en entrée si le fichier n’est pas trouvé dans votre bucket. Par exemple, vous avez une route nommer /blog votre bucket va chercher un fichier nommée blog.html à la racine. Mais comme dit plus haut pour les SPA, il n’existe que votre fichier index.html

⚠️ Un déploiement avec un bucket/S3 sera en HTTP. La redirection DNS suffit pour avoir votre site en HTTPS, mais il y a quand même un risque de sécurité. AWS à leur propre solution pour passer l’URL de votre S3 en HTTPS

Les avantages :

Facile à mettre en place ( peu de connaissance technique pour le mettre en place )
Évite les coûts et les contraintes d'un serveur
Haute dispo & scalabilité

Les désavantages:

Peut vite devenir cher, si vous avez beaucoup de visites
Zéro contrôle sur l’environnement, vous ne pouvez seulement specifier le fichier d’entrées et le fichier si aucun fichier n’est trouvé
Très peu sécurisés, tout les fichiers dans les buckets sont accessibles

Cas d’utilisation intéressant:

Le cas d’utilisation intéressant pour ce type de déploiement est :

les sites statiques ( blog, landing page )

Utilisation de services de PaaS ( Plateforme as a Service )

Les services de PaaS tels que Netlify, Vercel ou encore Clever Cloud sont des plateformes de déploiement qui permettent de déployer rapidement des applications. Ces services prennent en charge la génération de sites statiques mais depuis peu les implémentations dynamiques comme le SSR.

Implémentation front	Possible ?
SPA	🌟
SSG	🌟
SSR	🌟

Avantages :

Facile à mettre en place ( peu de connaissance technique pour le mettre en place )
Évite les coûts et les contraintes d'un serveur
La version gratuite peut-être suffisant au début
Beaucoup de feature intéressante, comme les environnements générés sur chaque PR

Désavantages :

Coût mensuel ou annuel pour l'utilisation de la plateforme
Limitations de personnalisation et de configuration
Dépendance à un tiers pour le déploiement et l'hébergement ( Un peu vrai pour tous les services cloud )

Cas d’utilisation intéressant:

Le cas d’utilisation intéressant pour ce type de déploiement est :

Le début d’un side projet pour livrer le plus rapidement possible de la valeurs sans se prendre la tête

Utilisation d’un service CaaS ( Container as a service )

Vous pouvez aussi déployer votre application sous forme de containers. Pour ce faire, vous devez créer une image, avec un dockerfile ou encore en passant par buildpack. Une fois votre image créée et mise sur une registry accessible, vous pouvez la deployer via des services cloud comme GCP, AWS, Azure, Scaleway voir même sur certains services de PaaS comme Clever Cloud

Implémentation front	Possible ?
SPA	✅
SSG	✅
SSR	🌟

Avantages :

Possibilité de déployer sur de multiples environnements assez facilement
Possibilité de personnaliser le déploiement et la configuration de l'environnement
Possibilité de gérer efficacement les ressources et de réduire les coûts
Possibilité de mettre en place des stratégies de scalabilité horizontales

Désavantages :

Nécessite des compétences techniques et une certaine expertise pour mettre en place et gérer l'environnement de déploiement
Coûts associés à l'utilisation de services cloud pour héberger l'application
Complexité accrue par rapport à d'autres méthodes de déploiement plus simples

Cas d’utilisation intéressant:

Le cas d’utilisation intéressant pour ce type de déploiement est :

Si vous êtes en entreprise et qu’il y a déjà un cluster kube pour déployer vos applications et qu’on vous interdit d’utiliser un PaaS

Utilisation d’un Serveur ou VM dédié

Vous pouvez aussi déployer vos applications front depuis un serveur dédié ou une VM. Pour ce faire, il suffit de mettre en place un reverse proxy comme Nginx, Traefik, HaProxy et certainement d’autres.

⚠️ Si vous voulez déployer du SSR sur un serveur dédié, il faut penser à mettre en place un serveur node, si vous faites du Next, Nuxt ou SvelteKit. Si vous faites du PHP, n’oubliez pas d’en mettre un aussi sinon ça ne va pas fonctionner.

Implémentation front	Possible ?
SPA	✅
SSG	✅
SSR	🌟

Avantages :

Possibilité de personnaliser le déploiement
Contrôle total sur l'environnement de l'application
Pas de coûts supplémentaires pour l'utilisation d'une plateforme tierce
Possibilité d'ajouter des modules et des bibliothèques personnalisées
Possibilité de gérer les ressources et de réduire les coûts

Désavantages :

Nécessite des compétences techniques et une certaine expertise pour la mise en place et la gestion de l'environnement de déploiement
Complexité accrue par rapport à d'autres méthodes de déploiement plus simples
Risques de sécurité plus élevés en cas d'erreurs de configuration
Nécessite une maintenance régulière pour garantir la sécurité et les performances de l'application

Cas d’utilisation intéressant:

Le cas d’utilisation intéressant pour ce type de déploiement est :

Pour apprendre la complexité de deployer et de maintenir un serveur web soi-même

Tableau récapitulatif

	SPA	SSG	SSR
Bucket/S3	✅	🌟	❌
PaaS	🌟	🌟	🌟
CaaS	✅	✅	🌟
Serveur ou VM dédié	✅	✅	🌟

Conclusion

Il existe beaucoup moyen de déployer une application front, mais chaque façon de déployer a des avantages comme des inconvénients. Il est donc important de le savoir, par contre ce choix ne doit pas vous bloquer. Vous pouvez logiquement le changer sans problèmes.

Voilà j’espère vous avoir donner des idées pour déployer votre application front que ça soit votre blog ou vos sides projects 🐵