Votre changelog reprend les fonctionnalités que vous avez réalisé entre deux versions, ça tombe bien, votre historique git contient ces informations 🙂 On va voir comment les extraire de git pour générer automatiquement un changelog exhaustif et fiable.
Sommaire
Le principe
Pour faciliter la maintenance de votre projet, il est d’usage d’avoir des commits parlants afin que tous les développeurs puissent connaître les raisons d’un changement.
On va simplement appliquer une norme aux messages de nos commits:
Un bugfix commencera par fix:
Une feature commencera par feat:
etc..
Des outils permettent d’automatiser cette tâche comme commitzen:
Exemple:
Quand vous préparez une release, vous allez normalement créer un tag pour votre version.
Des utilitaires vont simplement lire les messages des commits qui ont eu lieu entre vos tags et vont déterminer lesquels écrire dans le changelog en fonction de leur préfixe, c’est tout !
Exemple concret
Si j’écrivais dans mon changelog à la main jusqu’à la version v0.1.0 et qu’à partir de la prochaine version v0.2.0 je veux qu’il soit généré automatiquement:
Le changelog a été édité pour la version v0.2.0 uniquement, c’est donc très facile à mettre en place car ça n’affecte pas les informations de vos précédentes versions !
Mise en place
Choisissez une convention de nommage et un outil adapté, c’est tout !
J’ai mis dans les exemples précédents un usage avec Commitzen car c’est ce que j’utilise au quotidien actuellement (et j’en suis satisfait) mais d’autres options existent.
Il arrive que la code review nous empêche de merge nos PR assez vite et qu’on se retrouve à tirer une branche d’une branche de travail pour avancer 😔
Une fois la première PR squash et merge, la PR issue de la seconde branche se retrouve avec des conflits 💥
Si vous avez déjà vécu cette situation, il y a de bonnes chances que vous ayez cherry-pick vos commits de travail sur une...
Il arrive souvent que pour tester unitairement des règles de validation, on doive tester le même cas mais avec des exemples différents. Sans tests paramétrés, ça revient à faire un test par cas ce qui peut alourdir notre fichier de tests.
On va voir comme...
Avant .Net 8, tester du code qui utilise DateTime.Now() n’était pas trivial, on devait faire en sorte de mocker la Clock dans nos tests. Depuis .Net 8, c’est beaucoup plus facile grâce à TimeProvider inclut par défaut !
En deux mots, TimeProvider est une...
La gestion des erreurs de son API est très importante pour que les consommateurs puissent avoir une description claire du problème mais c’est souvent fastidieux à maintenir.
On va voir comment avoir des statuts de réponse cohérent et des messages d’erre...
