Gestion de versions pour la data science

Suivre les modifications que vous ou vos collaborateurs apportez aux données et aux logiciels est essentiel dans tout projet, qu’il s’agisse de recherche, de data science ou d’ingénierie logicielle. Pouvoir référencer ou récupérer une version précise de l’ensemble du projet facilite la reproductibilité, en amont d’une publication, pour répondre aux commentaires des relecteurs et pour fournir des informations complémentaires aux évaluateurs, aux éditeurs et aux lecteurs.

Les meilleurs outils pour tracer ces changements sont les systèmes de gestion de versions utilisés en développement logiciel, comme Git, Mercurial et Subversion. Ils enregistrent qui a modifié quoi et quand, et synchronisent les évolutions vers un serveur central afin que plusieurs contributeurs puissent gérer les changements sur le même ensemble de fichiers.

Si ces outils simplifient le suivi des modifications, leur prise en main peut être exigeante. Pour franchir ce cap, deux approches sont recommandées : une méthode manuelle et structurée pour gérer les changements, et l’usage complet d’un système de gestion de versions. Vous pouvez commencer par la première en visant progressivement la seconde, ou bien plonger directement dans la gestion de versions.

Bonnes pratiques pour la gestion de versions

Quelle que soit l’approche retenue, gardez en tête ces bonnes pratiques générales :

1. Sauvegardez (presque) tout ce qui est produit par un être humain, dès sa création. Cela inclut scripts et programmes de tout type, packages logiciels dont dépend votre projet, ainsi que la documentation. Quelques exceptions à cette règle sont évoquées plus bas.

2. Faites des changements de petite taille. Chaque modification doit rester suffisamment limitée pour conserver un suivi pertinent. Par exemple, un seul changement du type Révision du script qui ajoute ou modifie plusieurs centaines de lignes est probablement trop volumineux, car il empêchera d’isoler les impacts sur différentes parties de l’analyse. À l’inverse, ne segmentez pas non plus à l’excès. À titre indicatif, une bonne unité de changement correspond à un groupe d’éditions que vous pourriez vouloir annuler en une seule étape à l’avenir.

3. Partagez vos changements fréquemment. Toutes les personnes impliquées doivent partager et intégrer régulièrement les modifications des autres. Évitez que les dépôts locaux des contributeurs divergent, car l’effort de fusion croît plus vite que l’ampleur des différences. C’est particulièrement crucial avec la procédure manuelle décrite ci-dessous, qui n’apporte aucune aide pour fusionner des changements simultanés potentiellement conflictuels.

4. Créez, maintenez et utilisez une checklist pour l’enregistrement et le partage des changements du projet. Cette liste doit prévoir la rédaction de messages de log clairs, la taille et le contenu attendus des commits, des guides de style pour le code, la mise à jour des to-do, ainsi qu’une interdiction de valider du travail inachevé ou du code cassé.

5. Stockez chaque projet dans un dossier répliqué en dehors de la machine de travail du chercheur via un système comme Dropbox ou un dépôt distant tel que GitHub. Synchronisez ce dossier au moins une fois par jour. Cela prend quelques minutes, mais ce temps est aussitôt rentabilisé en cas de vol d’ordinateur ou de panne de disque.

Comment aborder la gestion manuelle des versions

La première approche, entièrement réalisée à la main, comprend deux volets supplémentaires.

D’abord, ajoutez un fichier nommé CHANGELOG.txt dans le sous-dossier docs du projet, et consignez-y, par ordre antéchronologique (le plus récent en premier), les modifications apportées au projet avec leur date. Ce fichier est l’équivalent d’un cahier de laboratoire et devrait contenir des entrées similaires à celles ci-dessous.

## 2016-04-08

* Switched to cubic interpolation as default.
* Moved question about family's TB history to end of questionnaire.

## 2016-04-06

* Added option for cubic interpolation.
* Removed question about staph exposure (can be inferred from blood test results).

Ensuite, copiez l’intégralité du projet dès qu’un changement significatif est effectué (c’est-à-dire susceptible d’affecter les résultats), et stockez cette copie dans un sous-dossier nommé avec la date, dans la zone synchronisée. Vous obtiendrez ainsi une organisation semblable à celle-ci :

.
|-- project_name
|   -- current
|       -- ...project content as described earlier...
|   -- 2016-03-01
|       -- ...content of 'current' on Mar 1, 2016
|   -- 2016-02-19
|       -- ...content of 'current' on Feb 19, 2016

Ici, le dossier project_name est synchronisé avec un stockage externe (par exemple Dropbox), current est l’emplacement de travail courant, et les autres dossiers à l’intérieur de project_name correspondent aux anciennes versions.

Avantages et limites de la gestion manuelle

