Qu’est-ce qu’un workflow basé sur les versions ?
Ici, nous expliquons de quelle manière vous pouvez créer un workflow basé sur les versions avec GitHub.
Qu’est-ce qu’un workflow basé sur les versions ?
Un workflow basé sur les versions est un ensemble de modèles et stratégies dont l’objectif est la mise en production d’un logiciel. Bien que cette notion semble être un objectif évident pour une équipe de développement, la valeur de cette perspective est plus nuance. Dans cette unité, nous expliquons comment il pilote trois parties différentes du cycle de publication : la gestion du projet, la sélection d’une stratégie de branchement et la publication aux clients.
Planification du travail à l’aide des tableaux de projet GitHub
Dans une perspective de planification, adopter une approche axée sur les versions signifie que les problèmes seront divisés en itérations distinctes qui produisent une nouvelle version. Ces itérations souvent appelées sprints s’inscrivent dans des périodes approximativement égales pour produire des changements incrémentiels. D’autres équipes préféreront inclure l’intégralité des versions publiées dans une seule itération qui peut durer quelques mois ou davantage. Dans GitHub, ces itérations sont gérées sous forme de projets.
La principale fonctionnalité d’un projet est son tableau. Le tableau est le plan central d’enregistrement de l’itération ; il contient toutes les cartes qui doivent être résolues. Une carte peut représenter un problème (issue), une demande de tirage (pull request) voire simplement une note générique.
Par défaut, chaque carte commence dans la colonne À faire, passe dans En cours après le début du travail et finit dans Terminé. Vous pouvez personnaliser ces colonnes, ajouter d’autres colonnes ou appliquer l’automatisation au déplacement de ces cartes et à leurs propriétés pour s’adapter au processus de votre équipe.
Découvrez-en plus sur la gestion des tableaux de projet.
L’état du projet de la carte est intégré dans tout le dépôt. Par exemple, faire glisser une carte de Actions à effectuer vers En cours modifie son état et met à jour l’indicateur visuel en regard du titre du projet. La section en vert indique la part des cartes marquées comme Terminé, tandis que la section en violet signale les cartes En cours. L’espace restant représente la part des cartes qui n’ont pas encore commencé. En plus de faire glisser des cartes autour de la carte, vous pouvez les mettre à jour à partir de leur vue principale.
Lorsque vous utilisez un tableau de projet, toutes les parties prenantes ont un moyen simple de comprendre l’état et la vitesse d’un projet. Vous pouvez également créer des tableaux dont l’étendue est limitée à certains utilisateurs ou à un ensemble de dépôts appartenant à une organisation.
Découvrez-en plus sur le suivi de la progression de votre travail avec les tableaux de projet.
Suivi de jalons spécifiques
Pour les équipes, ou éventuellement certains membres des équipes, GitHub offre une fonctionnalité de suivi des jalons.
Les jalons sont similaires au suivi des projets, car il y a un accent sur l’achèvement hiérarchisé des problèmes et des demandes de tirage. Toutefois, lorsqu’un projet peut être axé sur le processus de l’équipe, un jalon est axé sur le produit.
Découvrez-en plus sur le suivi de la progression de votre travail avec des jalons.
Choix d’une stratégie de création de branches
Les dépôts où plusieurs développeurs travaillent en parallèle doivent avoir une stratégie de création de branches bien définie. S’installer sur une approche unifiée tôt dans le projet permet de réduire la confusion et la frustration au fur et à mesure que l’équipe et l’échelle codebase.
Flux GitHub
En plus d’offrir une plateforme pour le développement collaboratif de logiciels, GitHub fournit également un workflow prescrit conçu pour optimiser l’utilisation de ses différentes fonctionnalités. Bien que GitHub puisse fonctionner avec pratiquement n’importe quel processus de développement logiciel, nous vous recommandons de prendre en compte le flux GitHub si votre équipe n’est pas encore installée sur un processus.
Utilisation de branches de longue durée
Une branche de longue durée est une branche Git qui n’est jamais supprimée. Certaines équipes préfèrent les éviter et opter plutôt pour des branches de fonctionnalité et de correctif de bogue de courte durée. Pour ces équipes, le but de tout travail est de produire une demande de tirage qui fusionne leur travail dans main. Cette approche peut être efficace pour les projets qui n’ont jamais besoin de revenir en arrière, comme les applications web internes qui ne prennent pas en charge une version précédente.
Toutefois, dans certains scénarios, une branche de longue durée répondra mieux aux besoins d’une équipe. Le cas le plus courant qui nécessite une branche de longue durée est quand un produit a plusieurs versions qui doivent être prises en charge pendant longtemps. Si une équipe doit planifier cet engagement, le dépôt doit suivre une convention standard, telle que release-v1.0, release-v2.0, etc. Ces branches doivent également être marquées comme protégées dans GitHub afin que l’accès en écriture soit contrôlé et qu’ils ne puissent pas être supprimés accidentellement.
Les équipes doivent toujours conserver la branche racine main et y fusionner les modifications de branche de version en amont tant qu’elles s’inscrivent dans le futur du projet. Au moment opportun, release-v3.0 doit se baser sur main afin que le travail de maintenance pour release-v2.0 ne complique pas le dépôt.
Maintenance des branches de longue durée
Supposons qu’une correction de bogue a été fusionnée dans la branche release-v2.0, puis refusionnée en amont dans main. Il a ensuite été découvert ultérieurement que ce bogue existait également dans la branche release-v1.0 et que le correctif devait être rétro-porté pour les clients qui utilisent toujours cette version. Quelle est la meilleure façon de renvoyer ce correctif ?
La main fusion de la branche en release-v1.0 n’est pas une option réalisable, car elle contiendrait un nombre significatif de validations qui n’étaient pas destinées à faire partie de cette version. Pour la même raison, le rebasage release-v1.0 sur la validation main actuelle ne serait pas une option.
Une autre option consisterait à réimplémenter manuellement la correction sur la branche release-v1.0, mais cette approche entraînerait un surplus de travail et ne serait pas adaptée dans les scénarios avec des versions multiples. Git offre une solution automatisée à ce problème sous la forme de sa commande cherry-pick.
Qu’est-ce que la commande cherry-pick de Git ?
git cherry-pick est une commande qui vous permet d’appliquer les commits de votre choix d’une branche à une autre. Elle itère simplement les commits sélectionnés et les applique à la branche cible en tant que nouveaux commits. Si nécessaire, les développeurs peuvent fusionner tous les conflits avant d’effectuer le backport.
Découvrez-en plus sur la commande cherry-pick de Git.
Mise à la disposition des consommateurs
Quand une version du produit est prête à être publiée, GitHub simplifie le processus de création de package et de notification des consommateurs.
Créer une version est aussi simple que remplir le formulaire :
- Entrez une étiquette Git à appliquer, qui doit suivre la gestion sémantique de version, par exemple
v1.0.2. GitHub gère le processus de création de l’étiquette Git que vous spécifiez. - Entrez un nom pour votre version. Voici quelques conseils pratiques :
- Utiliser un nom descriptif
- Utiliser la version Git
- Utiliser un résumé concis de la modification de la version depuis la version précédente
- Utiliser un nom de code ou une expression aléatoire
- Fournissez des notes de publication. Vous pouvez automatiser cela avec l’application Release Drafter qui analyse les changements apportés depuis la version précédente et inclut les titres des demandes de tirage associées.
- Si vous souhaitez fournir des fichiers dans le cadre de la version, comme les programmes d’installation prédéfinis, vous pouvez les faire glisser et les déposer sur le formulaire. Vous n’avez pas besoin de créer un package de la source, car GitHub le fait automatiquement.
- Indiquez si la version est préversion en cochant cette case. Cette indication permet aux clients d’éviter les versions préliminaires si elles le souhaitent.
Une fois qu’une version est publiée, tout le monde regardant le référentiel reçoit une notification.
Découvrez-en plus sur les versions GitHub.