L’organisation des développements s’appuie sur l’outil GitLab.
Comment est utilisé GitLab par l’équipe documentaire ?
Tout d’abord, notre instance GitLab a vocation à devenir l’unique serveur Git centralisé pour l’ensemble de nos développements. Les groupes permettent de refléter l’organisation interne de l’équipe en équipes et en projets et les développeurs conservent une visibilité importante sur l’ensemble des projets pour faciliter la collaboration.
Ensuite, nous voyons GitLab avant tout comme une plateforme de communication autour du code ; chaque objet dans GitLab (ticket, demande de fusion, page wiki…) est une occasion de discussion entre développeurs et chacune de ces conversations est enregistrée et devient de la documentation du projet. GitLab permet de soutenir chaque phase de développement :
- Les tickets sont le support de la fonctionnalité à développer. On y discute beaucoup cas d’utilisation, exemples ou cas aux limites, problématiques d’ergonomie, propositions de design et peu de problématiques techniques qui n’en seront que les conséquences (voir les demandes de fusion plus bas). Dans un objectif permanent de maximiser la valeur livrée à nos utilisateurs, les tickets purement techniques doivent être limités au maximum ; les évolutions techniques seront plutôt portées par des tickets fonctionnels qui nécessitent ces évolutions.
- Les jalons (milestones) servent à documenter chaque itération. La description peut présenter les objectifs de l’itération, mais aussi documenter ce qui a été fait pour préparer la réunion avec les utilisateurs. Le point d’entrée principal pour les utilisateurs est le tableau Kanban (board) du jalon en cours, avec des colonnes À faire, À définir, En cours, À valider et Terminé. Pour chaque gros projet en cours de développement, ce tableau est aussi le support de la réunion quotidienne de l’équipe.
- Les demandes de fusion (merge requests) sont le support des revues de code. On y discute choix d’implémentation, architecture logicielle, problématiques techniques. Les possibilités offertes par Gitlab pour exprimer les contraintes (ne pas fusionner cette requête avant que tel ticket soit fermé,…) et les enchaînements (fusionner cette requête entraîne la fermeture de tel ticket…) sont utilisées.
- La plateforme d’intégration continue compile le code à chaque fois qu’il est poussé sur un dépôt, lance et vérifie les tests automatisés, confronte le code avec la plateforme qualité sonarqube. En cas de besoin, le développeur responsable est contacté automatiquement par mail ou via notre rocket.chat interne.
GitLab est très flexible et permet à chaque équipe d’adapter le mode de travail à sa taille et à la complexité ou à la criticité du projet.
Perspectives
Notre instance GitLab est mise à jour dès que les nouvelles versions sortent et nous évaluons donc régulièrement les nouveautés pour faire bouger nos pratiques. C’est ainsi que nous testons en ce moment l’utilité des itérations ou des publications (releases).
Une fonctionnalité disponible depuis longtemps, coûteuse à implémenter, mais qui nous semble intéressante est la mise à disposition à la volée d’environnement de test par branches. Depuis notre migration sur des clusters Kubernetes, c’est une fonctionnalité qui semble désormais envisageable et que nous testerons. De là, on pourra peut-être envisager des livraisons en continu (au moins sur les environnemnts de qualification).
La documentation d’une DSI va plus loin que la simple documentation du code des applications. Par souci de cohérence, les pages wiki des projets applicatifs sont donc conservées sur notre wiki interne ce qui limite les synergies avec le reste de GitLab. À l’avenir on pourra étudier l’utilité de migrer toute la documentation sur GitLab ou peut-être une articulation entre certaines pages sur WikITN et certaines pages sur le GitLab.
Enfin, notre instance GitLab est pour l’instant limitée aux développeurs, principalement pour des raisons de coût de licence mais aussi d’IHM trop orientée vers les informaticiens. Avec les efforts pour embarquer de plus en plus les utilisateurs dans la construction de nos applications, ce modèle atteint ses limites : sur certains projets, nous avons parfois une liste de tickets maintenue par les utilisateurs sous Excel en parallèle de la liste sous GitLab. Nous étudions diverses pistes pour rationaliser ce fonctionnement, comme l’utilisation du Service Desk.
Illustration : CC BY-SA 4.0 - İsmail Arılık - “Own work” - Wikipedia
