# Test utilisation de Gitlab pour la SEC

## Proposition structuration des projets

### Quelques définitions

Gitlab repose sur la notion de groupes, pouvant contenir des sous-groupes et/ou des projets.
Les groupes et sous-groupes ont pour objectifs principaux de :
- structurer les projets ;
- pouvoir gérer des droits fins sur un ensemble de sous-groupes et/ou projets enfant ;
- avoir une vue d'ensemble sur un ensemble de projets (exemple : il est possible de visualiser dans un tableau les issues de tous les projets contenus dans un groupe/sous-groupe).

Un projet contient le code, documentation, wiki, tableaux...

### Organisation proposée

Rouge = groupe
Bleu = sous-groupe
Vert = projet

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

SDSE [label="SDSE" color=Red, shape=box]      
BCPS [label="BCPS" color=Blue, shape=box] 
BUSCADE [label="BUSCADE" color=Blue, shape=box] 
#SUIVIBUS [label="Suivi des travaux transverses" color=Green, shape=box]
DOCBUS [label="Documentation" color=Green, shape=box]
ENQ [label="Enquêtes" color=Blue, shape=box]
PROGENQ [label="Programmes" color=Blue, shape=box]
SUIVIENQ [label="Suivi des travaux" color=Green, shape=box]
PROJRENQ [label="projet R 1" color=Green, shape=box]
SCAD [label="Statistiques civiles et accès au droit" color=Blue, shape=box]
PROGSCAD [label="Programmes" color=Blue, shape=box]
SUIVISCAD [label="Suivi des travaux" color=Green, shape=box]
PROJRSCAD [label="projet R 1" color=Green, shape=box]
  
               SDSE ->{BCPS}
                BCPS->{BUSCADE}    
                BUSCADE->{SCAD ENQ DOCBUS}
                ENQ->{PROGENQ SUIVIENQ}
                PROGENQ->{PROJRENQ}
                SCAD->{PROGSCAD SUIVISCAD}
                PROGSCAD->{PROJRSCAD}
}

*Remarques : après la réorganisation, suppression du niveau "BCPS"*

:question: **Pour Violaine et Rachel** : quid du suivi travaux actuellement transverses (exemples : montée de version R, activités de pilotage, évolutions Golem) ? Gestion à part ? Sur quel périmètre ? Rattachement aux sections ?

:question: **Pour Violaine et Rachel** : centralisation des programmes R BUSCADE ?

## Suivi des travaux

### Proposition

:bulb: **Proposition** : s'appuyer sur les issues Gitlab pour le suivi de nos travaux.

:arrows_counterclockwise: **Remplace** : Hackmd de suivi des travaux, échanges par mail, outil personnel de suivi des travaux

:heartbeat: **Avantages principaux par rapport à l'existant** :
- gagner en lisibilité et visibilité sur l'avancement de nos travaux, leur priorisation, leur charge, aussi bien pour les responsables que pour les membres de l'équipe ;
- avoir un outil commun centralisé ;
- assurer la traçabilité des échanges par sujet ;
- diminuer la charge mentale induite pour la réception de multiples mails ;
- suppression des coûts et risques liés au report d'une semaine à l'autre.

#### Proposition structure du tableau de suivi

Création de trois statuts seulement pour le moment, reproduisant l'existant dans le hackmd :
- A faire
- En attente
- En cours
Une issue fermée = terminée
Colonne sans étiquette pour le stock (notre backlog)

**Vues existantes**

**Granularité des issues**

:question: On fait quoi ?

Une fois sorti du stock, pas de tâches de plus de 20 jours de charge et plus de deux mois de délai (en théorie ;)).

Bonnes pratiques - dans tout cas, il faut impérativement à mon sens que :
- une issue est un fil conducteur, et ne contienne pas des infos qui n'ont rien à voir avec la choucroute ;
- une issue doit avoir une liste de sous-tâches précise. Si toutes les sous-tâches checkées = c'est fini ;
- une issue doit avoir une date globale d'échéance.

Exemples concrets pour discussion :
- demandes maintenance enquête : une seule issue par groupe de dev ayant la même échéance :+1:
- recette DDR : une issue globale :+1

**Visibilité**

TO DO : voir pour passer en public SDSE (?)

**Ajout d'une tâche pense-bête**

