Workflow
Afin de s'assurer que tout le monde fonctionne de la même façon et ne soit pas perdu dans lors du développement du projet, cette page présente comment se déroule le développement d'une fonctionnalité jusqu'à sa mise en production.
La source de vérité de l'avancement du projet se trouve dans les issues GitHub. Si vous avez un seul endroit à visiter pour savoir ce qu'il y à faire et quel est l'état d'avancement c'est le tableau des issues. Ce tableau contient tous les issues qui ont été déterminées par l'équipe.
Une autre partie importante des issues est les labels qui y sont associés. Il existe plusieurs labels et certains on des usages particuliers. La plupart des labels décrivent la catégorie de l'issue (par exemple bug pour les bugs ou feature pour les fonctionalités) et les labels en majucules avec des accolades (ex: [IN PROGRESS]) décrivent l'état d'avancement de la tâche. Il est primordial d'associer les bons labels aux issues et de les mettre à jour lorsque l'état d'avancement de la tâche change. Voici la liste complète des labels disponibles:
Voici le workflow type pour développer une fonctionnalité de l'application.
Les user stories fournies dans l'énoncé sont souvent trop grosses pour simplement créer une seule issue. La première étape est donc de diviser la user story en plus petites portions. Pour ce faire, nous utilisons principalement Miro pour en discuter en équipe et pour aider à découper.
Pour découper une story, nous tentons de trouver les plus petits incréments possibles qui offrent une différence visible par le client.
Une fois le découpage fait, les issues doivent être ajoutées sur GitHub avec la bon milestone et les bons labels.
Lorsque quelqu'un est prêt à effectuer une issue, ce dernier peut s'assigner à l'issue et changer le label de [READY] à [IN PROGRESS] pour signifier qu'il travaille dessus. Comme nous utilisons le Trunk-Based development (voir section sur les conventions de git), une nouvelle branche doit être créée et une nouvelle Pull-Request associée à l'issue doit être créée le plus rapidement possible. La Pull-Request doit être marquée en Draft jusqu'à ce qu'elle soit prête à être merge.
Une fois que le code lié à l'issue est fait, qu'il est testé et formatté (nous recommandons bien évidemment le TDD) et que les critères d'accpetations de l'issue sont répondus, la Pull-Request peut être modifiée pour ne plus être en Draft et le label de l'issue associée doit être changé de [IN PROGRESS] à [IN REVIEW]. Le lien vers la Pull-Request doit aussi être partagé dans le channel #code-review dans notre Discord afin que tous soient au courant qu'elle est prête. Pour qu'une Pull-Request soit mergée, il doit y avoir au moins 2 autres personnes qui approuvent la Pull-Request. Une fois cette conditions remplie et que tout est prêt, la Pull-Request peut être merge dans la branche principale.
Dans le contexte du projet, la mise en production doit être fait de façon manuelle. Lorsque l'on veut faire une mise en production, il suffit de tagger le commit sur la branche main que l'on désire envoyer en production. Les tags devraient être nommés de la façon suivante: MEP—X.Y, où X est le numéro de la MEP et Y est le nombre du tag de la même MEP (Ex: MEP—1.2 pour le 2e tag de la MEP#1). Il faut ensuite aller sur Draveur pour effectuer la mise en production officielle.
