Workflow Devs

Workflow de développement des outils

Cette page a pour but de résumer la façon de travailler sur les outils développés par La Quadrature du Net, quels outils utilisés et autres. Ce travail est basé sur le workflow de gitlab et a pour but de fluidifier et faciliter les tâches des différentes contributrices aux projets LQDN, qu'il s’agisse de personnes travaillant sur les interfaces, sur le backend, l'intégration ou l'administration système.

Le but est de réduire le plus possible le temps entre la contribution d'une personne et la mise en ligne et en production de cette idée, afin de valoriser au mieux le temps consacré à La Quadrature.

Le principe est donc de faciliter la discussion et la coopération parmi toutes les parties, en réduisant les conflits.

Prérequis

Il faut avoir un compte sur le Git de la quadrature, et avoir demandé de faire partie de l'équipe en charge du projet (avec les droits de Developer), généralement l'équipe la-quadrature-du-net. Il faut aussi avoir mis une clef SSH sur son compte, pour pouvoir soumettre ses modifications au projet (pas absolument nécessaire, mais cela aide un minimum).

Il faut avoir lié son compte avec le Mattermost de La Quadrature, et avoir rejoint l'équipe du projet (généralement La Quadrature du Net).

Une présence sur les listes de diffusion dev@laquadrature.net^info et discussion@laquadrature.net^info est recommandée.

Lancement

Il s'agit dans cette partie de faire discuter ensemble les équipes opérationnelles de La Quadrature, les contributrices et toute personnes ou organisation extérieure voulant travailler sur un projet. Le but est ici de déterminer le périmètre du projet et les envies de chacune. Cette discussion a lieu sur mattermost, éventuellement dans un canal dédié à un projet, ou sur les listes de diffusions (discussion@laquadrature.net par exemple)

Si il s'agît d'un projet « neuf », il est recommandé de créer au plus tôt le projet dans le dépôt gitlab, avec l'aide éventuelle des administrateurs (secouez Okhin).

Le but de cette étape est de décider dans quelle direction aller et de fournir les spécifications.

Profitez-en pour demander aux admins un endroit pour déployer une version de développement du projet.

Spécifications

La première partie, généralement réalisée en lien avec l'équipe opérationnelle de La Quadrature du Net, consiste à écrire des spécifications. Une dizaine de lignes décrivant les choses à faire, comment doit se comporter le projet ou le type de données à manipuler et publier.

Ces spécifications peuvent ensuite être réparties dans différentes milestones (il faut une personne ayant le rôle de Manager pour le projet, secouez l'équipe opérationnelle pour avoir des Managers). Cela va permettre de découper le projet en plusieurs étapes.

La discussion a lieu sur mattermost, ou lors de réunions de travail. Ces milestones doivent permettre de répondre à la question « sur quoi est-ce que je travaille ».

Idées

Maintenant les personnes discutent sur comment arriver aux objectifs définis dans les milestones. Au fur et à mesure des discussions, il sera nécessaire de créer des tickets (issues), de les associer à une milestone et de lui ajouter des étiquettes permettant d'estimer qui peut travailler dessus.

La discussion a lieu sur mattermost. Si des points importants apparaissent, par exemple un prérequis ou une impossibilité technique, ou le résultat d'un choix interne, il est important de le noter en commentaire du ticket.

Le travail de conception d'interface est également à documenter, éventuellement en ajoutant des mockups dans les commentaires des issues.

Développement

Une fois les tickets créés, il est possible de commencer à travailler directement sur les problématiques soulevées. Ne pas hésitez à s'assigner les tickets pour signaler que quelqu'un travaille déjà sur un problème, cela permet d'éviter de travailler à deux sur un problème sans concertation et donc de perdre une partie du travail effectué.

Il est nécessaire de créer une branche par issue sur laquelle on travaille, afin de réduire les risques de conflits.

Documentation

Pensez à documenter votre travail, par des commentaires dans le code, éventuellement dans les commentaires des issues, ou dans le wiki du projet. Pas de documentations, pas de code.

Tests

Dans la mesure du possible, écrivez des tests et exécutez les. Demandez aux opérationnels si vous avez besoin de jouer avec le développement continu de Gitlab (c'est bien, et il y a de la documentation). Pour le moment, nous n'utilisons que des runners shell (pas encore de docker ou kubernetes), il faut donc que vos scripts de tests permettent d'installer l'ensemble des dépendances nécessaires depuis un shell.

Revue / Merge

Une fois le travail sur une issue terminé, il faut intégrer le travail fait. Demandez à merger, dans la branche preprod, afin que votre travail soit pris en compte et intégré pour tout le monde.

Il est possible ensuite pour chaque personne participant au projet de commenter le travail, de l'améliorer. Il faut ensuite valider la requête (demandez aux Managers du projets, si ça n'arrive pas assez vite).

Résolvez ensuite les conflits. Cette résolution est à la charge de la personne qui crée la merge request.

Préproduction

Une fois la merge request validée, le code sera automatiquement déployé (si l'intégration continue est correctement faites) sur la machine de dev de la quadrature du net (par exemple: le site de la Revue de Presse) si les tests réussissent.

Continuez de travailler sur les merges request et l'issue tant que le déploiement n'est pas réussi.

Release

Une fois une milestone complétée (donc que toutes les issues ont été réglées), il devient possible d'effectuer un gel du code, afin d'avoir un point dans le temps où le code est stable. Un git tag et une merge request vers la branche master permettront de réaliser cela.

Le code sera automatiquement mis en production, si nécessaire.

Packaging

Pensez à créer un paquet et une documentation d'installation du projet afin de faciliter l'installation par d'autres personnes. Sans aller jusqu'à un paquet debian, avoir un script de déploiement et un fichier de configuration par défaut est important.

Notez également dans un fichier Changelog les modifications faites pour cette release, en particulier si des valeurs du fichiers de configuration sont faites.

Party

Youpi tout fonctionne, ça se fête. Prenez du temps avec vos collègues développeuses et designeuses pour fêter ça.

Feedback

Comme rien n'est jamais parfait, discuter des problèmes rencontrés, les documenter. Et ensuite GOTO 1.