Des pull requests fusionnées au changelog publié
Okou lit les pull requests fusionnées cette semaine, garde celles qui concernent vos utilisateurs, rédige l'article de changelog et le publie sur votre blog, votre liste Resend et X dans la même exécution, une fois le brouillon validé.
Qu'est-ce que l'automatisation du changelog ?
L'automatisation du changelog consiste à générer votre actualité produit à partir du travail réellement fusionné par l'équipe, au lieu de l'écrire de mémoire en fin de semaine. Okou est l'agent au milieu : il lit les pull requests fusionnées sur GitHub, garde celles qui concernent les utilisateurs, les regroupe par thèmes, rédige l'article de changelog et le publie sur votre blog, en newsletter Resend et en fil X en une seule exécution. Le résultat est une actualité produit hebdomadaire qui sort à l'heure et dit la même chose sur tous les canaux.
Pourquoi le changelog hebdomadaire mange un vendredi
Vendredi après-midi. Une trentaine de pull requests ont été fusionnées cette semaine et quelqu'un doit en tirer une actualité que les gens liront vraiment. Vous parcourez la liste des merges, devinez lesquels concernent les utilisateurs, écrivez l'article, le raccourcissez pour l'e-mail, le raccourcissez encore pour X, puis collez chaque version dans un outil différent. C'est la même lecture trois fois, et ce qui arrive sur X ne dit presque jamais exactement la même chose que ce qui est arrivé dans la boîte de réception.
Comment Okou transforme une semaine de merges en changelog publié
Étape 1 : Connectez vos outils
Étape 2 : Demandez à Okou
Étape 3 : Allez plus loin
Intégrations GitHub, Resend, X et Slack pour automatiser le changelog
Ce workflow lit dans un outil et écrit dans trois. GitHub est la seule source de vérité sur ce qui a été livré ; Resend et X sont des destinations ; Slack est l'endroit où le brouillon attend une personne. Chaque connecteur est accordé séparément et limité à ce que le workflow utilise réellement : un accès en lecture à votre dépôt n'implique donc jamais le droit de publier depuis votre compte.
Intégration GitHub : ce que Okou lit pour construire le changelog
RequisOkou interroge les pull requests fusionnées dans les dépôts que vous indiquez sur la période choisie et lit, pour chacune, le titre, le corps, les libellés, l'heure de fusion, l'auteur et les chemins de fichiers modifiés. Ces cinq signaux distinguent un changement visible d'une refactorisation interne : un libellé de note de release est le plus fort, les chemins modifiés attrapent ceux que personne n'a étiquetés, et le corps apporte le détail que le titre laisse de côté. Dans ce workflow, l'intégration GitHub est en lecture seule. Okou n'ouvre aucune issue, ne pousse aucun commit et ne modifie aucune pull request. Pointez-le vers plusieurs dépôts et il les lit dans la même passe : un frontend et un backend séparés donnent quand même un seul changelog.
Intégration Resend : la newsletter que Okou envoie
RequisOkou lit vos audiences Resend pour pouvoir désigner celle que vous nommez par son nom plutôt que par un identifiant, puis crée et envoie la campagne : objet, pré-en-tête, corps HTML et version texte. Après l'envoi, il relit le résultat et indique combien de messages ont été remis, différés et rejetés, ce qui explique que le rapport et la campagne ne se contredisent jamais. Le droit d'envoi est accordé séparément de l'accès en lecture aux audiences, et Okou n'ajoute, ne supprime ni n'exporte jamais de contacts.
Intégration X : le fil que Okou publie
RequisLe fil est écrit pour X, pas tronqué depuis l'article : une publication par thème, une ouverture qui dit ce qui a changé et une publication finale qui renvoie au texte complet. Okou publie chaque entrée en réponse à la précédente pour que le fil tienne ensemble, et vérifie la longueur avant publication plutôt que de laisser une publication être coupée. L'accès en écriture est limité au compte connecté, et publier le fil est tout ce qu'il fait. Okou ne lit ni votre fil d'actualité, ni vos mentions, ni vos messages privés.
Intégration Slack : là où le brouillon attend la validation
OptionnelSlack est facultatif et gagne sa place à l'étape de validation. Okou publie le brouillon complet dans le canal que vous indiquez, texte du blog, objet de l'e-mail et chaque publication du fil compris, puis s'arrête. Rien n'est publié tant que personne n'a validé, et vous pouvez demander une réécriture dans le même fil pour recevoir le brouillon mis à jour sur place. Sans Slack, le workflow se déroule quand même de bout en bout : le brouillon revient là où vous avez lancé l'exécution.
Okou, l'écriture manuelle et un générateur de changelog
Automatiser le changelog, ce sont deux problèmes : décider ce qui mérite d'être annoncé, et porter cette annonce sur tous les canaux. La plupart des outils n'en résolvent qu'un.
L'écrire à la main
Quelqu'un lit la liste des merges, décide de ce qui compte, écrit l'article puis le réécrit deux fois pour l'e-mail et pour X. Le jugement est bon et le ton est juste, mais cela coûte les mêmes 90 minutes chaque semaine et c'est la première chose sacrifiée dans une semaine chargée.
Un générateur de changelog
Les titres de commits ou de pull requests sont rassemblés automatiquement sur une page de notes de release. Aucun merge n'est oublié, mais ce sont des titres qui sont publiés et non des thèmes, une refactorisation ne se distingue pas d'une fonctionnalité, et tout s'arrête à une seule destination.
Le workflow de changelog de Okou
Okou lit les mêmes merges, applique votre règle sur ce qui concerne les utilisateurs, regroupe le reste par thèmes et rédige le texte de chaque canal. Blog, Resend et X sont publiés depuis un unique brouillon validé en une exécution, et l'exécution indique ce qui a été retenu et pourquoi.
Conseils pour de meilleurs résultats
Questions fréquentes
Comment automatiser un changelog à partir des pull requests GitHub ?
Connectez GitHub à Okou et donnez-lui une planification ou un déclencheur de release. Okou lit les pull requests fusionnées sur la période, les filtre avec votre règle sur ce qui concerne les utilisateurs, regroupe les survivantes par thèmes et rédige l'article de changelog. Ajoutez Resend et X et la même exécution le publiera aussi sur ces canaux.
Comment Okou décide-t-il quels merges concernent les utilisateurs ?
Selon la règle que vous lui donnez, appliquée à quatre signaux : le libellé de note de release, les chemins de fichiers modifiés, le titre de la pull request et son corps. Le libellé est le signal le plus fort et celui que la plupart des équipes finissent par standardiser. Tout ce que Okou exclut figure dans le rapport d'exécution avec sa raison : une mauvaise décision se voit au lieu de passer inaperçue.
Peut-on publier un même brouillon en newsletter et sur X en même temps ?
Oui. Okou écrit les thèmes une fois, puis les adapte à chaque canal : l'article complet sur le blog, l'e-mail au format boîte de réception avec objet et pré-en-tête, et un fil comptant une publication par thème. Les trois sont publiés dans la même exécution depuis le même brouillon validé, donc les faits ne peuvent pas diverger d'un canal à l'autre.
Quelque chose peut-il être publié sans ma validation ?
Non, sauf si vous le demandez. Par défaut, Okou publie le brouillon dans un canal et attend. Vous pouvez le valider, demander une réécriture dans le même fil ou l'abandonner. Si vous préférez une publication sans supervision, dites-le dans le prompt et Okou saute l'étape de validation.
De quels outils cette automatisation du changelog a-t-elle besoin ?
GitHub est requis comme source de ce qui a été livré. Resend et X sont requis comme les deux destinations de publication. Slack est facultatif et ne sert qu'à l'étape de validation ; sans lui, le brouillon revient là où vous avez lancé l'exécution.
Quelles autorisations ce workflow demande-t-il ?
GitHub a besoin d'un accès en lecture aux dépôts depuis lesquels vous publiez. Resend a besoin du droit d'envoi et d'un accès en lecture aux audiences. X a besoin d'un accès en écriture sur le compte qui publie le fil. Slack, si vous l'utilisez, doit pouvoir publier dans le canal de validation. Chaque connecteur est accordé séparément dans Okou, et en révoquer un laisse les autres intacts.
Okou peut-il construire un seul changelog à partir de plusieurs dépôts ?
Oui. Nommez chaque dépôt dans le prompt et Okou les lit dans la même passe, puis regroupe les changements selon le comportement qu'ils modifient plutôt que selon leur dépôt d'origine. Un frontend et un backend séparés donnent quand même un seul article.
Puis-je le déclencher sur un tag de release plutôt qu'une planification hebdomadaire ?
Oui. Créez une automatisation qui démarre le workflow quand une release est taguée sur GitHub. Okou construit alors le changelog à partir des pull requests de cette release plutôt que d'une fenêtre de dates, et le reste de l'exécution est identique.
Publiez le changelog de cette semaine
Connectez GitHub, Resend et X, puis utilisez le prompt hebdomadaire pour voir toute l'exécution : lecture, regroupement, rédaction, validation, publication.