Le blog changeloop
Les release notes, en pratique
Deux sujets qui nous occupent beaucoup : comment écrire des release notes que quelqu'un lit, et comment arrêter de tenir un changelog à la main. Pas de newsletter, pas d'inscription. Juste les articles.
Release notes de correctifs : écrire des entrées utiles
Les release notes de correctifs marchent si chaque entrée nomme le symptôme, les personnes touchées et la suite. Réécritures, sécurité et perte de données.
Release notes en pratique8 min de lecture
Comment demander un feedback client dans un produit logiciel
Posez une question précise juste après une action, là où l'utilisateur travaille. Formulations prêtes à l'emploi pour chaque moment, et erreurs à éviter.
Boucle de feedback8 min de lecture
Exemples de roadmap produit : six formats et leurs limites
Six exemples de roadmap produit avec des éléments réalistes : Now/Next/Later, trimestrielle, thèmes, résultats, publique et de release. Atouts et limites.
Boucle de feedback8 min de lecture
Release management : processus pour équipes qui livrent vite
Un processus de release management en sept étapes, avec responsable et critères de sortie, plus les métriques DORA et un KPI supplémentaire à suivre.
Ingénierie8 min de lecture
Exemples de release notes pour chaque type de changement
Exemples de release notes pour une fonctionnalité, un correctif, un changement cassant, une faille, une dépréciation, l'app store et une note interne.
Release notes en pratique8 min de lecture
Versionnage de l'API Stripe : fonctionnement et à copier
Le versionnage de l'API Stripe épingle chaque compte sur une version datée et laisse chaque requête la changer. Fonctionnement, coût, ce qu'on peut copier.
Changements d'API8 min de lecture
Qui écrit le changelog, et qui devrait l'écrire
Qui écrit le changelog ? L'autrice de la PR sait ce qui a changé, la PM pourquoi ça compte. Seule, aucune n'écrit une entrée vraiment utile aux clients.
Ingénierie6 min de lecture
Release notes d'urgence : écrire sous vraie pression
Une version pilotée par un incident a besoin de notes écrites en minutes, pas en jours, et le processus habituel de rédaction suppose un temps absent.
Release notes en pratique6 min de lecture
Changements cassants Protobuf : ce qui survit sur le fil
Les changements cassants Protobuf se jouent sur le fil, pas dans l'URL. Certains changements gRPC sont gratuits, d'autres cassent chaque client en silence.
Changements d'API7 min de lecture
Formats de fichier changelog : JSON, YAML ou juste Markdown
Le format d'un fichier changelog décide s'il alimente une page et un widget, ou n'est lu que par une personne. Markdown, JSON et YAML coûtent différemment.
Ingénierie6 min de lecture
Demandes dupliquées : fusionner sans perdre la voix
Regrouper les demandes dupliquées protège le décompte. Les fusionner sans soin perd la formulation qui rendait l'une d'elles utile, la perte moindre.
Boucle de feedback6 min de lecture
Dépréciation GraphQL sans numéro de version
GraphQL n'a pas de v1 ni v2 dans l'URL. Les champs sont dépréciés un par un via une directive, dans un schéma commun, et cela change le changelog.
Changements d'API6 min de lecture
Comment écrire un guide de migration d'API
Un guide de migration d'API transforme un changement incompatible en checklist. Ce qu'il doit contenir, et pourquoi une entrée de changelog ne suffit pas.
Changements d'API6 min de lecture
Un check de changelog pour GitHub Actions
Un check de changelog dans GitHub Actions refuse de merger sans entrée, car une étape qui dépend de la mémoire échoue à coup sûr. Et ce que ce check casse.
Ingénierie6 min de lecture
Refuser une demande de fonctionnalité sans perdre la cliente
Boucler la boucle veut souvent dire annoncer une livraison. La moitié difficile, c'est dire non, d'une façon qui ne casse pas la relation avec la cliente.
Boucle de feedback6 min de lecture
Release notes de feature flag : quoi dire, et quand
Les release notes de feature flag séparent fusion et livraison, qui ne coïncident plus avec un flag. Boucler trop tôt annonce une fonction invisible.
Boucle de feedback6 min de lecture
Quand une demande de fonctionnalité est en fait un bug
Un ticket demandant un réglage peut être un contournement pour un bug caché. La mauvaise étiquette l'envoie à la mauvaise responsable et file.
Boucle de feedback6 min de lecture
Suivre les demandes de fonctionnalités sans les perdre
Le suivi des demandes échoue de deux façons : elles n'arrivent nulle part, ou arrivent où personne ne revisite. Un système qui résiste aux deux.
Boucle de feedback7 min de lecture
Tickets support vs. demandes : qui croire ?
Un ticket support et un tableau de demandes mesurent des choses différentes, et traiter un pic dans l'un comme dans l'autre produit des priorités erronées.
Boucle de feedback6 min de lecture
Tags git, releases et votre changelog
Un tag git, une release, une entrée de changelog : trois enregistrements d'un événement. Les confondre fait dériver le changelog. Comment les accorder.
Ingénierie6 min de lecture
Changelogs d'API internes : ce qui change
Un changelog d'API publique a un public qu'on ne peut pas contacter directement. Un interne a un public à deux étages, et ça change ce qu'on lui doit.
Changements d'API6 min de lecture
Notes de release internes : qui d'autre doit savoir
Le support et les ventes apprennent souvent un lancement par une cliente perdue. Les notes internes règlent ça, sous une forme distincte des notes clients.
Release notes en pratique6 min de lecture
Release notes mobiles : ce que la limite fait sauter
App Store et Play Store donnent peu de lignes visibles et aucun lien. Ce qui marche sur un changelog web se casse avec ce budget si restreint.
Release notes en pratique5 min de lecture
Changelogs de monorepo : un seul, ou un par package ?
Un monorepo peut avoir un changelog pour tout le repo ou un par package, et se tromper rend chaque release trop bruyante ou trop dispersée à trouver.
Ingénierie6 min de lecture
Comment annoncer une nouvelle fonctionnalité (sans silence)
La plupart des annonces meurent dans un canal lu une seule fois. Où annoncer, quoi dire en premier, et comment atteindre celles qui l'ont demandée.
Release notes en pratique6 min de lecture
Prioriser les demandes de fonctionnalités qui s'accumulent
Un backlog laisse ouverte la question difficile : quelle demande sort en premier. Les cadres utiles, où chacun se casse, et ce qu'un compte de votes cache.
Boucle de feedback6 min de lecture
Release notes enterprise : ce qui change pour un compte
Les release notes enterprise d'un client sur un build privé doivent coller à son instance. Mal réglées, elles révèlent la roadmap ou égarent son support.
Release notes en pratique6 min de lecture
Semantic versioning et votre changelog
Le semantic versioning dit combien une release peut faire mal avant qu'on lise le changelog. Ce que chaque chiffre promet, et ce qu'une entrée doit tenir.
Ingénierie6 min de lecture
L'en-tête sunset d'API, et quand l'envoyer
L'en-tête sunset d'API dit quand une version cessera de répondre, à la différence d'une dépréciation. Ce que couvre la RFC 8594, ce qu'apporte un brownout.
Changements d'API6 min de lecture
Changelogs de webhooks : le changement cassant non demandé
Un changement de payload de webhook casse en silence, car personne ne peut le rejeter. Ce qui rend ce changement cassant, et comment le versionner.
Changements d'API6 min de lecture
Changelog : définition et exemple d'entrée
Un changelog est le registre daté des changements d'un produit. Un exemple d'entrée, la différence avec les release notes et le commit log, et où publier.
Release notes en pratique6 min de lecture
Changelog d'API : quoi publier et qui le lit
Un changelog d'API est lu par des gens qui décident si leur code marchera encore le mois prochain. Ce que doit chaque entrée, où il vit, comment suivre.
Changements d'API7 min de lecture
Construire une page de changelog que l'on suit
Une page de changelog vaut la peine quand quelqu'un y revient. Où elle vit, ce dont une entrée a besoin, flux et balisage, et la place du widget.
Ingénierie7 min de lecture
Le modèle d'email de mise à jour produit qu'on lit
L'email de mise à jour produit qu'on lit est allé à quelqu'un qui l'avait demandé. Un modèle, les quatre types d'emails, bons objets, le consentement.
Release notes en pratique7 min de lecture
Comment déprécier une API sans perdre ses développeurs
La dépréciation est une promesse avec une date. Le calendrier, le modèle d'avis, les en-têtes de réponse, et l'étape qui évite un incident au sunset.
Changements d'API7 min de lecture
Bonnes pratiques de versionnage d'API, pour les appelants
Versionnez seulement ce qui casse, mettez la version où les appelants la voient, et gardez l'ancienne active jusqu'à une date. Quatre schémas comparés.
Changements d'API8 min de lecture
Changements cassants : ce qui compte, comment en livrer un
Un changement cassant est tout changement qu'un appelant correct ne pourrait pas survivre. Ce qui compte, ce qui ne compte pas, comment le repérer en CI.
Changements d'API10 min de lecture
Fermer la boucle de feedback depuis le changelog
Une boucle de feedback se ferme quand qui a demandé sait que c'est livré. La boucle en quatre étapes, où elle casse, et pourquoi le changelog convient.
Boucle de feedback9 min de lecture
Template de demande de fonctionnalité qui devient changelog
Une demande de fonctionnalité ne sert que si on la retrouve à la livraison. Le modèle, les labels qui la routent et les champs que lit le changelog.
Boucle de feedback7 min de lecture
Roadmap publique depuis votre issue tracker, trois colonnes
Une roadmap publique est une promesse sur l'avenir. Gardez-la petite, alimentez-la depuis vos issues et déplacez chaque élément avec un label sur l'issue.
Boucle de feedback6 min de lecture
Automatisation du changelog, et ses limites
Automatisez collecte, formatage et publication. N'automatisez ni la sélection ni la formulation. Où se situe la ligne et ce qui arrive quand elle bouge.
Ingénierie7 min de lecture
Changelog vs release notes : quelle est la différence ?
Un changelog est un registre continu pour qui cherche quelque chose. Les release notes sont un message trié pour qui décide si ça l'intéresse. La division.
Release notes en pratique6 min de lecture
Des conventional commits à un changelog
Les conventional commits rendent un changelog dérivable, pas lisible. Ce que la convention apporte, où elle s'arrête, et comment combler l'écart.
Ingénierie6 min de lecture
Comment écrire des release notes que les gens lisent
«Corrections de bugs et améliorations de performance» n'est pas une release note. La question que chaque entrée doit résoudre, et une réécriture réelle.
Release notes en pratique7 min de lecture
Keep a Changelog, vraiment implémenté
La spec Keep a Changelog tient en une page et se lit en dix minutes. Les équipes dérivent en l'appliquant. Ce qu'elle dit, ce qu'elle laisse ouvert.
Ingénierie6 min de lecture
Bonnes pratiques des release notes qui comptent
Les listes de bonnes pratiques sont des conseils de style. Celles-ci changent ce que fait le lecteur, et trois conseils courants sont du folklore.
Release notes en pratique6 min de lecture