Environnement de développement

Un environnement de développement est un ensemble d'outils, de processus, et de règles appliqués à un projet. Ils définissent la manière dont un projet est, e.g. :

• structuré
• construit, et exécuté
• testé, et validé
• intégré, et déployé
• documenté
• etc.

Ainsi, avant toute étape de développement, il y a une étape pour convenir de l'environnement de développement du projet, puis le mettre en place. Cette étape correspond à l'initialisation du projet.

C'est à cette étape qu'une version minimale du projet est créée, de sorte à valider le bon fonctionnement de l'environnement de développement. Le dépôt Git est ainsi créé avec divers scripts et outils permettant d'exécuter, tester, déployer, documenter, etc. le projet. À ce moment, le code du projet ne fait rien de plus que d'écrire "Hello World" dans la console, une page Web, ou une fenêtre graphique, dans le seul but de vérifier que l'environnement de développement est bien opérationnel.

Ce n'est qu'une fois l'environnement de développement mis en place et validé, que la phase de développement pourra alors débuter.

La gestion des tâches est un exemple de processus à définir dans l'environnement de développement. Il va de l'expression du besoin ou de la demande, à sa résolution finale.

L'expression d'une demande peut se faire de manière plus ou moins formelle. Usuellement, elle va s'effectuer sous la forme d'un ticket (issue), afin d'en permettre le suivi. Il convient alors de définir les différents types de demandes ainsi que leur format, i.e. les informations nécessaires à leur résolution, e.g. :

• déclaration d'incidents/bugs.
• demande de support.
• demande de fonctionnalité.

Les informations demandées peuvent être, e.g. dans le cas d'une déclaration de bug, la version concernée du projet, les étapes pour reproduire le bug, le résultat obtenu, le résultat attendu, etc. Tout ce qui facilitera la compréhension ainsi que la résolution de la demande.

Une fois la demande créée, elle est usuellement "triée" (triage) en l'associant à diverses catégories, e.g :

• le type de la demande : e.g. Bug, Regression, Suggestion, Feature Request, etc. ;
• le domaine de la demande : eg. Domain: X
• le rejet de la demande : e.g. Won't Fix, Working as Intended, Not a Defect, Out of Scope, Duplicate ;
• l'acceptation de la demande : e.g. Help Wanted, Planning, Milestone: X ;
• L'impact, la priorité, l'effort : e.g. Impact: X, Priority: X, Effort: X.

Une fois la demande acceptée, il convient d'en planifier la résolution. C'est à dire le moment où cette demande sera traitée, en fonction de la disponibilité des différentes ressources, des autres demandes en cours, et de leurs priorités/importances/impacts/efforts relatifs.

La feuille de route (roadmap), défini les futures (sous-)étapes du projet appelées jalons (milestone). Ils peuvent être des :

• jalons de version : une future release du projet, ou une contrainte temporelle.
• jalons d'évolution : un ensemble cohérent de modifications du projet (e.g. bugfix, ajout de fonctionnalités, etc.).

Les différentes demandes sont ainsi affectées à différentes personnes et jalons, ce qui définira qui les traitera et quand. La progression du projet peut ainsi être visualisée par le taux des demandes traitées au sein des différents jalons. Il est aussi possible de pondérer les demandes par une difficulté, temps estimé de traitement, etc. afin d'obtenir des taux de progression plus pertinents.

Le processus de traitement d'une demande correspond usuellement à une succession d'étapes allant de la conception de la solution à sa validation finale, passant par son implémentation, vérification, intégration, déploiement, documentation, etc. Ces différentes étapes doivent être explicitées à la fois pour avoir un processus clair que les différents développeurs puissent suivre, mais aussi afin de pouvoir suivre l'évolution de chaque demande.

À cette fin, on utilise généralement le Kanban, un tableau composé de plusieurs colonnes correspondant aux différentes étapes de résolutions d'une demande, sur lesquelles ont déplace des posts-its correspondant chacun à une demande différente. Cela permet ainsi d'obtenir visuellement la progression des différentes demandes au sein du projet.

La mémoire humaine est peu fiable (e.g. altérations, oublis), et difficile à transmettre proprement (e.g. déformations, incomplétudes). Le départ d'un collaborateur peut alors provoquer des pertes d'informations, et l'arrivée d'un nouveau nécessite la mobilisation de ressources afin de le former.

