VizDiff

VizDiff

vizdiff.io · Programmation

VizDiff est un outil auto-hébergé de régression visuelle pour Storybook. Il capture les composants en CI, signale les changements de pixels et publie des statuts sur GitLab ou GitHub avant le merge.

Aperçu de l'interface de VizDiff

À propos de VizDiff

What Is VizDiff

VizDiff repère les changements d'interface que la relecture du code seule laisse passer. Il s'appuie sur la configuration Storybook que vous avez déjà, capture une capture d'écran de chaque story à chaque commit et compare le nouvel ensemble à une base de référence enregistrée. C'est du test de capture Storybook en résumé, et chaque test de capture d'écran signale ce qui a bougé pour qu'une personne l'approuve ou le rejette.

L'outil tourne sur votre propre infrastructure. Pas de compte partagé dans le cloud, et les captures restent dans votre propre bucket de stockage. C'est du test de régression visuelle sans confier votre interface à un tiers. Si votre équipe compile déjà Storybook dans GitLab ou GitHub, VizDiff s'insère dans le pipeline existant plutôt que de vous demander de déménager ailleurs.

La limite principale tient au périmètre. VizDiff comprend les stories Storybook et presque rien d'autre, donc ceux qui testent des pages entières ou des parcours applicatifs ont besoin de quelque chose de plus large. Il suppose aussi que vous allez déployer et maintenir le service, ce qui l'écarte si vous ne voulez rien exploiter.

Getting Started

  1. Connectez-vous à VizDiff via votre fournisseur d'identité (Microsoft Entra ou SSO sur GitLab, GitHub OAuth sur GitHub).
  2. Ajoutez un projet et copiez le Project Token qu'il génère pour ce dépôt.
  3. Stockez le token sous VIZDIFF_PROJECT_TOKEN dans les secrets ou variables de votre CI.
  4. Ajoutez l'étape d'envoi à votre pipeline, en pointant vers le dossier de build Storybook, par exemple storybook-static.
  5. Ouvrez une merge request, relisez les captures recueillies dans VizDiff, puis approuvez ou rejetez le build.

Informations sur le produit

Aperçu des tarifs, des plateformes compatibles et des performances de VizDiff.

Offre gratuiteOui
Offres payantes$0 (open source under MIT)
PlateformeWeb (self-hosted via Docker or Helm)
Développeurvizdiff.io
CatégorieProgrammation
Date de lancementMar 2023
Dernière mise à jourJul 2025
Visites du siteN/A
Classement mondial du siteN/A
Disponibilité de l’APIOui

Idéal pour

Les utilisateurs, tâches et cas d'usage où cet outil convient le mieux.

Utilisateurs

  • Équipes frontend qui construisent des bibliothèques de composants dans Storybook et veulent attraper les régressions avant le merge
  • Utilisateurs de GitLab ou GitHub qui ont déjà un pipeline CI et ne veulent pas d'un compte séparé dans le cloud
  • Organisations avec des règles de données strictes qui ont besoin que les captures restent sur leur propre infrastructure
  • Développeurs solo sur de petits projets de composants qui peuvent lancer un déploiement Docker eux-mêmes

Tâches

  • Attraper une régression visuelle sur une pull request avant que le code n'atteigne la branche principale
  • Relire quelles stories ont changé entre deux builds Storybook et valider chacune
  • Maintenir une base de référence partagée de captures approuvées pour toute l'équipe
  • Bloquer automatiquement un merge quand un commit introduit des changements d'interface non approuvés

Cas d'usage

  • Refondre un composant du design system et voir précisément quels autres écrans ont été touchés
  • Maintenir une bibliothèque de composants qui grandit, où un petit changement de style se répercute sur des dizaines de stories
  • Travailler avec une équipe distribuée où les relecteurs ne peuvent pas lancer l'app en local pour juger l'interface
  • Durcir un processus de publication où les bugs d'interface continuent de passer après des tests unitaires au vert

Fonctionnalités clés

Storybook Integration

VizDiff lit les stories que votre équipe a déjà écrites, donc pas de suite de tests séparée à maintenir. Quand votre pipeline compile Storybook, la CLI envoie le résultat et l'outil génère une capture par story. Ajoutez un composant à Storybook, il apparaît dans la comparaison suivante sans configuration supplémentaire.

GitLab and GitHub Status Checks

L'outil publie un statut de commit sur les merge requests GitLab ou une vérification sur les pull requests GitHub. C'est du test visuel GitLab et du test visuel GitHub dans le même flux. Cette vérification reste en attente le temps que les captures se génèrent et qu'une personne relise les nouvelles ou les modifiées. Si rien n'a changé, elle passe en succès d'elle-même, donc les commits de routine passent sans que personne ne lève le petit doigt.

Pixel-Level Diff Views

Chaque story modifiée s'ouvre dans une boîte de comparaison avec les vues Old, New, Diff et 2-Up. La vue Diff joue le rôle d'outil de diff de pixels et met en évidence ce qui a bougé, et le mode 2-Up place les deux versions côte à côte. Les flèches du clavier vous font passer de l'une à l'autre, ce qui compte quand une seule branche touche des dizaines de stories.

Shared Baselines

Les captures approuvées deviennent la base de référence à laquelle le build suivant est comparé, et toute l'équipe travaille sur le même ensemble. Les captures sont stockées dans votre propre bucket compatible S3, donc les images de référence ne quittent jamais votre infrastructure. Créer une branche depuis un commit avec des captures approuvées garde la comparaison pertinente au lieu de la réinitialiser avec tout en nouveau.

Self-Hosted Deployment

VizDiff est distribué comme projet open source sous licence MIT et tourne comme trois services (api, worker, frontend) sur PostgreSQL et un bucket que vous fournissez. C'est une solution de régression visuelle auto-hébergée de bout en bout. Des images versionnées multi-architectures sont publiées sur GitHub Container Registry, et un fichier Docker Compose comme un chart Helm couvrent l'installation. Pas de compte éditeur ni de tarif par utilisateur.

Avantages et inconvénients

Avantages

  • Les captures et les bases de référence restent sur votre propre infrastructure, ce qui convient aux politiques de données strictes
  • Fonctionne avec le build Storybook que votre pipeline produit déjà, donc l'adoption se limite presque à une modification du CI
  • Les vérifications de statut bloquent les merges d'elles-mêmes et se libèrent quand rien n'a changé
  • Open source sous MIT, sans tarif par utilisateur à négocier
  • Un test de régression d'interface qui tourne en arrière-plan, si bien que les relecteurs ne regardent que quand quelque chose bouge
  • GitLab et GitHub sont pris en charge, y compris les instances GitLab auto-hébergées

Inconvénients

  • L'installation exige de déployer et maintenir le service, donc Docker, PostgreSQL et un bucket de stockage
  • Ne teste que les stories Storybook, donc les pages entières et les parcours à plusieurs étapes restent hors de portée
  • La première exécution sur une branche ne fait que créer la base de référence, donc les premiers commits affichent tout comme nouveau
  • La connexion dépend d'un fournisseur d'identité externe, donc une équipe purement locale a plus de choses à câbler

Questions fréquentes

Il capture une capture d'écran de chaque story Storybook quand votre pipeline CI tourne, compare les résultats aux bases de référence approuvées et signale celles qui ont changé. Ces changements apparaissent comme une vérification de statut sur votre merge request ou pull request, où un collègue les approuve ou les rejette.