Pour couvrir les cas de micro-tâches (moins de 30 minutes) isolées (rattachables à aucun ticket existant) et ne nécessitant pas une traçabilité fine, création d'un template pense-bête pour création d'un ticket pense-bête chaque semaine. Utilisation des fils de commentaires pour éventuel complément.
=> Décision : tout est a priori rattachable à des tâches. Donc, on part sans pense-bête et on verra.

TO DO : supprimer template + pense-bêtes existants

**Priorité**

L'ordre dans les colonnes fait foi.

TO DO : on crée un label "Urgent" : tâche pour laquelle une action est attendue impérativement sur un délai court (pression d'une partie prenante, livrable à fournir rapidement...). Exemples : MAD avec engagement fort. Le label permet d'identifier pour l'équipe et l'encadrement des tâches très prioritaires.

**Jalon**

Un "jalon" est équivalent à une itération dans Gitlab. Cela présuppose donc que nous sommes en capacité de nous engager sur un périmètre d'issues sur une période donnée. Pour mettre en place des jalons, il faut donc avec un découpage assez fin des issues et des DOD sans ambiguité.
Pour moi, nous ne sommes pas encore assez matures, mais c'est une cible à atteindre qui permettrait de donner plus de visibilité à toute l'équipe sur nos engagements de court-terme. Quand on sera prêt, on pourrait partir par exemple sur des jalons de 15 jours pour faciliter nos points avec Philippe.

**Gestion des étiquettes**

gestion des étiquettes groupe vs projet + bonnes pratiques de préfixe. Création des étiquettes de toutes les personnes au niveau SDSE.

:question: Etiquette de thème : quelle politique ? Mélange de genre entre du pérenne & ponctuel. Un thème : un début une fin et/ou un thème = une thématique pérenne.
=> Décision : on est plutôt sur des thèmes pérennes.
T:production courante & réutilisation T:Amélioration calcul DDR (idéee pdu prolongement d'un exitsnat)

**Reprise du stock**

Reprise depuis septembre des travaux "conséquents" et sur lesquels on pourrait être amenés à revenir dans les mois à venir (besoin de tracabilité + en lien avec des travaux actuels. Exemple : double, remplacement juridictions + besoin d'être sûr que dans les 4 derniers mois, on n'a pas pris des engagements importants qu'on n'a pas "oublié". Si plus de 4 mois, c'était l'été donc plus si important...) pour voir ce que ça pourrait donner.

Dans l'ordre de priorité :
- DONE : collecte
- DONE : transversal
- DONE : enquêtes

DONE : actions consécutives aux contrôles qualité dans le board

Reprise des archives en l'état dans le Wiki du projet de suivi des travaux : https://gitlab.codeo.intranet.justice.gouv.fr/sdse/bcps/buscade/statistiques-civiles-et-acces-au-droit/suivi-des-travaux/wikis/home

TO DO : ajouter dernier suivi d'activité une fois bascule complètement faite

**Alimentation du backlog**

A partir du PAT, alimentation d'un backlog moyen terme. A FAIRE : mi-février.

**Identification individuelle des travaux à réaliser**

:question: Gestion des affectations multiples ?
Pas possible d'assigner plus d'une personne (dans l'optique je pense qu'une tâche a forcément un responsable). Dans l'équipe LEI, on avait pris le partie d'avoir des étiquettes par personne. Création d'étiquette pour toute l'équipe.

:warning: éviter de mélanger la gestion par assignation + étiquette. TO DO : supprimer les assignations.

et pratique tag pour sujets urgents

**Template**

Quatre templates initiés :
- demande au BIS ;
- autre ;
- preparation campagne (seulement pour enquête) ;
- suivi campagne (seulement pour enquête).

Possible d'avoir d'autres templates ? Par exemple, pour les MAD ?

**Suivi de la charge**

Fonctionnalités spend/estimate : permet d'avoir un suivi en heures, jours, mois... du temps estimé et réellement passé.

:question: Prioritaire ? Pour moi, peut-être un peu prématuré. Décision : pas prioritaire. On verra plus tard pour le mettre en place, avec peut-être une première étape d'estimation par les responsables, puis par les personnes.

:question: **Gestion des tâches récurrentes annuelles**
- Gestion avec template ? dans nouvelle version Gitlab, fonctionnalité d'import plus prometteuse pour moi.
- Faire figurer (car pas le cas pour certaines au moins dans point hebdo je crois. Exemple : MAD Visio ou IT) ? Pour moi, oui si on veut que ce soit un outil complet de suivi de notre charge. Décision : on met tout dans Gitlab.

**Lien avec travaux avec le BIS ou SC**

*L'idée serait ici d'absorber l'usage de Mantis et de Resana pour les projets de refonte ou autre. Peut être vu dans un second temps pour moi en collaboration avec le BIS.*
> Expérimentation en cours sur MJD + à venir sur SIAJ

- :question: Un ou des boards à part ? Même board (ça risque d'être le bazar...)
- :question: A court terme = SIAJ on fait comment ? Partie de faire un board à part... Mais nécessite une certaine rigueur/harmonisation au niveau des étiquettes.

**Suivi pour préparation des comités et autres**

(A envisager dans un second temps si ça te va)

Programme R pour sortie HTML ou CSV ? Flux ouvert vers Gitlab depuis R Studio.

*Remarque : fonctionnalité d'export CSV by design dans version plus récente. Je compte faire un message à l'équipe Gitlab pour savoir leur rythme de montée de version.*

**Gestion des docs**

Plutôt sur espace de partage et mettre lien.

## Documentation

:bulb: **Proposition** :
- utiliser le Wiki Gitlab comme support de notre documentation collaborative interne
- peut-être plus tard, envisager un versioning de notre documentation
- peut-être plus tard, envisager d'utiliser le Wiki pour extérieur SDSE

:arrows_counterclockwise: **Remplace** : certains documents partagés (exemple : bonnes pratiques R), projets Resana (astuces R), certaines pages du Wiki.

:heartbeat: **Avantages principaux par rapport à l'existant** :
- dissocier notre Wiki interne du Wiki SDSE ;
- avoir un outil collaboratif structuré pour nos besoins internes ;
- avoir des fonctionnalités de recherche.

:skull_and_crossbones: **Limites principales par rapport à l'existant** :
- pas de mode multi-édition simultanées par rapport à Resana & hackmd

:question: Projet de documentation à part (vs par exemple dans suivi des travaux si que Wiki) ? Je suis pour car plus flexible. Décision : ok pour doc à part.

En cours : projet de doc. sur Gitlab au niveau SDSE

TO DO : regarder snippet

## CI/CD

GitLab CI/CD permet d’automatiser le lancement de tâches au sein de pipelines. *Exemples d'usage que pourrait avoir le BUSCADE : lancement programmé de programmes R, tests de nouveaux outils, création d'un site de documentation...*

Pour le moment, pas de Runner intégré sur le Gitlab codeo. Il est possible d'avoir des droits sur un Jenkins, mais qui de toute façon, n'aura sûrement pas les flux ouverts pour accéder à nos bases de données. A horizon mi-2023, il pourrait proposer une solution intégrée, mais sans garantie (projet Alpha).

Piste envisagée à moyen terme (priorité faible) :
- voir avec le BIS quelle possibilité offrirait leur Jenkins ;
- suivre l'avancement de l'intégration du Jenkins BIS dans Gitlab codeo.

## Questions Steven (05/12/22)
* Quand et comment sort-on les tâches _closed_ du kanban ? = pour le moment, pas d'archivage.
* J'ai fait deux trucs pas fifous mais j'ai fait quand même :) :) Passer d'anglais à français, et (surtout) (ça a changé ma vie) passer le premier jour de la semaine dans les calendriers de dimanche à lundi. Quechtionne associée : ces _tips_ type FAQ, on les stockou ? GitLab, Wiki, L, autre ? (et bien sur tu dois en avoir what1000 de plus de ton côté des tips) = intégration dans doc. commune Wiki
* Dans les échanges sous un ticket, faut-il mentionner systématiquement pour que la notif soit envoyée ?
* C’est pas mal du tout de mettre des @ dans les commentaires des issues, ça apparait dans les mentions, moi j’adore ça les mentions. Si c’est une best pratice que tu pousses, je serai hyper preneur (en tout cas pour moi), pour savoir instantanément quels sont les issues sur lesquels on attend qqch de moi
* Est-ce qu’on peut exporter en csv la liste des issues d’un projet ? Pas dans cette version de Gitlab mais dans les prochaines oui.