Issues GitLab

Toutes les tâches sont suivies via des issues GitLab. Chaque issue porte un statut indiquant où elle se situe dans le flux de travail.

Flux des étapes

  1. Open — l’issue a été signalée ou demandée, mais elle n’est pas encore planifiée ni priorisée. N’importe qui peut créer une issue ; le responsable d’équipe en fait le tri.
  2. Awaiting specifications — les spécifications de conception, fonctionnelles et techniques doivent encore être rédigées avant que le travail puisse commencer. Ce statut est ignoré lorsque l’issue est déjà suffisamment claire.
  3. Awaiting development — l’issue est entièrement spécifiée (sur le plan produit et technique) et prête à être prise en charge.
  4. In development — l’issue est étudiée (recherches), développée et suit le processus de revue de code.
  5. On hold — le travail est bloqué, en attente d’une intervention externe (par exemple un client ou une autre équipe), ou l’issue a échoué à la validation et nécessite des travaux supplémentaires. Une fois que le développeur est prêt à s’en charger, l’issue retourne en In development.
  6. In validation — un artefact (build ou environnement de staging) est disponible et l’issue est en cours de test.
  7. Awaiting deployment — l’issue est validée ; une nouvelle version du logiciel doit être taggée et publiée pour les utilisateurs finaux.
  8. Done — l’issue est terminée et déployée.

Une issue peut aussi être fermée sans être terminée :

  • Won't do — l’issue est fermée sans être réalisée.
  • Duplicate — l’issue est fermée parce qu’une autre la couvre déjà.
graph TD
    S0[Open] --> S1[Awaiting specifications]
    S0 --> S2[Awaiting development]
    S1 -->|design, functional, tech| S2
    S2 --> S3[In development]
    S3 <--> S4[On hold]
    S3 --> S5[In validation]
    S5 -->|needs work| S4
    S5 --> S6[Awaiting deployment]
    S6 -->|release| S7[Done]