Au fur et à mesure que vous itérez sur les systèmes numériques, il peut être difficile de garder une trace de ce qui a changé et pourquoi, c’est là qu’un changelog devient utile.
Un Changelog est un enregistrement numérique. Dans ce document, nous documentons chronologiquement les modifications apportées à un logiciel ou à un système. Dans la conception Web, nous pouvons créer des changelogs pour les sites Web et les applications, la documentation qui les prend en charge et même les systèmes de conception.
Dans cet article, nous expliquerons les avantages des changelogs ainsi que des conseils pour créer et maintenir un modificateur pour votre produit ou système numérique.
Pourquoi tu as besoin d’un modifice
Il existe de nombreuses raisons de conserver un changelog pour chacun des systèmes numériques que votre équipe gère:
Meilleure communication
Les changelogs sont un moyen efficace de communiquer des changements liés à votre logiciel – et à une variété d’utilisateurs également.
Bien qu’il soit crucial que tous les membres de votre équipe de développement soient conscients de ce qui a changé et quand cela s’est produit, bon nombre de vos utilisateurs finaux peuvent également vouloir faire référence à ce journal. Les changelogs sont également un bon moyen de garder d’autres équipes au courant de ce qui a changé.
Par exemple, si les utilisateurs commencent à signaler la même erreur, votre équipe d’assistance peut se tourner vers le Changelog pour voir si quelque chose a changé avant la possibilité de résoudre le problème. Il peut également s’agir d’une ressource utile pour les équipes de marketing et de vente qui peuvent avoir besoin d’ajuster leurs stratégies ou leurs messages si une fonctionnalité a été supprimée ou de nouvelles ajoutées.
Transparence et responsabilité
Pensez au nombre d’applications que nous utilisons quotidiennement et à combien nous savons peu de ce qui se passe avec eux dans les coulisses. Bien que nous soyons souvent informés des grandes sorties avec de nouvelles fonctionnalités sophistiquées ou des UIS remaniées, tous les développeurs de logiciels ne sont pas aussi à venir en ce qui concerne les ajustements plus petits ou sensibles qui gardent réellement l’application en bonne forme – et nous en sécurité tout en l’utilisant.
Publier un Changelog pour que quiconque puisse le voir différenciera votre produit des autres. Cela montrera également aux utilisateurs à quel point le logiciel est bien soigné, même si vous ne l’avez affiner qu’une fois par mois environ.
Dossier historique précis
Les notes de libération et les changelogs peuvent parfois être confus les uns pour les autres. Les notes de version ont tendance à se concentrer sur l’évolution du logiciel de la version à la version. Il raconte une histoire beaucoup plus grande et flatteuse.
Un Changelog, en revanche, a tendance à être bref et axé sur les mises à jour techniques. Il montre aux utilisateurs ce qui a changé au fil du temps, peu importe la taille ou la taille. Il documente également les bogues, les pannes, les problèmes de performances et autres problèmes techniques importants.
En gardant une trace de ce qui s’est passé, votre équipe peut en apprendre beaucoup sur ce que votre produit a besoin pour être bien entretenu et peut les aider à atténuer les problèmes à l’avenir.
Conseils pour construire et maintenir un changelog
Si vous cherchez à construire un changelog pour la première fois ou à vous demander comment améliorer un existant, voici quelques conseils pour vous aider à en tirer le meilleur parti:
1. Créez une structure pour cela
Les changelogs peuvent devenir assez longs avec le temps. Pour conserver leur utilité, établissez une structure définie pour chaque version.
Par exemple, votre structure peut cohérente des éléments suivants:
- Numéro de version – par exemple, «v3.1.5»
- Date de sortie -Eg, «2025-06-19»
- Type d’amélioration – « ajouté »
- Description – «Page Paramètres d’abonnement aux comptes d’utilisateurs»
Gardez la structure concise et uniforme. Vous pouvez même utiliser une table pour garder tout organisé, si vous préférez.
Voici comment le Système de conception Nord a structuré sa page de notes de sortie / Changelog:
Ce que nous voyons ici est un modificateur bien organisé. Pour commencer, il y a une section pour les différents aspects du système de conception, comme les composants Web, le cadre CSS, les jetons de conception, etc.
De plus, chaque version regroupe souvent les types de changement, de sorte que «ajouter» reste avec «ajouts», «améliore» le reste avec «améliore» et ainsi de suite.
Bien qu’une structure définie puisse améliorer la convivialité, elle permettra également aux membres de votre équipe de contribuer au modificateur. Avec un lexique défini et des règles, tout le monde peut aider à le maintenir, donc la responsabilité ne se contente pas de monter sur les épaules d’une personne.
2. Documenter tous les modifications
Les notes de version sont l’endroit où vous pouvez promouvoir toutes les nouvelles choses sympas qui se produisent dans la dernière version de votre produit. Les Changelogs, cependant, devraient entrer dans le Nitty granuleux de toutes les modifications que vous avez apportées, même si elles ne semblent pas positives.
Par exemple, votre changelog devrait documenter et étiqueter ces types de modifications:
- Ajouté ou Nouveau: Pour les nouvelles fonctionnalités
- Supprimé ou À la retraite: Pour les fonctionnalités qui ont été retirées
- Déprécié: Pour les fonctionnalités obsolètes et prévues pour être supprimées
- Modifié: Pour les fonctionnalités modifiées
- Fixé: Pour les fonctionnalités de buggy qui ont été réparées
- Sécurité: Pour les mises à jour liées à la sécurité
- Prochain: Pour les fonctionnalités ou les modifications prévues pour l’avenir
En utilisant des étiquettes cohérentes et des normes de documentation dans le changelog, cela facilitera beaucoup les utilisateurs de tous les niveaux techniques de comprendre ce qui a changé.
Changelog d’Asana est un exemple unique car il est publié dans le Forum des développeurs:
Comme l’explique l’entreprise:
«Nous avons choisi de mettre le Changelog dans le forum à la place (plutôt que dans la documentation de l’API) pour ces deux avantages: le forum prend en charge les commentaires afin que les développeurs puissent poser des questions et donner des commentaires sur les modifications à venir et nous pouvons fournir des réponses. Les développeurs peuvent s’abonner aux mises à jour s’ils souhaitent être informés sur les modifications API à venir.»
Peu importe où il habite, vous pouvez voir que le Changelog comprend divers types de changements et les étiquette en tant que tels – EG, «à venir», «nouveau», «changement» et ainsi de suite.
3. Utilisez l’ordre chronologique inversé
Chaque entrée de votre Changelog doit avoir une date de sortie qui lui est associée et un numéro de libération unique. En règle générale, les versions majeures sont un nombre entier comme la v2.0.0 et les versions mineures sont écrites comme v2.1.0.
Lorsque vous les publiez sur la page, ajoutez la dernière version en haut afin que la liste soit dans l’ordre chronologique inverse. Les dernières mises à jour sont ce qui sera la plus concernée par vos utilisateurs, ce qui minimisera la quantité de défilement qu’ils font.
C’est quoi eBay fait:
C’est en fait le haut de la page des notes de version où des détails supplémentaires et des explications plus complètes sur les mises à jour de version sont écrites ci-dessous. Cependant, ce tableau fournit un résumé succinct des modifications apportées à chaque version, en commençant par la plus récente.
Une autre belle touche à cette page est l’historique de la version API trouvée dans la barre latérale droite, afin que les utilisateurs puissent cliquer et aller à une version qu’ils souhaitent explorer davantage.
4. Gardez la langue simple et accessible
Même si un Changelog est un document technique, cela ne signifie pas qu’il doit être complexe et trop compliqué pour un profane. Gardez-le court et gardez le libellé simple.
Considérez également votre public. À moins que vous ne sachiez que tous ceux qui accèdent au Changelog seront du même pays et parleront de la même langue, vous devrez vérifier qu’il est accessible.
Un langage simple vous aidera. Il en va de même pour les formats de version et de date que tout le monde peut comprendre. Par exemple, au lieu d’écrire vos dates de version comme Mm / dd / yyyyécrivez-les comme Yyyy / mm / dd.
Une autre option consiste à rédiger la date en totalité Spotify fait:
Ce changelog n’est plus accessible au public, mais vous pouvez voir à quel point il est facile de trouver le numéro de version et la date, et à quel point les formats conviviaux sont conviviaux.
Un autre écart auquel je devrais attirer l’attention est le format de ce changelog. Spotify ne semble pas publier les modifications en annonçant d’abord le type de modification (par exemple, «ajouté», «déprécié», etc.). Cependant, il a écrit ce changelog dans un langage simplifié et fourni des liens de référence afin que les utilisateurs puissent en savoir plus sur chacune des modifications.
5. Gardez un horaire
Votre Changelog est le reflet de la façon dont votre logiciel ou système est bien entretenu. Pour aider les utilisateurs et les membres de l’équipe à le remarquer, effectuez la mise à jour du Changelog en tandem avec les versions une priorité. Et créez un calendrier pour ces versions, même les mineures.
Les sorties n’ont pas besoin de sortir chaque semaine ou même de toutes les deux semaines si votre logiciel n’a pas besoin d’une tonne de maintenance. Mais trouvez un calendrier de mise à jour qui fonctionne pour vous et respectez-le. Cela aidera à définir les attentes avec vos utilisateurs et cela gardera également votre équipe à l’écoute de ce qui se passe avec le produit et l’expérience, afin qu’ils puissent le garder dans la meilleure forme possible.
Le Instagram Changelogpar exemple, semble suivre un horaire mensuel (pour la plupart).
Bien qu’il y ait quelques mois qui sont sautés, vous pouvez voir que ces instances suivent généralement un mois où il y avait de nombreuses versions. Donc, si votre équipe ne peut pas ou ne ressent pas le besoin de s’engager dans un calendrier de publication exact, c’est un bon moyen de procéder. Visez une fois par mois (ou quel que soit votre horaire préféré), mais ne vous engagez pas à des dates de libération spécifiques.
De plus, toutes les libérations ne seront pas prévues à l’avance. Par exemple, disons que le support client vous informe d’un bogue ou que votre équipe a découvert une vulnérabilité de sécurité. Ces types de modifications ne peuvent pas attendre vos versions prévues. Padrez le problème dès que possible et émettez une mise à jour du Changelog une fois qu’elle est faite.
Si votre équipe fait des heures supplémentaires pour réparer quelque chose d’urgence, vous pouvez toujours repousser la prochaine version pour leur donner une pause (ce qui peut être ce que Meta / Instagram a fait).
Emballage
La documentation est incroyablement importante lorsque vous êtes en charge de la construction et de la maintenance des logiciels et des systèmes. Mais nous n’avons pas seulement besoin de documentation pour nous parler des fonctionnalités ou de la façon d’exécuter des processus. Cela peut également nous faire savoir où nous avons été, ce que nous avons fait et pour fixer une piste pour ce qui va arriver.
C’est pourquoi il est essentiel d’avoir un modiage pour chaque application ou site Web que vous construisez avec tous les systèmes de conception ou les référentiels de documentation que vous maintenez. Le Changelog tient un enregistrement précis de ce qui a été fait, fournit à d’autres équipes et au public une transparence sur ce sur quoi vous travaillez et vous enseigne également ce que votre application doit prospérer.
Source link