Avec notre Guide de projet PROPRE, faîtes collaborer un comité d’édition et une équipe de développement pour la création de vos rapports automatisés en suivant la méthodologie PROPRE. Suivez nos propositions de pratique d’organisation, d’outils et de développement R, pour une pratique DevOps maîtrisée et en toute bienveillance.
Il est possible de collaborer autour de git dans une équipe composée de développeurs et de non développeurs. Dans ce guide “Organisation d’un projet collaboratif de publication PROPRE”, nous vous expliquons comment.
Qu’est-ce qu’un projet collaboratif PROPRE ?
Table des matières
Un projet collaboratif PROPRE est un projet qui suit le “PROcessus de Publications REproductibles” et qui est conduit par une équipe pluri-disciplinaire.
Suite à la réponse de la DREAL Pays de la Loire à un appel à projet du Commissariat Général au Développement Durable (CGDD) fin 2015 sur le thème de la connaissance stratégique des territoires, un centre de service de la donnée a été constitué en 2018.
Le “DREAL datalab” doit proposer des accès facilités aux données brutes, agrégées et analysées produites et les diffuser.
Afin de favoriser la réussite des projets, des méthodes modernes de développement et l’utilisation d’outils libres et open-source ont été testées.
La production de données et d’analyses de ces données requièrent aujourd’hui leur présentation dans un cadre reproductible pour au moins trois raisons : la confiance en l’information, sa fraîcheur et le gain de temps à en produire des nouvelles.
Ainsi s’est présentée la nécessité définir un PRocessus pour monter des projets collaboratifs de Publications REproductibles et donc diffusables. L’acronyme PROPRE est né.
La mise en place de ce processus ne pouvait se réaliser que dans une seule équipe.
Une équipe pluri-disciplinaire d’agents de différentes DREAL s’est constituée pour mettre le processus à l’épreuve des besoins et contraintes de chacun sur un projet collaboratif commun.
Les détails de la genèse et les concepts du processus se trouvent dans le livre numérique : C’est du PROPRE !
Que contient ce guide de développement autour de R ?
Ce livre s’adresse aux différentes personnes impliquées dans un processus de développement PROPRE. Nous distinguerons trois catégories de contenu :
- [01 – coordination] : Comment mettre en place un tel projet, quels sont les rôles à répartir, quels sont les moyens et les outils nécessaires, … ?
- [02 – édition] : Comment définir ses besoins, comment présenter le contenu des documents, comment collaborer avec l’équipe de développement, … ?
- [03 – développement] : Comment lancer techniquement le projet, quels outils utiliser, quelles méthode de développement avec R, quelles sont les bonnes pratiques, … ?
Étapes du projet dans l’ordre chronologique
Mise en place du projet
- [coord] – Définition des rôles de coordination des équipes et du calendrier : “Comment coordonner le projet ?”
- [coord] – Mettre en place les outils de communication : “Les outils de travail”
- [edition] – Discussion sur les besoins et un contenu générique : “Comment définir ses besoins et le contenu”
- [coord] – Définition du format et du stockage des données : “Quelles questions se poser sur la gestion des données ?”
- [dev] – Mettre en place le projet de développement en lien avec git, RStudio et GitLab : “Mettre en place un projet de développement avec RStudio et GitLab”
Le cycle de développement DevOps
Chaque demande du comité éditorial sera listée dans un ou plusieurs tickets.
Chaque développeur qui prend en charge un ticket fera valider ses développements par un responsable du développement, puis le résultat par le comité éditorial avant de pouvoir fermer ce ticket.
D’une manière générale, pour une production avec R, la validation concerne (1) l’apparence générale de la production (hors contenu pertinent), (2) le contenu (non mis en forme), et (3) le contenu intégré dans le moyen de production.
Dans le cadre d’une publication PROPRE, la validation concerne les outils d’aide à la création de contenu.
Le produit de développement est toujours un package R, documenté, testé et versionné.
Le produit final visé est une publication reproductible créée à partir de ce package.
Les étapes de mise en place doivent avoir permis de séparer la publication en différents chapitres, si possible indépendants.
La publication sera construite en plusieurs étapes, répétées pour chaque chapitre.
- UI first : Création et validation de l’apparence du futur produit (bookdown, sans contenu) et de la façon de le construire par les utilisateurs (Comment apparaît le menu de création de la publication).
- Rmd then :
- [dev] : Création des vignettes du package. Plutôt dédiées à la documentation du développement, elles présentent l’utilisation directe des fonctions créées. Les vignettes compilées seront présentées sur un site web pour validation du contenu et des traitements des données par le comité éditorial [Ed].
- [edition] : Création du contenu des textes de la publication. Les titres et paragraphes sont validés en comité éditorial. En théorie, il ne devrait pas y avoir de discussion sur la structure du chapitre à ce stade.
- Documentation utilisateurs. C’est une extension de la partie Rmd then qui doit expliquer aux utilisateurs du produit comment l’utiliser. Cela inclut
- Integration du contenu dans le produit. Lors de cette phase, il ne devrait plus y avoir de discussion ni sur l’apparence, ni sur le contenu, ni sur le fond. Les codes R sont figés. Il s’agit surtout de vérifier que tout se passe bien dans le produit final.
Les 1., 2. et 3. peuvent se faire indépendamment, en parallèle.
Le 4. se fait à la fin. Ce peut être la fin de la validation d’un chapitre en particulier. Mais pas d’un paragraphe.
Les guides nécessaires à la bonne réalisation des cycles de développements sont les suivants :
- [dev] – Créer les tickets du projet dans le Kanban et les utiliser comme la référence pour le développement : “Créer des tickets et gérer la communication et l’avancement avec un Kanban”
- [edition] – Voir l’avancée de la résolution des tickets et répondre aux interrogations des développeurs : Suivre le traitement de ses besoins
- [dev] – Développer en utilisant git, GitLab et RStudio comme outils de collaboration : “Collaboration sur un projet Git avec Gitlab et Rstudio”
- [dev] – Développer un package documenté et testé avec la méthode ‘Rmd first’. Cette méthode est valable pour les étapes de développement ci-dessus : « Développer un package documenté et testé avec la méthode ‘Rmd first’
- Vous pouvez des tutoriels complémentaires sur la méthode Rmd First: “Rmd First” : Quand le développement commence par la documentation et {fusen} : Créer un package à partir d’un simple fichier Rmarkdown
- [dev] – Garder en tête les “Pratiques, trucs et astuces de code avec R”
- [edition] Participer à la rédaction des textes à insérer dans le produit final : “Rédiger et fournir les textes en Rmarkdown”
Tests utilisateurs et livraisons
À l’issue d’un cycle, le contenu est figé, les développements de nouvelles fonctionnalités sont figés.
On entre dans une phase de validation.
Les équipes de développement et d’édition testent le bon fonctionnement des outils
- [dev] Tester et livrer : “Release : Validation – Livraison par les [ChfDev]”
- [edition] “Tester, reporter les bugs, valider”
- [edition] “Produire, diffuser et communiquer”
En savoir plus sur PROPRE
Diaporamas de présentation de la démarche PROPRE :
- Les détails de la genèse et les concepts du processus se trouvent dans le livre numérique : C’est du PROPRE !
- la présentation de la démarche (sept 2020)
- bilan du 1er cas d’école au 30 nov 2020
- presentation à la communauté spyrales
- Les publications {propre.rpls} publiées en 2020