Documenter fixe les informations par écrit, permettant de les formaliser, conserver, et les transmettre. La transmission en est aussi bien moins coûteuse, nécessitant simplement de l'écrire, au lieu d'avoir à la répéter à toute personne qui en aurait l'utilité.

On peut distinguer 4 types de documentations dans le cadre d'un projet :

• la documentation du dépôt : les informations essentielles, sous forme de fichiers Markdown, e.g. README.md, INSTALL.md, CONTRIBUTING.md, LICENCE.md, ROADMAP.md, CHANGELOGS.md.
• la documentation API : décrit les API, générés automatiquement e.g. avec Sphinx, Doxygen, etc.
• la documentation développeur : indique comment bien utiliser les API.
• la documentation utilisateur : renseigne sur la manière d'utiliser le projet.

💡 Les tickets/issues ainsi que les commits sont aussi une forme d'informations. Afin de faciliter le suivi, il est d'usage de référencer, dans un commit, les issues qu'il adresse.

⚠ Bien qu'il soit possible d'ajouter des balises HTML dans un fichier Markdown, cela s'accompagne de différentes limitations. Il est ainsi bien souvent préférable d'écrire la documentation directement directement en HTML.

La documentation API liste et décrit les possibilités de l'API (classes, méthodes, etc). La documentation développeur donne des recommendations, et indique la bonne manière de faire pour un objectif précis. Par exemple, une documentation développeur indiquera, sous la forme de pseudo-tutoriels, comment créer, configurer, et ajouter un élément. Une documentation API listera les méthodes des différentes interfaces (e.g. , , ). La documentation API se focalise donc sur le contenu des API, quand la documentation développeur s'intéresse à leur bonne utilisation.

⚠ Les commentaires au sein du code ne doivent pas être une répétition du code, ils doivent être utilisés soit pour indiquer une nuance importante, pour référencer un issue, ou pour générer la documentation API.

Les différentes opérations (e.g. déployer, exécuter) doivent être partageables et reproductibles. Les différents processus doivent respecter et forcer les conventions définies au sein de l'équipe.

Automatiser les différentes opérations et processus permet de résoudre ces problèmes. Par exemple un simple script peut permettre d'effectuer simplement une opération complexe, s'assurant aussi de l'homogénéité de l'opération au sein de l'équipe. Cette automatisation peut être de 4 natures :

• manuelle : s'exécute manuellement.
• réactive : s'exécute automatiquement suite à un événement.
• périodique : s'exécute à interval régulier.
• procédurale : l'outil nous guide à travers une liste d'étapes.

Les scripts permettent de définir une successions d'opérations dans un fichier. Ils peuvent être exécutés manuellement ou par un service donné.

Par exemple, un script peut lancer un programme Python en définissant afin de s'assurer que les dossiers ne polluent pas le dossier du dépôt.

La réactivité consiste à réagir à un événement en exécutant un script donné. Ces événements peuvent être de différentes natures et origines. Par exemple, des événements de modifications sur le système de fichier, des événements liés au dépôt Git/Github, etc.

Par exemple live server sur VSCode, ou permettent de lancer un site Web qui servira les fichiers du dossiers indiqué, et se mettra à jour à chaque modification de ces fichiers.

Beaucoup de commandes de développement intègre un watch mode, qui permet d'effectuer l'action donnée à chaque modifications, e.g. reconstruire le projet. Le hot reload consiste à mettre à jour un processus en cours d'exécution, sans l'arrêter.

Pour Git, il est par exemple possible d'exécuter des scripts au début ou à la fin de certaines opérations (hooks), par exemple pour formatter les fichiers de code, s'assurer que les tests passent avant d'accepter le commit, etc.

💡 Github a son propre système, cf CI/CD, e.g. déployer sur un environnement de test ou de production dès que la branche associée reçoit des nouveaux commits.

Issues: Templates / labels définis.

Souvent des logiciels/interfaces ad hoc.

Fork + PR

Somewhere droits d'accès ? e.g. commits signés ?

Règles conventions de code règles de nommage standards de documentation exigences de tests ✅ Processus workflow Git (issues, branches, PR) revue de code cycle de validation (CI, tests) publication / release ✅ Outils (mais comme moyens, pas comme finalité) IDE, extensions linters, formatters CI/CD scripts d’automatisation