On entend souvent « Les données coûtent peu, le temps coûte cher ». Copier l’ensemble du projet comme ci-dessus peut sembler gaspilleur, puisque beaucoup de fichiers ne changent pas, mais réfléchissez-y : un disque dur d’un téraoctet coûte environ 50 $, ce qui signifie que 50 Go reviennent à moins de 5 $. À condition d’exclure les gros fichiers de données de la zone sauvegardée (nous y reviendrons plus bas), cette méthode coûte moins cher que le temps nécessaire pour sélectionner manuellement les fichiers à copier.

Cette procédure manuelle satisfait les exigences évoquées plus haut sans nécessiter de nouveaux outils. En revanche, si plusieurs chercheurs travaillent sur le même projet, ils devront se coordonner pour qu’une seule personne modifie un fichier donné à la fois. Ils peuvent notamment créer un fichier de journal des modifications par contributeur, puis fusionner ces journaux à chaque création de copie de sauvegarde.

Systèmes de gestion de versions

Ce que la méthode manuelle exige avant tout, c’est de la discipline. Les outils au cœur de la seconde approche — celle que nous utilisons dans nos propres projets — ne se contentent pas d’accélérer le processus : ils automatisent certaines étapes tout en en imposant d’autres, ce qui réduit l’effort de discipline nécessaire et améliore la fiabilité des résultats.

Difficile de dire quel outil est aujourd’hui le plus utilisé en recherche, mais celui dont on parle le plus est sans doute Git. Cela tient en grande partie à GitHub, une plateforme d’hébergement populaire qui allie l’infrastructure technique de collaboration via Git à une interface web moderne. GitHub est gratuit pour les projets publics et open source et pour les utilisateurs du monde académique et des organisations à but non lucratif. GitLab est une alternative reconnue et appréciée, car la plateforme GitLab elle-même est libre et open source. Bitbucket propose un hébergement gratuit pour les dépôts Git et Mercurial, mais compte nettement moins d’utilisateurs dans la communauté scientifique.

Ce qu’il ne faut pas mettre sous gestion de versions

Tailles et formats de fichiers

Les bénéfices des systèmes de gestion de versions ne s’appliquent pas à tous les types de fichiers de la même manière. En particulier, l’intérêt varie selon la taille et le format des fichiers.

• Premièrement, la comparaison de fichiers y est optimisée pour le texte brut, comme le code source. En général, la visualisation des « diffs » fait partie des grands atouts de ces systèmes. Malheureusement, si les fichiers Microsoft Office (tels que les .docx utilisés par Word) ou d’autres fichiers binaires, par exemple les PDF, peuvent être stockés dans un système de versions, il est impossible d’y repérer précisément les changements entre deux versions. Les données tabulaires, comme les fichiers CSV, peuvent également être versionnées, mais une simple réorganisation des lignes ou des colonnes créera une différence majeure, même si les données n’ont pas changé.

• Deuxièmement, les données brutes ne devraient pas changer et n’ont donc pas besoin d’un suivi de versions. Conserver sous gestion de versions les fichiers intermédiaires et autres résultats n’est pas nécessaire si vous pouvez les régénérer à partir des données brutes et des logiciels. Toutefois, si données et résultats sont de petite taille, il est recommandé de les versionner pour en faciliter l’accès par les collaborateurs et la comparaison entre versions.

• Troisièmement, les systèmes de versions actuels ne sont pas conçus pour gérer des fichiers de plusieurs mégaoctets — a fortiori des gigas —, donc évitez d’y inclure de gros fichiers de données ou de résultats. (À titre de référence, la limite pour un fichier individuel sur GitHub est de 100 Mo.) Certains systèmes hybrides émergents comme Git LFS mettent les informations textuelles sous gestion de versions tout en stockant les gros fichiers sur un serveur distant, mais ils ne sont pas encore assez matures pour être recommandés.

Partage involontaire

Autre situation où les systèmes de versions ne jouent pas forcément en votre faveur : le « partage involontaire ». Les chercheurs manipulant des données soumises à des restrictions légales interdisant leur diffusion (par exemple, des données médicales) doivent veiller à ne pas les stocker dans des systèmes publics de gestion de versions. Certaines institutions fournissent des solutions privées : renseignez-vous auprès de votre service informatique.

De plus, veillez à ne pas déposer par inadvertance des éléments sensibles tels que des mots de passe ou des clés privées dans un système de versions où d’autres pourraient y accéder.

Si vous souhaitez vous lancer, découvrez notre introduction gratuite à Git for Data Science.

Remerciements

Ce billet est tiré de « Good enough practices in scientific computing » par Greg Wilson, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt et Tracy K. Teal, https://doi.org/10.1371/journal.pcbi.1005510.