Forem: Jérémy Chauvin

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 🐵