diff --git a/chapters/contexte.typ b/chapters/contexte.typ index d90df19..e548385 100644 --- a/chapters/contexte.typ +++ b/chapters/contexte.typ @@ -1,3 +1,5 @@ +#import "../template.typ" : * + = Contexte Dans cette première section, je vais remettre en contexte le concept de formation, détailler mon parcours académique et présenter l'entreprise qui m'accueille en alternance. @@ -27,10 +29,10 @@ Une année à l'UHA 4.0 du parcours "Master Informatique et Mobilité" se divise Lors de ma première année du parcours de master, nous avons eu comme sujet de fil rouge, la gestion et l'automatisation de l'arrosage des plantes. Le but était de pouvoir récolter des données environnementales liées à une plante, puis les réutiliser pour prendre des décisions à l'aide de divers outils.\ Nous avons pu utiliser une sonde de température et un capteur d'humidité pour récolter les données, les envoyer grâce à un microcontrôleur vers un serveur pour stocker et traiter les données.\ Nous avons également pu utiliser des caméras pour nous permettre d'effectuer des constatations d'assèchement à partir des feuilles d'une plante qui réagit de manière assez marquée à ce facteur.\ -J'ai eu comme principales tâche de mettre en place un système IOT pour récolter les données environnementales et les images puis les envoyer vers un serveur distant. J'ai par ailleurs pu participer aux développements et à la recherche de solutions d'analyse des données collectées. +J'ai eu comme principales tâche de mettre en place un système #ref-glossary(term: "IoT")[IOT] pour récolter les données environnementales et les images puis les envoyer vers un serveur distant. J'ai par ailleurs pu participer aux développements et à la recherche de solutions d'analyse des données collectées. Cette année, pour la seconde année de mon parcours au sein du master, le sujet était de pouvoir prédire le confort moyen d'une salle de travail basé sur le ressenti des utilisateurs. Basé sur de la collecte de données et de l'analyse de ces dernières pour effectuer des prédictions, nous avions accès à une sonde de température, des microphones et des caméras pour analyser l'environnement. Comme à l'itération précédente du fil-rouge, un système de stockage et d'analyse des données nous a permis de réaliser des prédictions basées sur les données collectées. -En tant que Scrum Master, j'ai pu développer un système IOT de collecte de données et mettre en place un système de prédiction par analyse des données entrantes. +En tant que #ref-glossary(term: "Scrum-Master")[Scrum Master] , j'ai pu développer un système #ref-glossary(term: "IoT")[IOT] de collecte de données et mettre en place un système de prédiction par analyse des données entrantes. Mes deux années de master ont consécutivement été réalisées au sein de l'entreprise Unit Solutions. diff --git a/chapters/etat-de-l_art.typ b/chapters/etat-de-l_art.typ index 29af736..f1e6c12 100644 --- a/chapters/etat-de-l_art.typ +++ b/chapters/etat-de-l_art.typ @@ -5,7 +5,7 @@ == Présentation d'InfSuite -Début *2016*, les différents cantons suisses utilisaient le client lourd Kuba, l'application mère d'InfSuite. Ce logiciel était payé par l'#display-def("OFROU") pour une meilleure gestion des infrastructures routières en Suisse. +Début *2016*, les différents cantons suisses utilisaient le client lourd Kuba, l'application mère d'InfSuite. Ce logiciel était payé par l'#ref-glossary(term: "OFROU")[OFROU] pour une meilleure gestion des infrastructures routières en Suisse. En *2019*, elle lance un appel d'offres dans le but de réduire les coûts liés aux applications qu'elle utilise. L'application Kuba étant une application hautement complète et complexe, le budget n'était alors pas forcément adapté à tous les cas d'usages des différents cantons, certains ayant des besoins différents en termes de gestion. @@ -13,7 +13,7 @@ Unit Solutions a alors décidé de se lancer dans la conception d'une nouvelle s Les principaux objectifs de l'application étaient donc : - De n'implémenter que les fonctionnalités que les cantons seraient susceptibles d'utiliser. -- Vendre l'application à l'#display-def("OFROU") grâce à la refonte de l'application qui réduit les coûts de l'application. +- Vendre l'application à l'#ref-glossary(term: "OFROU")[OFROU] grâce à la refonte de l'application qui réduit les coûts de l'application. - Livrer une version utilisable au bout d'un an et demi maximum pour permettre aux cantons de tester l'application et de s'adapter au nouveau système. Finalement adoptée par la suite par la majorité des cantons suisses, l'application InfSuite est une application géographique basée sur des technologies web récentes. Le but de l'application est de permettre de faire l'état et le suivi d'ouvrages d'art dans le temps. Lorsqu'un organisme responsable de la préservation des ouvrages d'art vient faire des constatations à une certaine date d'un ouvrage, il enregistre toutes les informations et données relatives dans l'application. @@ -47,15 +47,15 @@ D'autres onglets permettent de retrouver des informations plus précises telles Chaque ouvrage appartient à un canton, mais il peut être prêté à d'autres cantons, comme dans le cas où un pont serait partagé entre deux cantons par exemple. Un autre exemple d'ouvrage partagé est lorsque la gestion est déléguée à une ville plutôt qu'au canton. À ce moment, dans l'application, l'ouvrage appartient au canton et est « prêté » à la ville qui en est chargée. Chaque donnée générée à partir de l'application est rattachée au client qui en est à l'origine, ce qui permet d'avoir un historique en cas de problème. Pour permettre de rendre l'application plus légère, l'application est basée sur une architecture trois tiers. -Le premier tiers de l'application correspond à la base de données. Cette base de données est une base PostgreSQL. C'est ici que toutes les données sont stockées ainsi que les relations entre chaque donnée existante. Je détaillerai les particularités techniques de cette base de données qui peuvent expliquer la pertinence de son utilisation dans ce contexte plus loin dans ce rapport. +Le premier tiers de l'application correspond à la base de données. Cette base de données est une base #ref-glossary(term: "PostgreSQL")[PostgreSQL]. C'est ici que toutes les données sont stockées ainsi que les relations entre chaque donnée existante. Je détaillerai les particularités techniques de cette base de données qui peuvent expliquer la pertinence de son utilisation dans ce contexte plus loin dans ce rapport. -Le second tiers de l'application correspond à l'API. Une API web est une interface de programmation qui permet à des applications informatiques de communiquer entre elles via Internet. Elle définit les règles et les formats de données pour faciliter l'échange d'informations entre les différentes applications. +Le second tiers de l'application correspond à l'API. Une #ref-glossary(term: "API")[API ]web est une interface de programmation qui permet à des applications informatiques de communiquer entre elles via Internet. Elle définit les règles et les formats de données pour faciliter l'échange d'informations entre les différentes applications. -Cette API est le serveur back-end qui permet de faire la relation entre le monde extérieur et les données brutes stockées en base de données. Le serveur est développé en C\# avec l'ORM Entity Framework. Cette interface permet notamment de mettre en forme les données pour qu'elles correspondent aux besoins du troisième et dernier tiers. +Cette #ref-glossary(term: "API")[API ]est le serveur #ref-glossary(term: "Back-End")[back-end] qui permet de faire la relation entre le monde extérieur et les données brutes stockées en base de données. Le serveur est développé en #ref-glossary(term: "C#")[C\#] avec l'#ref-glossary(term: "ORM")[ORM ]Entity Framework. Cette interface permet notamment de mettre en forme les données pour qu'elles correspondent aux besoins du troisième et dernier tiers. -Le dernier tiers correspond à la partie visible de l'application. Appelé frontend, il met à disposition de manière visuelle et simplifiée les données. Ce dernier tiers permet également à l'utilisateur de créer, modifier ou effacer des données. Il est développé en TypeScript avec le framework Angular pour permettre de créer une application dynamique et réactive. +Le dernier tiers correspond à la partie visible de l'application. Appelé #ref-glossary(term:"Front-End")[Front-End], il met à disposition de manière visuelle et simplifiée les données. Ce dernier tiers permet également à l'utilisateur de créer, modifier ou effacer des données. Il est développé en #ref-glossary(term: "TS")[TypeScript] avec le framework #ref-glossary(term: "Angular")[Angular] pour permettre de créer une application dynamique et réactive. -Le dernier service complémentaire est un serveur GIS. Ce serveur permet de fournir des informations cartographiques comme des adresses. Il permet aussi de délivrer les fonds de cartes. Ils peuvent être hébergés et entretenus par Unit Solutions, ou alors par d'autres entreprises comme le fond de carte Open Street Map appartenant à la fondation du même nom. Il n'est pas intégré dans le concept d'architecture trois tiers puisque, comme je l'ai indiqué, ce service est indépendant et n'est pas une dépendance du reste. +Le dernier service complémentaire est un serveur #ref-glossary(term: "GIS")[GIS]. Ce serveur permet de fournir des informations cartographiques comme des adresses. Il permet aussi de délivrer les fonds de cartes. Ils peuvent être hébergés et entretenus par Unit Solutions, ou alors par d'autres entreprises comme le fond de carte Open Street Map appartenant à la fondation du même nom. Il n'est pas intégré dans le concept d'architecture trois tiers puisque, comme je l'ai indiqué, ce service est indépendant et n'est pas une dépendance du reste. Le schéma @three-tier-archi-diagram ci-dessous représente les trois tiers de l'application communiquant ensemble. L'application propose à l'utilisateur de personnaliser toute l'application. Cela comprend par exemple quel fond de carte afficher, quelles données afficher, personnaliser l'affichage de ces données tel que le type d'affichage des épingles… Ces configurations sont propres à l'utilisateur et sont sauvegardées en base de données, en parallèle de toutes les autres données de l'application. @@ -65,21 +65,21 @@ Le schéma @three-tier-archi-diagram ci-dessous représente les trois tiers de l ) #pagebreak(weak: true) -== PostgreSQL, un système open source +== #ref-glossary(term: "PostgreSQL")[PostgreSQL], un système open source -Ce document est axé sur le travail réalisé sur une base de données. L'application utilisant une base de données PostgreSQL, je présente dans cette section ce qu'est PostgreSQL, les avantages de cette technologie, les inconvénients et enfin une conclusion à cette section orientée. +Ce document est axé sur le travail réalisé sur une base de données. L'application utilisant une base de données #ref-glossary(term: "PostgreSQL")[PostgreSQL], je présente dans cette section ce qu'est #ref-glossary(term: "PostgreSQL")[PostgreSQL], les avantages de cette technologie, les inconvénients et enfin une conclusion à cette section orientée. === Présentation de PostgreSQL -PostgreSQL est un système de gestion de base de données relationnelle (#ref-glossary(term: "SGBDR")[SGBDR]). Le projet est initié en 1986 par Michael Stonebraker et Andrew Yu à l'Université de Californie à Berkeley. +#ref-glossary(term: "PostgreSQL")[PostgreSQL]est un système de gestion de base de données relationnelle (SGBDR). Le projet est initié en 1986 par Michael Stonebraker et Andrew Yu à l'Université de Californie à Berkeley. -L'une des forces majeures de ce système est d'être Open Source, ce qui signifie qu'il est développé et maintenu par la communauté en plus des développements apportés par la société mère PostgreSQL. +L'une des forces majeures de ce système est d'être Open Source, ce qui signifie qu'il est développé et maintenu par la communauté en plus des développements apportés par la société mère #ref-glossary(term: "PostgreSQL")[PostgreSQL]. -PostgreSQL tient sa réputation de sa fiabilité, sa robustesse et sa richesse fonctionnelle que je détaillerai juste après. +#ref-glossary(term: "PostgreSQL")[PostgreSQL]tient sa réputation de sa fiabilité, sa robustesse et sa richesse fonctionnelle que je détaillerai juste après. === Les principes de base -Comme dit précédemment, PostgreSQL est un SGBDR. Il utilise le langage SQL#footnote("Structured Query Language") pour chercher ou manipuler les données stockées. Le système met à disposition une série de fonctions pour permettre ces interactions, à savoir : +Comme dit précédemment, #ref-glossary(term: "PostgreSQL")[PostgreSQL]est un SGBDR. Il utilise le langage SQL#footnote("Structured Query Language") pour chercher ou manipuler les données stockées. Le système met à disposition une série de fonctions pour permettre ces interactions, à savoir : - Les transactions : un ensemble d'une ou de plusieurs opérations regroupées en une seule opération atomique. - Les vues : table virtuelle qui sélectionne et affiche des données à partir d'une ou plusieurs tables réelles. - Les contraintes d'intégrité : règles qui garantissent la validité et la cohérence des données dans une base de données. @@ -87,53 +87,47 @@ Comme dit précédemment, PostgreSQL est un SGBDR. Il utilise le langage SQL#foo - Les triggers : procédure stockée qui est automatiquement exécutée en réponse à un événement spécifique sur une table. - Les fonctions utilisateurs : procédure stockée qui renvoie une valeur et peut être utilisée dans une requête SQL comme une fonction intégrée. -PostgreSQL a également l'avantage d'être multiplateforme. Il peut ainsi fonctionner sur des environnements variés avec des systèmes d'exploitation différents, comme Windows, Linux, Mac, etc. L'une des forces de ce système de gestion de base de données réside dans sa capacité à gérer des volumes importants de données allant jusqu'à plusieurs Téraoctets. Cette gestion passe par différents points clés, à savoir : +#ref-glossary(term: "PostgreSQL")[PostgreSQL]a également l'avantage d'être multiplateforme. Il peut ainsi fonctionner sur des environnements variés avec des systèmes d'exploitation différents, comme Windows, Linux, Mac, etc. L'une des forces de ce système de gestion de base de données réside dans sa capacité à gérer des volumes importants de données allant jusqu'à plusieurs Téraoctets. Cette gestion passe par différents points clés, à savoir : - L'indexation - Le partitionnement - La gestion du cache - Des notions de concurrence et d'isolation - - De la réplication et du #ref-glossary(term: "Sharding")[sharding]. + - De la réplication et du #ref-glossary(term: "Sharding")[Sharding]. === Les avantages de PostgreSQL -PostgreSQL est un SGBDR très populaire pour plusieurs raisons : +#ref-glossary(term: "PostgreSQL")[PostgreSQL]est un SGBDR très populaire pour plusieurs raisons : - Il est open source, ce qui signifie qu'il est gratuit et que son code source est disponible pour tous. Cela permet à la communauté de développeurs de contribuer à son amélioration et de créer des extensions pour ajouter des fonctionnalités supplémentaires. - Il est très fiable et robuste, ce qui en fait un choix idéal pour les applications critiques et les environnements de production. - Comme vu précédemment, il est très performant, grâce à son moteur de stockage et son optimiseur de requêtes. Il est capable de gérer de gros volumes de données et de supporter des charges de travail élevées. - Le système au complet est très flexible, grâce à son architecture modulaire et à son support des extensions. Il peut s'adapter à de nombreux types d'applications et de besoins, notamment pour des applications géographiques avec des besoins plus complets. - Par sa nature open source, il est compatible avec de nombreux langages de programmation, tels que Python, Java, C++, Ruby, PHP, etc. -Il est également important de noter que PostgreSQL tient sa popularité, au-delà de ses performances et fonctionnalités déjà complètes, grâce à sa capacité à gérer des types de données bien plus complexes. Il propose la gestion de modèles de données complexes tels que des données géographiques et des données attributaires, mais permet surtout de gérer les relations entre ces données. +Il est également important de noter que #ref-glossary(term: "PostgreSQL")[PostgreSQL]tient sa popularité, au-delà de ses performances et fonctionnalités déjà complètes, grâce à sa capacité à gérer des types de données bien plus complexes. Il propose la gestion de modèles de données complexes tels que des données géographiques et des données attributaires, mais permet surtout de gérer les relations entre ces données. Cette gestion de données complexe permet une ouverture sur d'autres systèmes, particulièrement QGIS, un système d'informations géographiques, et ainsi d'étendre les fonctionnalités proposées par ce système. En type de fichiers volumineux, on peut par exemple citer les fichiers MAJICS, RPG, référentiels vecteurs, etc. -=== Les inconvénients de PostgreSQL +=== Les inconvénients de #ref-glossary(term: "PostgreSQL")[PostgreSQL] -PostgreSQL présente également quelques inconvénients qu'il faut prendre en compte : +#ref-glossary(term: "PostgreSQL")[PostgreSQL]présente également quelques inconvénients qu'il faut prendre en compte : - Il peut être plus complexe à installer et à configurer que d'autres SGBDR, tels que MySQL ou SQLite. - Il peut nécessiter plus de ressources matérielles (mémoire, CPU, espace disque) que d'autres SGBDR pour fonctionner de manière optimale. - Il peut être moins performant que d'autres SGBDR pour certaines tâches spécifiques, telles que les requêtes de type OLAP (Online Analytical Processing). -"PostgreSQL 12 - Guide de l'administrateur" de Guillaume Lelarge et Stéphane Schildknecht, éditions Eyrolles, 2020. - -"PostgreSQL - Maîtrisez les fondamentaux du SGBD open source" de Régis Montoya, éditions ENI, 2019. - -"PostgreSQL - Le guide complet de l'administrateur et du développeur" de Joshua D. Drake et Peter Eisentraut, éditions Pearson, 2018. - === Conclusion -PostgreSQL est un SGBDR open source très populaire, grâce à sa fiabilité, sa robustesse, sa richesse fonctionnelle et sa flexibilité. Il est utilisé dans de nombreux domaines, tels que la finance, la santé, l'éducation, le gouvernement, etc. Il est également compatible avec de nombreux langages de programmation et de nombreux systèmes d'exploitation. Cependant, il peut être plus complexe à installer et à configurer que d'autres SGBDR et nécessiter plus de ressources matérielles. Malgré ces inconvénients, PostgreSQL reste un choix idéal pour de nombreuses applications critiques et environnements complexes. +#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un SGBDR peu s'avérer plus complexe et peu nécessiter plus de ressources matérielles. Malgré ces inconvénients, #ref-glossary(term: "PostgreSQL")[PostgreSQL]reste un choix idéal pour de nombreuses applications critiques et environnements complexes de par les différents avantages cités précédement, tel que sa rapidité, sa fiabilité et son aspect open-source. #pagebreak(weak: true) == Problématique -L'application InfSuite s'appuie sur de nombreuses technologies, développées en externe de l'entreprise, pour fonctionner. Je peux par exemple citer Angular, un framework front-end développé par Google, qui est régulièrement mis à jour avec des réparations de bugs, des ajouts de nouveautés... et qui est utilisé dans l'application. Ce framework est continuellement mis à jour sans préavis pour les utilisateurs, mais utilise un système de versionnement. Le versionnement permet d'éviter les changements trop fréquents et perturbateurs, tout en offrant la possibilité d'introduire des améliorations et des nouvelles fonctionnalités de manière contrôlée. Il aide également les développeurs à anticiper les changements majeurs et à maintenir leurs applications à jour avec les dernières versions d'Angular. +L'application InfSuite s'appuie sur de nombreuses technologies, développées en externe de l'entreprise, pour fonctionner. Je peux par exemple citer Angular, un framework #ref-glossary(term: "Front-End")[front-end] développé par Google, qui est régulièrement mis à jour avec des réparations de bugs, des ajouts de nouveautés... et qui est utilisé dans l'application. Ce framework est continuellement mis à jour sans préavis pour les utilisateurs, mais utilise un système de versionnement. Le versionnement permet d'éviter les changements trop fréquents et perturbateurs, tout en offrant la possibilité d'introduire des améliorations et des nouvelles fonctionnalités de manière contrôlée. Il aide également les développeurs à anticiper les changements majeurs et à maintenir leurs applications à jour avec les dernières versions d'Angular. Par exemple, dans le cas où Google déploierait des changements de code majeurs qui rendent le code ultérieur obsolète, le système de versionnement lui permet de rendre sa mise à jour accessible au grand public, sans pour autant forcer la main aux développeurs à effectuer une mise à jour qui pourrait mettre le fonctionnement de leur application en péril. La majorité des technologies utilisées par InfSuite suivent ce système de versionnement. Malheureusement, réaliser de nouveaux développements pour l'application tout en surveillant les mises à jour des composants externes, analyser leur impact, les intégrer à l'application dès que ces dernières sont disponibles, n'est clairement pas possible. La stratégie de mises à jour utilisée est donc d'effectuer occasionnellement ces mises à jour, soit lors de moments clés (de nouvelles fonctionnalités importantes, des mises à jour de sécurité, des gains de performances, etc.), soit spontanément pour maintenir l'environnement à jour. -Ce cas de figure est présent à toutes les couches de l'architecture logicielle d'InfSuite, front-end, back-end, bases de données. Depuis un certain temps, l'application InfSuite utilise la version 14 du SGBDR PostgreSQL. Sortie en septembre 2021, cette version est maintenant dépréciée en faveur de la dernière version stable de l'application 16. Cependant, la version 14 a été adoptée très tôt par InfSuite et est restée depuis la version utilisée dans l'environnement InfSuite. +Ce cas de figure est présent à toutes les couches de l'architecture logicielle d'InfSuite, #ref-glossary(term: "SGBDR")[SGBDR] #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Sortie en septembre 2021, cette version est maintenant dépréciée en faveur de la dernière version stable de l'application 16. Cependant, la version 14 a été adoptée très tôt par InfSuite et est restée depuis la version utilisée dans l'environnement InfSuite. Pour suivre la stratégie de mise à jour de l'application, le sujet d'une mise à jour de la base de données d'InfSuite, de la version 14 vers la version stable la plus récente, a été mis sur la table. Le chef de projet en charge d'InfSuite a alors demandé une expertise pour la réalisation de cette migration pour s'assurer de la viabilité, mais également d'envisager, si possible, de réaliser cette migration en utilisant les nouveautés disponibles pour cette migration. Je vais donc chercher à savoir quelles sont les étapes préliminaires pour s'assurer de la viabilité d'une telle migration, comment réaliser cette migration de manière optimale dans le contexte d'InfSuite et comment s'assurer de la qualité de la réalisation de cette dernière. @@ -147,10 +141,10 @@ Pour faire une migration de base de données, il existe de nombreuses solutions, === Les outils On peut dans un premier temps penser à effectuer cette migration grâce à des outils spécialisés qui se chargent de faire la migration automatiquement et de s'assurer de la pérennité entre les données de l'ancienne base et les données insérées dans la nouvelle. -En prenant pour exemple l'outil Oracle Data Dump fourni par l'entreprise Oracle, ce logiciel permet de sauvegarder et restaurer des données et des métadonnées pour les bases Oracle. -Il est rapide et fiable, on peut ainsi lui fournir un fichier #ref-glossary(term: "Dump")[dump] de la base source et l'outil va se charger, grâce à ce fichier, d'intégrer les données dans la base cible. +En prenant pour exemple l'outil Oracle Data #ref-glossary(term: "Dump")[Dump] fourni par l'entreprise Oracle, ce logiciel permet de sauvegarder et restaurer des données et des métadonnées pour les bases Oracle. +Il est rapide et fiable, on peut ainsi lui fournir un fichier #ref-glossary(term: "Dump")[Dump] de la base source et l'outil va se charger, grâce à ce fichier, d'intégrer les données dans la base cible. Microsoft propose sa solution alternative SSMA pour importer les types de bases Access, DB2, MySQL, Oracle, SAP ASE vers leurs différents SGBDR propriétaires (à savoir les suites SQL Server). -Sur le même principe, les outils MySQL Workbench, AWS Database Migration Service (DMS) et PgAdmin permettent de réaliser le même type de migration vers leurs systèmes propriétaires, à savoir respectivement MySQL, AWS et PostgreSQL. +Sur le même principe, les outils MySQL Workbench, AWS Database Migration Service (DMS) et PgAdmin permettent de réaliser le même type de migration vers leurs systèmes propriétaires, à savoir respectivement MySQL, AWS et #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Les principaux désavantages de ce genre de solutions sont : - L'import des données reste assez strict et ne permet pas de flexibilité. Si les données ne sont pas compatibles, il faut passer du temps à travailler le modèle de données pour essayer de pallier aux incompatibilités. @@ -181,4 +175,4 @@ La migration en temps réel n'est donc réellement intéressante que dans le cas Il existe de nombreux outils pour effectuer des migrations de données à partir de bases de données. Cependant, il faut prendre en compte différents critères, comme la complexité de la migration, le budget alloué, les systèmes source et cibles, mais aussi la stratégie à appliquer lors de cette étape. Par exemple, dans un cas, le temps alloué à la migration peut être ignoré si ce qui compte est d'effectuer la migration sans arrêter le service, dans un autre cas, le temps d'arrêt est moins important que la fiabilité de la migration. Il faut donc réfléchir en amont à la manière d'effectuer cette étape, mais surtout à la pertinence de cette tâche pour éviter des coûts supplémentaires qui pourraient se révéler inutiles. Toutes ces questions permettent de cibler le besoin et donc le type de migration souhaité pour, par la suite, transférer ses données entre deux systèmes. -Je peux maintenant m'intéresser à la place de ce #ref-glossary(term: "SGBDR")[SGBDR] au sein de l'application InfSuite. \ No newline at end of file +Je peux maintenant m'intéresser à la place de ce SGBDR au sein de l'application InfSuite. \ No newline at end of file diff --git a/chapters/final-opening.typ b/chapters/final-opening.typ index 3802493..62facec 100644 --- a/chapters/final-opening.typ +++ b/chapters/final-opening.typ @@ -5,7 +5,9 @@ Au cours des trois années d'alternance passées au sein de l'entreprise Unit So Ajouter ce genre de gestion de base de données dans l'application permet également de remettre en question la manière actuelle de faire les choses pour tenter d'améliorer le processus.\ Actuellement, pour gérer les schémas de base de données, nous utilisons le logiciel Power Designer. Il permet de gérer les définitions des modèles de données avec les relations, les définitions de clés primaires, etc. Il ne permet cependant que de générer des définitions, il ne permet pas d'effectuer les actions sur la base de données, il reste totalement hors connexion.\ -Une fois les modifications effectuées dans l'outil, il génère le nouveau schéma de base avec les définitions de tables, colonnes,... Pour créer les scripts qui vont mettre à jour la base de données avec ces nouvelles définitions, il faut aller chercher dans le fichier de schéma de base de données, modifié par Power Designer, les différentes modifications. On peut alors créer un nouveau fichier ``` .sql``` dans lequel on va y ajouter les instructions SQL permettant d'effectuer ces modifications. Une fois le script rédigé, on peut tester que tout fonctionne correctement sur une base de développement. Si tout fonctionne comme prévu, alors il faut le dupliquer dans les dossiers de configuration spécifiques à chaque environnement et pousser toutes ces modifications sur Azure Devops. +Une fois les modifications effectuées dans l'outil, il génère le nouveau schéma de base avec les définitions de tables, colonnes... Pour créer les scripts qui vont mettre à jour la base de données avec ces nouvelles définitions, il faut aller chercher dans le fichier de schéma de base de données, modifié par Power Designer, les différentes modifications. On peut alors créer un nouveau fichier ``` .sql``` dans lequel on va y ajouter les instructions SQL permettant d'effectuer ces modifications. Une fois le script rédigé, on peut tester que tout fonctionne correctement sur une base de développement. Si tout fonctionne comme prévu, alors il faut le dupliquer dans les dossiers de configuration spécifiques à chaque environnement et pousser toutes ces modifications sur Azure Devops. -Toute cette gestion complexifie la simple de tâche de mettre à jour les informations en base de données. Il serait plus convenant de trouver une alternative moins complexe pour effectuer cette tâche. Après avoir mis à jour la base de données, on peut alors légitimement se poser la question :Comment simplifier l'administration d'une base de données.\ -On pourrait alors partir par exemple sur une implémentation dans l'outil d'administration du projet pour effectuer cette tâche longue et récurrente. \ No newline at end of file +Toute cette gestion complexifie la simple de tâche de mettre à jour les informations en base de données. Il serait plus convenant de trouver une alternative moins complexe pour effectuer cette tâche. Après avoir mis à jour la base de données, on peut alors légitimement se poser la question : Comment simplifier l'administration d'une base de données. + +On pourrait alors partir par exemple sur une implémentation dans l'outil d'administration du projet pour effectuer cette tâche longue et récurrente, ce qui élminierait une grande partie de ressource temps liée à la main d'oeuvre pour réaliser ce genre d'actions.\ +Etudier la faisabilité et l'importance d'une telle tâche est de la même importance qu'étudier une migration de base de données. Il faut s'assurer que le temps de recherche et de développement confèrent plus d'avantage et libère plus de temps que ce qui est requis pour mettre en place la solution. \ No newline at end of file diff --git a/chapters/réalisation.typ b/chapters/réalisation.typ index ac0eeeb..3d2fe87 100644 --- a/chapters/réalisation.typ +++ b/chapters/réalisation.typ @@ -9,11 +9,11 @@ Je présente dans cette section le travail réalisé durant les neuf mois au sei == Pertinence et cohérence -Lorsque le sujet de mettre à jour le SGBDR a été présenté, il n'a pas été décidé de remplacer PostgreSQL. Comme expliqué précédemment, PostgreSQL excelle dans la gestion de données géographiques et attributaires, il est complet et surtout très bien maintenu par ses développeurs. Ces différentes raisons en font un candidat parfait pour l'environnement InfSuite plus que tout autre système proposé par la concurrence. +Lorsque le sujet de mettre à jour le SGBDR a été présenté, il n'a pas été décidé de remplacer PostgreSQL. Comme expliqué précédemment, #ref-glossary(term: "PostgreSQL")[PostgreSQL]excelle dans la gestion de données géographiques et attributaires, il est complet et surtout très bien maintenu par ses développeurs. Ces différentes raisons en font un candidat parfait pour l'environnement InfSuite plus que tout autre système proposé par la concurrence. -Maintenir PostgreSQL en tant que SGBDR de l'application écarte déjà un bon nombre de solutions au niveau logiciel. Je peux d'ores et déjà écarter les logiciels payants et longs à maîtriser autres que PgAdmin pour effectuer cette migration, qui reste le logiciel le plus adéquat puisque nous ne cherchons pas à changer d'environnement. +Maintenir #ref-glossary(term: "PostgreSQL")[PostgreSQL]en tant que SGBDR de l'application écarte déjà un bon nombre de solutions au niveau logiciel. Je peux d'ores et déjà écarter les logiciels payants et longs à maîtriser autres que PgAdmin pour effectuer cette migration, qui reste le logiciel le plus adéquat puisque nous ne cherchons pas à changer d'environnement. -L'application InfSuite souhaite utiliser une fonctionnalité importante de PostgreSQL : les timestamps, ou horodatages en français. +L'application InfSuite souhaite utiliser une fonctionnalité importante de #ref-glossary(term: "PostgreSQL")[PostgreSQL]: les timestamps, ou horodatages en français. En effet, InfSuite utilise un système de version basé sur de l'horodatage. Quand un utilisateur met à jour les informations d'un document dans l'application (inspection, restauration, etc.), il crée une nouvelle version du document. @@ -30,13 +30,13 @@ Dans le schéma @file-versionning-schema, deux utilisateurs génèrent des versi caption: [Schéma d'un conflit de version entre deux version d'un document] ) -De plus, un point important pour lequel le souhait de mettre à jour la base de données a été exprimé est de pouvoir profiter des améliorations du #ref-glossary(term: "SGBDR")[SGBDR] PostgreSQL. Il y a par exemple des mises à jour de sécurité du système. Mettre à jour une application et ses différents composants permet de profiter des mises à jour de sécurité afin d'éviter des vulnérabilités qui pourraient mettre en péril les données des clients et l'intégrité de l'entreprise. +De plus, un point important pour lequel le souhait de mettre à jour la base de données a été exprimé est de pouvoir profiter des améliorations du SGBDR PostgreSQL. Il y a par exemple des mises à jour de sécurité du système. Mettre à jour une application et ses différents composants permet de profiter des mises à jour de sécurité afin d'éviter des vulnérabilités qui pourraient mettre en péril les données des clients et l'intégrité de l'entreprise. -Les vulnérabilités sont connues sous le nom de Common Vulnerabilities and Exposures et, en prenant pour exemple la mise à jour pour corriger la faille CVE-2023-5869, PostgreSQL résout un problème permettant d'écrire des octets arbitraires en mémoire, qui facilitait l'exécution de code arbitraire. Normalement, les ORM permettent de faire automatiquement de la paramétrisation de requêtes pour prévenir d'injections potentielles. Mais il se peut que des failles supplémentaires se cachent dans le code et permettent donc, malgré tout, d'exploiter ces failles. Les corriger sur le système permet alors d'éliminer en grande partie le risque d'attaque. +Les vulnérabilités sont connues sous le nom de Common Vulnerabilities and Exposures et, en prenant pour exemple la mise à jour pour corriger la faille CVE-2023-5869, #ref-glossary(term: "PostgreSQL")[PostgreSQL]résout un problème permettant d'écrire des octets arbitraires en mémoire, qui facilitait l'exécution de code arbitraire. Normalement, les #ref-glossary(term: "ORM")[ORM ]permettent de faire automatiquement de la paramétrisation de requêtes pour prévenir d'injections potentielles. Mais il se peut que des failles supplémentaires se cachent dans le code et permettent donc, malgré tout, d'exploiter ces failles. Les corriger sur le système permet alors d'éliminer en grande partie le risque d'attaque. -En complément des vulnérabilités, les mises à jour apportent des améliorations de performances cruciales. En théorie, les ORM jouent un rôle essentiel dans les performances d'une application, car ils utilisent un cache pour éviter d'effectuer des requêtes vers la base de données à trop haute fréquence. +En complément des vulnérabilités, les mises à jour apportent des améliorations de performances cruciales. En théorie, les #ref-glossary(term: "ORM")[ORM ]jouent un rôle essentiel dans les performances d'une application, car ils utilisent un cache pour éviter d'effectuer des requêtes vers la base de données à trop haute fréquence. -Dans le cas de la base PostgreSQL, elle est aussi utilisée pour le système d'information GIS, il y a donc beaucoup de données à délivrer et avec un grand nombre de requêtes. Améliorer les performances permet de réduire la latence ressentie par l'utilisateur lorsqu'il cherche à charger des données dans l'application. Sur la version 16 de PostgreSQL, il est promis une amélioration de 10 % des performances du #ref-glossary(term: "SGBDR")[SGBDR]. Un tel gain de performance permet d'améliorer grandement l'expérience utilisateur. +Dans le cas de la base #ref-glossary(term: "PostgreSQL")[PostgreSQL], elle est aussi utilisée pour le système d'information GIS, il y a donc beaucoup de données à délivrer et avec un grand nombre de requêtes. Améliorer les performances permet de réduire la latence ressentie par l'utilisateur lorsqu'il cherche à charger des données dans l'application. Sur la version 16 de #ref-glossary(term: "PostgreSQL")[PostgreSQL], il est promis une amélioration de 10 % des performances du SGBDR. Un tel gain de performance permet d'améliorer grandement l'expérience utilisateur. Il faut maintenant déterminer quel est le type de migration le plus adéquat dans ce cas de figure pour éviter les coûts supplémentaires qui peuvent être facilement évités. @@ -46,36 +46,36 @@ Je dois dans un premier temps chercher les technologies utilisées dans l'applic En regardant côté architecture, je cherche quelles sont les applications qui risquent de rencontrer un problème lors de la migration. Les seuls systèmes qui établissent une relation directe avec la base de données sont côté #ref-glossary(term: "Back-End")[back-end]. On limite donc l'impact sur l'application globale s'il y a des changements et des mises à jour à réaliser pour permettre à l'application de continuer à fonctionner avec la base de données. -Le projet #ref-glossary(term: "Back-End")[back-end] de l'application est développé en C\# avec .NET qui gère la partie web de l'application. Un certain nombre de librairies sont utilisées par le projet InfSuite pour permettre d'étendre les fonctionnalités de l'application sans devoir dépenser de temps de développement. +Le projet #ref-glossary(term: "Back-End")[back-end] de l'application est développé en #ref-glossary(term: "C#")[C\#] avec .NET qui gère la partie web de l'application. Un certain nombre de librairies sont utilisées par le projet InfSuite pour permettre d'étendre les fonctionnalités de l'application sans devoir dépenser de temps de développement. -Il existe des paquets alimentés par Microsoft, par exemple comme .NET, #ref-glossary(term: "EF")[#display-def("EF")], ... et d'autres librairies qui sont elles développées par des développeurs tiers qui ont souhaité ajouter une nouvelle fonctionnalité à l'écosystème. +Il existe des paquets alimentés par Microsoft, par exemple comme .NET, #ref-glossary(term: "EF")[EntityFramework], ... et d'autres librairies qui sont elles développées par des développeurs tiers qui ont souhaité ajouter une nouvelle fonctionnalité à l'écosystème. -Quand on souhaite effectuer une mise à jour de l'application, l'environnement Microsoft nous propose d'effectuer la mise à jour de ces librairies nommées NuGet Packages dans l'écosystème C\# via NuGet, le gestionnaire de dépôts associé. +Quand on souhaite effectuer une mise à jour de l'application, l'environnement Microsoft nous propose d'effectuer la mise à jour de ces librairies nommées NuGet Packages dans l'écosystème #ref-glossary(term: "C#")[C\#] via NuGet, le gestionnaire de dépôts associé. -Il permet de faire du versionnement des librairies, sur le même principe que PostgreSQL qui utilise le concept de versionnement pour livrer ses mises à jour. +Il permet de faire du versionnement des librairies, sur le même principe que #ref-glossary(term: "PostgreSQL")[PostgreSQL]qui utilise le concept de versionnement pour livrer ses mises à jour. Chaque version d'une librairie peut notifier des incompatibilités avec certaines versions d'autres librairies. Je dois donc étudier les composants qui permettent de faire la liaison à la base de données et également les librairies dont peut ou qui peuvent dépendre de ces composants. Il faut prêter attention à chaque composant mis à jour indépendamment qui pourrait causer d'autres problèmes de compatibilité avec l'application et casser des fonctionnalités. -Un projet C\# dans l'environnement Microsoft est composé d'une solution, de sous-solutions et de projets. +Un projet #ref-glossary(term: "C#")[C\#] dans l'environnement Microsoft est composé d'une solution, de sous-solutions et de projets. Les sous-solutions d'un projet sont des solutions indépendantes intégrées au projet. Un peu à la manière de librairies, je peux créer du code qui pourra être réutilisé dans différents projets indépendamment, sans devoir le dupliquer. Chaque projet possède ses propres NuGet packages, mais la solution peut gérer des dépendances, c'est-à-dire que le package sera ajouté à la liste des dépendances globales et sera installé dans tous les projets de la solution. -Dans mon cas, la solution #ref-glossary(term: "Back-End")[back-end] d'InfSuite est composée de 65 projets. Il y a le projet "WebApi" qui gère les routes et les interactions avec l'application #ref-glossary(term: "Front-End")[front-end] qui est disponible pour le client et qui dépend du projet "Server". Le projet "Server", lui, contient la logique de certaines interactions simples, par exemple la recherche d'IO via la barre de recherche dans l'application. Le projet "Server" dépend du projet "Core" qui gère certaines fonctionnalités plus poussées de l'application autant pour la partie web que pour d'autres composants. Il existe de nombreuses autres dépendances dans l'application qui complexifient la gestion des packages. Par exemple, dans le diagramme @ik-webapi-dependencies, on remarque rapidement que les dépendances internes au projet peuvent être relativement complexes. +Dans mon cas, la solution #ref-glossary(term: "Front-End")[front-end] qui est disponible pour le client et qui dépend du projet "Server". Le projet "Server", lui, contient la logique de certaines interactions simples, par exemple la recherche d'IO via la barre de recherche dans l'application. Le projet "Server" dépend du projet "Core" qui gère certaines fonctionnalités plus poussées de l'application autant pour la partie web que pour d'autres composants. Il existe de nombreuses autres dépendances dans l'application qui complexifient la gestion des packages. Par exemple, dans le diagramme @ik-webapi-dependencies, on remarque rapidement que les dépendances internes au projet peuvent être relativement complexes. #figure( image("../assets/images/ik-webapi-dependencies.png"), - caption: [Arbre de dépendances du projet WebApi d'InfSuite] + caption: [Arbre de dépendances du projet Web#ref-glossary(term: "API")[Api ]d'InfSuite] ) Si je souhaite par exemple mettre à jour un package dans le projet "Geometry", tous les projets dépendants sont impactés par cette mise à jour, il faut donc s'assurer que rien ne vient casser le bon fonctionnement de l'application en profondeur. Je m'intéresse donc aux liens entre les différents projets ainsi qu'aux librairies que je souhaite mettre à jour pour m'assurer de leur compatibilité pour toute l'application. === Compatibilité et décision -La première étape est de valider la compatibilité entre la version 14 et 16 de PostgreSQL. Une première manière de valider cela est d'aller sur les notes de mise à jour sur le site officiel et de chercher les changements qui peuvent affecter la compatibilité entre les deux bases. +La première étape est de valider la compatibilité entre la version 14 et 16 de #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Une première manière de valider cela est d'aller sur les notes de mise à jour sur le site officiel et de chercher les changements qui peuvent affecter la compatibilité entre les deux bases. Après avoir analysé en détail les changements, il y a trois grandes catégories. Il y a l'impact sur l'administration système, celui sur les requêtes SQL et celui sur l'incompatibilité des données. La partie administration système n'est pas gérée par les développeurs d'InfSuite, elle est gérée par d'autres employés de l'entreprise, je peux donc me concentrer sur la partie requêtes et données. @@ -100,15 +100,15 @@ Pour l'import de données, cette tâche a été réalisée par un administrateur Pour mettre à jour le modèle de données de manière synchrone avec les mises à jour de l'application et éviter des soucis de compatibilités, l'environnement InfSuite utilise un système de fichiers scripts. Rédigés en SQL, ces scripts viennent mettre à jour le schéma de base de données et sont exécutés automatiquement par le serveur lors de la mise à jour de l'environnement ciblé (dev, staging, production, etc.). -Pour l'exemple des horodatages, je rédige un script SQL que je pourrais exécuter manuellement sur l'environnement de développement avec la nouvelle version de PostgreSQL et effectuer mes tests. Cependant, si je veux intégrer mes modifications sur les autres environnements, il faut que je sauvegarde mes changements sur Azure DevOps, je n'ai pas la permission de faire ces changements manuellement. +Pour l'exemple des horodatages, je rédige un script SQL que je pourrais exécuter manuellement sur l'environnement de développement avec la nouvelle version de #ref-glossary(term: "PostgreSQL")[PostgreSQL]et effectuer mes tests. Cependant, si je veux intégrer mes modifications sur les autres environnements, il faut que je sauvegarde mes changements sur Azure DevOps, je n'ai pas la permission de faire ces changements manuellement. Enfin, pour mettre à jour les données dans la base une fois le schéma de base modifié, je décide de faire cette migration en temps réel. La compatibilité entre les types de données timestamp et timestamptz permet de garder en base l'ancien format de version, de mettre à jour le schéma de base puis de mettre à jour les données en y rajoutant le fuseau horaire. Comme la colonne "version" est utilisée à de nombreux endroits, créer un type de donnée côté serveur qui va s'occuper de les traiter rend la tâche moins complexe et chronophage. Avant de passer à la réalisation, je dois m'assurer de la compatibilité des dépendances externes pour effectuer la migration. -Ce qui m'intéresse particulièrement ici, est de mettre à jour le package Npgsql car il permet de communiquer avec la base de données. Dans une application .NET, il y a la possibilité d'utiliser un #ref-glossary(term: "ORM")[#display-def("ORM")] pour simplifier les interactions avec les bases de données. Le projet InfSuite utilise historiquement l'#ref-glossary(term: "ORM")[ORM] #ref-glossary(term: "EF")[EntityFramework]. Il faut bien différencier #ref-glossary(term: "EF")[EntityFramework] qui n'est plus activement développé, de son successeur EntityFrameworkCore qui offre de nouvelles fonctionnalités qui ne seront plus implémentées dans #ref-glossary(term: "EF")[EntityFramework]. +Ce qui m'intéresse particulièrement ici, est de mettre à jour le package Npgsql car il permet de communiquer avec la base de données. Dans une application .NET, il y a la possibilité d'utiliser un #ref-glossary(term: "ORM")[ORM ]pour simplifier les interactions avec les bases de données. Le projet InfSuite utilise historiquement l'#ref-glossary(term: "ORM")[ORM ]#ref-glossary(term: "EF")[EntityFramework]. -#ref-glossary(term: "EF")[EntityFramework] utilise le connecteur Npgsql pour effectuer les requêtes vers la base de données. En recherchant les versions disponibles de Npgsql pour EntityFramework, je me suis rendu compte qu'il fallait prêter attention à une fonctionnalité importante de PostgreSQL que le projet InfSuite veut maintenant exploiter : les horodatages avec des fuseaux horaires. +#ref-glossary(term: "EF")[EntityFramework], je me suis rendu compte qu'il fallait prêter attention à une fonctionnalité importante de #ref-glossary(term: "PostgreSQL")[PostgreSQL]que le projet InfSuite veut maintenant exploiter : les horodatages avec des fuseaux horaires. -La version post mise à jour de Npgsql était la version 4.1.13 et la dernière version disponible qui utilise les horodatages avec fuseau horaire est la version 8.0.3. En essayant de le mettre à jour avec cette version, je me suis rendu compte qu'#ref-glossary(term: "EF")[EF] n'était pas compatible avec la version 8.0.3. La dernière version du paquet Npgsql disponible pour #ref-glossary(term: "EF")[EF] étant la version 6.4.3, je dois donc me contenter de cette version. +La version post mise à jour de Npgsql était la version 4.1.13 et la dernière version disponible qui utilise les horodatages avec fuseau horaire est la version 8.0.3. En essayant de le mettre à jour avec cette version, je me suis rendu compte qu'#ref-glossary(term: "EF")[EntityFramework] étant la version 6.4.3, je dois donc me contenter de cette version. Avant de valider l'utilisation de ce dernier dans toute l'application, je dois valider qu'elle supporte les horodatages avec fuseau horaire et qu'elle est également compatible avec le reste de l'application. En se référant à la documentation fournie, la première version à intégrer les horodatages avec fuseau horaire est bien la version 6.X.X d'Npgsql, elle est donc compatible avec le besoin de sauvegarder les fuseaux horaires pour les versions. @@ -116,7 +116,7 @@ Si on souhaite passer sur la nouvelle version du paquet Npgsql, la version 8.X.X L'étude d'impact des coûts et des changements impliqués par une telle mise à jour a déjà été réalisée à priori de mon analyse et il en est ressorti que pour l'année courante, un tel budget ne pouvait pas être accordé pour cette mise à jour. Si je veux mettre à jour l'application pour utiliser les dernières fonctionnalités disponibles sans passer par une mise à jour d'EF, le seul choix qu'il reste est de mettre à jour Npgsql vers la version 6.X.X. -Le schéma @npgsql-versions-incompatibilty ci-dessous résume la situation d'incompatibilités entre les versions des trois éléments à savoir respectivement : à gauche Entity Framework, au centre le paquet Npgsql et à droite la base de données PostgreSQL. +Le schéma @npgsql-versions-incompatibilty ci-dessous résume la situation d'incompatibilités entre les versions des trois éléments à savoir respectivement : à gauche Entity Framework, au centre le paquet Npgsql et à droite la base de données #ref-glossary(term: "PostgreSQL")[PostgreSQL]. #figure( image("../assets/images/npgsql-versions-incompatibilty.png"), @@ -125,7 +125,7 @@ Le schéma @npgsql-versions-incompatibilty ci-dessous résume la situation d'inc === Tests de performance -La dernière étape permettant de valider cette étape de migration est de s'assurer que la nouvelle version de PostgreSQL installée à de meilleures performances que la version remplacée. Pour valider cela, il a été développé un système en interne de test de performance. L'architecture complexe de la base et la relation avec des données géographiques et attributaires peut rendre les requêtes parfois plus longues d'exécution. +La dernière étape permettant de valider cette étape de migration est de s'assurer que la nouvelle version de #ref-glossary(term: "PostgreSQL")[PostgreSQL]installée à de meilleures performances que la version remplacée. Pour valider cela, il a été développé un système en interne de test de performance. L'architecture complexe de la base et la relation avec des données géographiques et attributaires peut rendre les requêtes parfois plus longues d'exécution. Pour effectuer un test de performance, le système utilise une fonctionnalité gourmande en ressource, les groupes. Dans l'environnement InfSuite, il est possible d'afficher sur la carte les objets d'infrastructure. Par défaut tous les objets d'un dataowner sont affichés. Pour permettre d'axer son travail sur des objets d'infrastructures particuliers, alors il est possible d'appliquer un filtre à toutes ces entités. Le mode "Groupe" de l'application permet de créer alors deux types différents de filtres. @@ -133,13 +133,13 @@ Le premier type de filtres est un filtre statique. Peu gourmand en ressource et Le second type de filtre, plus complexe, est le filtre dynamique. Les filtres dynamiques permettent de gérer automatiquement les entités qui seront incluses ou exclues de l'affichage. Pour ce type de filtre, il est possible de créer des règles de filtrage avancées pour permettre à l'utilisateur plus de flexibilité.\ Un peu à la manière d'une requête SQL, il est possible de construire une requête qui va être exécutée pour permettre de retrouver les entités à partir de critères. Il est par exemple possible de demander de filtrer les ouvrages par position géographique en ne prenant en compte que ceux au-dessus d'une certaine latitude et de rajouter à ce filtre uniquement les ouvrages qui contiennent un certain numéro dans leur nom.\ -Il est possible de créer des règles avec chaque propriété d'un objet d'infrastructure, d'appliquer un ordre pour les conditions, de faire des agrégats, des jointures,... Les utilisateurs ont la liberté de créer leur propre requête, une requête pouvant devenir rapidement complexe, elle peut donc prendre plus de temps à filtrer les objets d'infrastructures pour les retourner à l'utilisateur.\ -Étant utilisé par les services GIS de l'application, s'assurer de la performance de ce système est primordial. +Il est possible de créer des règles avec chaque propriété d'un objet d'infrastructure, d'appliquer un ordre pour les conditions, de faire des agrégats, des jointures... Les utilisateurs ont la liberté de créer leur propre requête, une requête pouvant devenir rapidement complexe, elle peut donc prendre plus de temps à filtrer les objets d'infrastructures pour les retourner à l'utilisateur.\ +Étant utilisé par les services #ref-glossary(term: "GIS")[GIS] de l'application, s'assurer de la performance de ce système est primordial. Ce que l'outil permet de tester est ce système de groupe/filtres. Il va chercher les différents filtres existants en base de données, peu importe le client qui a pu les créer, et les exécuter.\ -Cette méthode permet de connaître les performances réelles de la base dans un cas pratique spécifique à l'application et non pas d'avoir des performances théoriques fournies par les développeurs du #ref-glossary(term: "SGBDR")[SGBDR] qui peuvent être tournées en leur faveur. Nous cherchons donc à savoir si le chiffre de 10% en gain de performances est réel ou non. +Cette méthode permet de connaître les performances réelles de la base dans un cas pratique spécifique à l'application et non pas d'avoir des performances théoriques fournies par les développeurs du SGBDR qui peuvent être tournées en leur faveur. Nous cherchons donc à savoir si le chiffre de 10% en gain de performances est réel ou non. -L'objectif est donc de comparer les performances de la base de production encore sous PostgreSQL 14, avec les performances d'une base de développement installée pour l'occasion, elle, sous PostgreSQL 16. Après avoir exécuté l'outil de benchmark sur les deux bases, je récupère les données brutes en sortie de programme pour les analyser. Ci-dessous un exemple de données de sorties fournies par le programme après exécution. +L'objectif est donc de comparer les performances de la base de production encore sous #ref-glossary(term: "PostgreSQL")[PostgreSQL]14, avec les performances d'une base de développement installée pour l'occasion, elle, sous #ref-glossary(term: "PostgreSQL")[PostgreSQL]16. Après avoir exécuté l'outil de benchmark sur les deux bases, je récupère les données brutes en sortie de programme pour les analyser. Ci-dessous un exemple de données de sorties fournies par le programme après exécution. ```csv eruid,description @@ -183,7 +183,7 @@ Structure du tableau de résultats: - La ligne *``` Identical_Ios_Duration```* indique le temps de traitement total (en millisecondes) uniquement pour les OIs identiques entre les deux bases. - La ligne *``` Average_Ios_Load_Duration```* indique le temps de traitement moyen écoulé (en millisecondes) par objet d'infrastructure. -Dans les réultats obtenus, je remarque rapidement que le temps de traitement entre les deux bases n'est pas drastiquement différent. Pour le temps de traitement global des objets d'infrastructure identiques entre les deux bases, on ne gagne que 0.23 milliseconde après la migration. Pour filtrer mes résultats j'utilise la méthode ``` =SUM(SUMIF(pg14[Group_Id]; VLOOKUP(pg14[Group_Id]; pg16[Group_Id]; 1;FALSE); pg14[Load_Duration_In_Ms]))``` qui va exclusivement récupérer les lignes où les groupes anaylsés sont présents dans les deux bases puis faire la somme des résultats de performances. +Dans les réultats obtenus, je remarque rapidement que le temps de traitement entre les deux bases n'est pas drastiquement différent. Pour le temps de traitement global des objets d'infrastructure identiques entre les deux bases, on ne gagne que 0.23 milliseconde après la migration. Pour filtrer mes résultats j'utilise la méthode ``` =SUM(SUMIF(pg14[Group_Id]; VLOOKUP(pg14[Group_Id]; pg16[Group_Id]; 1;FALSE); pg14[Load_Duration_In_Ms]))``` qui va exclusivement récupérer les lignes avec lesquelles les groupes analysés sont présents dans les deux bases puis faire la somme des résultats de performances. Pour terminer mon analyse, je transforme les résultats en pourcentages dans le tableau @perf_gain_sheet_1. Avec ça je peux comparer les 10% de performances annoncées avec les résultats réels obtenus. @@ -197,22 +197,22 @@ Pour terminer mon analyse, je transforme les résultats en pourcentages dans le ) ) -Comme je l'ai remarqué rapidement, le gain réel de performances entre les deux bases n'est que de 3.7%. Le score affiché pour les données anaylsées identiques entre les deux bases est encore plus faible avec uniquement 1.78% de perfomances gagnées. +Comme je l'ai remarqué rapidement, le gain réel de performances entre les deux bases n'est que de 3.7%. Le score affiché pour les données analysées identiques entre les deux bases est encore plus faible avec uniquement 1.78% de performances gagnées. -Ce résultat peut être le résultats de nombreux facteurs. Une première hypothèse qu'on peut emettre est que l'analyse de performances donnée par PostgreSQL concerne d'autre types de requêtes ou de perfomances de base. Un autre cas de figure est que le temps de traitement le plus long dans notre cas est obtenu par l'interface entre le code et la base: EntityFramework. En effet il se pourrait que la gestion des requêtes côté ORM soit la plus couteuse en ressource que tout le reste du système ce qui impacte le résultat final. Une dernière hypothèse serait un biais dans mon analyse. Une erreur humaine est plausible et il n'est pas exclu que je me sois trompé dans mes requêtes ou que j'ai oublié de prendre en compte tout autre élément ayant un impact direct sur les performances obtenues. +Ce résultat peut être les résultats de nombreux facteurs. Une première hypothèse qu'on peut émettre est que l'analyse de performances donnée par #ref-glossary(term: "PostgreSQL")[PostgreSQL]concerne d'autres types de requêtes ou de perfomances de base. Un autre cas de figure est que le temps de traitement le plus long dans notre cas est obtenu par l'interface entre le code et la base: #ref-glossary(term: "EF")[EntityFramework]. En effet, il se pourrait que la gestion des requêtes côté #ref-glossary(term: "ORM")[ORM ]soit la plus couteuse en ressource que tout le reste du système ce qui impacte le résultat final. Une dernière hypothèse serait un biais dans mon analyse. Une erreur humaine est plausible et il n'est pas exclu que je me sois trompé dans mes requêtes ou que j'ai oublié de prendre en compte tout autre élément ayant un impact direct sur les performances obtenues. -J'ai donc pu rendre mon rapport sur les comparatifs de perfomances à mon chef de projet pour qu'il valide, ou non, la suite de la migration de base de données. Les résultats de perfomances obtenus seuls, ne permettent pas de justifier un tel investissement pour cette migration. Cependant, comme évoqué plus haut, d'autres points importants tel que la sécurité ou la pérennité de l'application en mettant à jour la base on permit de soutenir la décision de continuer la migration. J'ai donc pu continuer les étapes de migration en passant sur la partie d'adaptation du code pour permettre à l'application de fonctionner avec la nouvelle base. +J'ai donc pu rendre mon rapport sur les comparatifs de performances à mon chef de projet pour qu'il valide, ou non, la suite de la migration de base de données. Les résultats de performances obtenus seuls, ne permettent pas de justifier un tel investissement pour cette migration. Cependant, comme évoqué plus haut, d'autres points importants tel que la sécurité ou la pérennité de l'application en mettant à jour la base, ont permit de soutenir la décision de continuer la migration. J'ai donc pu continuer les étapes de migration en passant sur la partie d'adaptation du code pour permettre à l'application de fonctionner avec la nouvelle base. #pagebreak(weak: true) == Adaptation du code Dans l'application, 24 projets au total utilisent le paquet Npgsql. Ces projets ne sont pas uniquement dédiés à la partie #ref-glossary(term: "Back-End")[back-end] de l'application, mais sont également des outils tiers développés pour des besoins spécifiques. Je peux par exemple citer l'outil IkCoordToRvg que j'ai pu aborder dans mon mémoire de licence, qui était le projet sur lequel j'ai pu travailler durant toute une année. Comme pour tout autre projet, il utilise des dépendances au projet Core d'InfSuite, qui nécessite lui-même le paquet Npgsql. Lorsque j'ai tenté une première fois de mettre à jour le paquet, je me suis retrouvé confronté à de nombreuses erreurs de compatibilité avec des dépendances externes. -Pour régler les conflits, une simple mise à jour vers une version plus récente des paquets concernés a suffi. Tout comme pour la mise à jour Npgsql, je m'assure dans un premier temps qu'il n'y ai pas de changements majeurs qui risque de casser le bon fonctionnement de l'application, puis j'effectue la mise à jour. Je dois maintenant adapter le code concerné. +Pour régler les conflits, une simple mise à jour vers une version plus récente des paquets concernés a suffi. Tout comme pour la mise à jour Npgsql, je m'assure dans un premier temps qu'il n'y ait pas de changements majeurs qui risque de casser le bon fonctionnement de l'application, puis j'effectue la mise à jour. Je dois maintenant adapter le code concerné. -Pour gérer les formats de certaines données, l'application utilise une inférence du type de données. Pour le cas de la mise à jour de la colonne version, on la met à jour pour utiliser des horodatages avec fuseau horaire. Cependant, le reste des modèles utilisant des horodatages dans d'autres parties de l'application n'ont pas été mis à jour. Ils utilisent toujoursla versions sans fuseau horaire. +Pour gérer les formats de certaines données, l'application utilise une inférence du type de données. Pour le cas de la mise à jour de la colonne version, on la met à jour pour utiliser des horodatages avec fuseau horaire. Cependant, le reste des modèles utilisant des horodatages dans d'autres parties de l'application n'ont pas été mis à jour. Ils utilisent toujours la version sans fuseau horaire. -Il faut donc préciser à notre application que pour le type de données DateTime dans l'application InfSuite, cela correspond au type DateTime2 en base de donnée (horodatage sans fuseau horaire). Dans l'autre sens, il n'y a pas la même problématique puisque les DateTime en C\# contiennent un fuseau horaire.\ +Il faut donc préciser à notre application que pour le type de données DateTime dans l'application InfSuite, cela correspond au type DateTime2 en base de donnée (horodatage sans fuseau horaire). Dans l'autre sens, il n'y a pas la même problématique puisque les DateTime en #ref-glossary(term: "C#")[C\#] contiennent un fuseau horaire.\ Ainsi, si au moment de la conversion l'horodatage ne contient pas cette information, alors le serveur utilise par défaut le fuseau horaire de sa propre localisation. Pour gérer l'inférence des données, je dois rajouter une nouvelle étape de vérification pour le convertisseur JSON en lui précisant comment gérer le nouveau format. Un simple ajout de la ligne ci-dessous dans les types personnalisé permet cette inférence. Elle récupère simplement le contenu textuel de la requête et essayer de valider que c'est une date. Si c'est le cas alors, il infère le type Date pour l'application, sinon il exécute le reste du programme comme normalement. @@ -220,10 +220,10 @@ Pour gérer l'inférence des données, je dois rajouter une nouvelle étape de v JsonTokenType.String when reader.TryGetDateTime(out DateTime datetime) => DateTime.SpecifyKind(datetime, DateTimeKind.Unspecified), ``` -Pour préciser quels sont les entitées en base de données qui n'utilisent pas le format par défaut DateTime2, je rajoute à la variable ``` Version``` dans les entitées concernées l'anotation ``` [JsonConverter(typeof(DateTimeUtcConverter))]```. De la sorte ,je le force à utiliser un convertisseur différent. +Pour préciser quels sont les entités en base de données qui n'utilisent pas le format par défaut DateTime2, je rajoute à la variable ``` Version``` dans les entitées concernées l'anotation ``` [JsonConverter(typeof(DateTimeUtcConverter))]```. De la sorte, je le force à utiliser un convertisseur différent. -Pour permettre de gérer ces dates différement j'ai pu créer deux convertisseurs de dates. Ils ont un fonctionnement similaire, il ne varient que par le type de date retourné. Dans le bloc de code @codebloc-dt-unspecified les dates sont retournée sans fuseau horaire s'il n'est pas présent tandis que dans le bloc de code @codebloc-dt-utc il prends en valeur par défaut le fuseau horaire UTC.\ -Il est bon de remarquer que j'utilise dans mon anotation de variable pour mon entité ci-avant, le convertisseur que j'expose dans le bloc de code @codebloc-dt-utc. +Pour permettre de gérer ces dates différement, j'ai pu créer deux convertisseurs de dates. Ils ont un fonctionnement similaire, ils ne varient que par le type de date retourné. Dans le bloc de code @codebloc-dt-unspecified les dates sont retournées sans fuseau horaire s'il n'est pas présent tandis que dans le bloc de code @codebloc-dt-utc il prends en valeur par défaut le fuseau horaire UTC.\ +Il est bon de remarquer que j'utilise dans mon annotation de variable pour mon entité ci-avant, le convertisseur que j'expose dans le bloc de code @codebloc-dt-utc. #figure(image("../assets/images/codebloc-dt-unspecified.png"), caption: [Bloc de code d'un convertisseur de date sans fuseau horaire]) @@ -248,7 +248,7 @@ C'est en me rappelant cela que j'ai réalisé que les tests ont été réalisés La mise en production étant un environnement sensible et n'ayant pas les compétences d'administrateur système nécessaires, je n'ai pas pu participer à la mise en place de la mise en production des changements. J'ai cependant pu vérifier que tout fonctionnait comme attendu en inspectant l'environnement de production. -Une fois le serveur de production mis à jour avec les nouveaux éléments, j'effectue un nouveau test de performance pour valider que le biais de différence de performance entre les environnements est bien la source du problème. Je conserve les données obtenues précédemment pour la base PostgreSQL 14 et je récupère le résultat de l'outil de benchmark une fois exécuté sur la nouvelle base et sur le même environnement pour une comparaison correcte. +Une fois le serveur de production mis à jour avec les nouveaux éléments, j'effectue un nouveau test de performance pour valider que le biais de différence de performance entre les environnements est bien la source du problème. Je conserve les données obtenues précédemment pour la base #ref-glossary(term: "PostgreSQL")[PostgreSQL]14 et je récupère le résultat de l'outil de benchmark une fois exécuté sur la nouvelle base et sur le même environnement pour une comparaison correcte. #figure( table( @@ -274,12 +274,12 @@ Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas fo ) ) -Les résultats du tableau @perf_gain_sheet_2 confirment ma supposition. La différence entre les deux environnements a biaisé les résultats des analyses. Sur les OIs identiques, on retrouve cette fois-ci les dix pourcents annoncés par l'équipe de développement de PostgreSQL. Encore mieux, je remarque que pour les OIs analysés au global dans les deux bases, la différence de performances grimpe jusqu'à onze pourcents. +Les résultats du tableau @perf_gain_sheet_2 confirment ma supposition. La différence entre les deux environnements a biaisé les résultats des analyses. Sur les OIs identiques, on retrouve cette fois-ci les dix pourcents annoncés par l'équipe de développement de #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Encore mieux, je remarque que pour les OIs analysés au global dans les deux bases, la différence de performances grimpe jusqu'à onze pourcents. -Le projet bénéficie donc des améliorations de performances promises par l'équipe PostgreSQL, mais surtout, de performances encore plus accrues que prévues par rapport à l'ancien système. +Le projet bénéficie donc des améliorations de performances promises par l'équipe #ref-glossary(term: "PostgreSQL")[PostgreSQL], mais surtout, de performances encore plus accrues que prévu par rapport à l'ancien système. === Problèmes rencontrés -Après la mise en place du nouveau système, une erreur de compatibilité dans les transactions entre l'application Observo et InfSuite est apparue. Malgré les nombreuses étapes de tests, les anaylses préliminaires, la mise en place du système sur un serveur intermédiaire nommé staging qui est très similaire à l'environnement de production, le problème n'a pas pu être détécté avant. Il n'est survenu que lors de la mise en place des mises à jour sur le serveur de production. +Après la mise en place du nouveau système, une erreur de compatibilité dans les transactions entre l'application Observo et InfSuite est apparue. Malgré les nombreuses étapes de tests, les analyses préliminaires, la mise en place du système sur un serveur intermédiaire nommé Staging qui est très similaire à l'environnement de production, le problème n'a pas pu être détecté avant. Il n'est survenu que lors de la mise en place des mises à jour sur le serveur de production. -Le problème concernait une erreur de compatibilité avec les fameuses date lors de l'échange de données entre les deux application. La différence de format fournie par InfSuite n'était pas valide côté Observo, le système retrouvait donc la transaction en échec. \ No newline at end of file +Le problème concernait une erreur de compatibilité avec les fameuses date lors de l'échange de données entre les deux applications. La différence de format fournie par InfSuite n'était pas valide côté Observo, le système retrouvait donc la transaction en échec. \ No newline at end of file diff --git a/main.pdf b/main.pdf index 0b5b0b7..61221ef 100644 Binary files a/main.pdf and b/main.pdf differ diff --git a/main.typ b/main.typ index 6946ba3..c98bff8 100644 --- a/main.typ +++ b/main.typ @@ -11,35 +11,32 @@ degree: "Master informatique et mobilité", promotion: (title: "UHA 4.0.5", year: 2024), acronyms: ( - "OFROU": (ref-glossary(term: "OFROU")[Office Fédérale des Routes]), - "SGBDR": (ref-glossary(term: "SGBDR")[Système de gestion de base de données relationnelle]), - "EF": (ref-glossary(term: "EF")[Entity Framework]), - "ORM": (ref-glossary(term: "ORM")[Object Relational Mapping]), - "IA": (ref-glossary(term: "IA")[Intelligence Artificielle]), - "GIS": (ref-glossary(term: "GIS")[Geographic Information System]), - "IoT": (ref-glossary(term: "IOT")[Internet of Things]), - + "OFROU": ("Office Fédérale des Routes"), + "SGBDR": ("Système de gestion de base de données relationnelle"), + "EF": ("Entity Framework"), + "ORM": ("Object Relational Mapping"), + "IA": ("Intelligence Artificielle"), + "GIS": ("Geographic Information System"), + "IoT": ("Internet of Things"), ), glossary: ( "Dump": [Un fichier "dump" est un fichier de sauvegarde qui contient une copie de toutes les données et métadonnées d'une base de données à un instant T.], "OFROU": [L'Office Fédérale des Routes est l'autorité suisse compétente pour l'infrastructure routière], "SGBDR": [Un système de gestion de base de données relationnelle est le système composant une base de données.], - "BE": [Partie d'un système informatique ou d'une application qui gère la logique métier, les bases de données, et les opérations côté serveur.], - "FE": [Partie visible d'une application ou d'un site web avec laquelle les utilisateurs interagissent directement. ], - "EF": [Entity Framework qui se décline également en Entity Framework Core, est une librairie C\# qui sert d'ORM], + "Back-End": [Partie d'un système informatique ou d'une application qui gère la logique métier, les bases de données, et les opérations côté serveur.], + "Front-End": [Partie visible d'une application ou d'un site web avec laquelle les utilisateurs interagissent directement. ], + "EF": [Entity Framework qui se décline également en Entity Framework Core, est une librairie #ref-glossary(term: "C#")[C\#] qui sert d'ORM], "ORM": [De l'anglais Object Relational Mapping, permet d'interfacer les objets code avec les données contenues en base de données.], "Sharding": [Technique de partitionnement horizontal des bases de données pour améliorer leur performance et leur scalabilité.], "API": [Une interface de programmation qui permet à des applications informatiques de communiquer entre elles via internet.], - "PSQL": [Un SGBDR open source connu pour sa fiabilité et sa capacité à gérer des gros volumes de données.], - "CSharp": [Un language de programmation utilisé pour le développement d'applications notamment avec l'ORM Entity Framework.], - "TS": [Un language de programmation qui est un surensemble de JavaScript, souvent utilisé avec Angular pour développer des applications web dynamiques.], + "PostgreSQL": [Un SGBDR open source connu pour sa fiabilité et sa capacité à gérer des gros volumes de données.], + "C#": [Un language de programmation utilisé pour le développement d'applications notamment avec l'ORM Entity Framework.], + "TS": [Un language de programmation qui est un surensemble de JavaScript, souvent utilisé avec #ref-glossary(term: "Angular")[Angular] pour développer des applications web dynamiques.], "Angular": [Un framework de développement web open source, utilisé pour créer des applications web dynamiques et réactives.], "GIS": [Un système qui permet de capturer, stocker, manipuler, analyse, gérer et présenter des données spatiales ou géographiques], "IoT": [Un réseau d'objets physiques interconnectés qui peuvent collecter et échanger des données.], - "SM": [Un rôle dans la méthodologie Scrum, responsable de la facilitation et de la coordination des processus Scrum au sein d'une équipe de développement], - "IA": [Un domaine de l'informatique qui se concentre sur la création de systèmes capables d'effectuer des tâches nécessitant normalement l'intelligence humaine.], - "OC": [Un domaine de l'optimisation mathématique qui cherche à trouver la meilleure solution parmi un ensemble fini de solutions possibles.], - "DM": [Le processus de découverte de modèles et de connaissances à partir de grandes quantités de données.] + "Scrum-Master": [Un rôle dans la méthodologie Scrum, responsable de la facilitation et de la coordination des processus Scrum au sein d'une équipe de développement], + "IA": [Un domaine de l'informatique qui se concentre sur la création de systèmes capables d'effectuer des tâches nécessitant normalement l'intelligence humaine.] ), hayagriva-bibliography: "bibliographie.yml", thanks: [ @@ -56,7 +53,7 @@ Enfin, je souhaite exprimer ma gratitude envers les relecteurs de ce rapport pou introduction: [ Après avoir réalisé mon parcours de licence professionnelle "Développeur informatique" au sein de l'UHA et obtenu mon diplôme, j'ai souhaité approfondir mes connaissances rejoignant le cursus master proposé par l'UHA 4.0 qui fait suite à la licence. -Mon parcours de master a été réalisé au sein de l'entreprise Unit Solutions basée à Allschwil en Suisse, qui s'était déjà proposée de me suivre dans mon cursus universitaire pour les deux années précédentes. Mes contributions principales se sont orientées sur le projet InfSuite et l'environnement l'entourant. L'application pour laquelle j'ai pu apporter ma contribution a comme objectif premier de gérer le suivi et la maintenance d'état d'ouvrages d'art. +Mon parcours de master a été réalisé au sein de l'entreprise Unit Solutions basé à Allschwil en Suisse, qui s'était déjà proposée de me suivre dans mon cursus universitaire pour les deux années précédentes. Mes contributions principales se sont orientées sur le projet InfSuite et l'environnement l'entourant. L'application pour laquelle j'ai pu apporter ma contribution a comme objectif premier de gérer le suivi et la maintenance d'état d'ouvrages d'art. Dans ce mémoire, je vous présenterais les détails du projet InfSuite et de ma contribution au projet. J'ai eu pour objectif principal de planifier et de réaliser une migration de base de données. En effet, la base de données étant un point clef de l'application, une maintenance de cette dernière est nécessaire pour assurer une certaine pérennité de l'application. Cette étape de migration s'inscrit dans un projet de maintenir les technologies de l'application à jour et de permettre de palier à d'autres problèmes. @@ -67,11 +64,24 @@ Pour conclure cette seconde année de master en alternance chez Unit Solutions, Cette tâche complexe, nécessitant une compréhension approfondie de l'architecture logicielles et de la gestion de données (syntaxe SQL, compréhension d'un SGBDR, etc.), m'a offert dans un premier temps une experience pratique précieuse, et dans un second temps, l'occasion de renforcer ma capacité à interpréter et résoudre une problématique technique complexe et sensible. -L'opportunité d'avoir un rôle aussi marqué sur ce projet a renforcé ma confiance en mes compétences professionnelles et m'a permis de contribuer de manière tangible à cette mission a fort intérêt pour l'entreprise. Le soutien constant et les conseils de mon chef de projet, des encadrants de la formation, ainsi que l'environnement de travail collaboratif chez Unit Solutions, ont été un facteur clé de la réussite de cette mission. +L'opportunité d'avoir un rôle aussi marqué sur ce projet a renforcé ma confiance en mes compétences professionnelles et m'a permis de contribuer de manière tangible à cette mission à fort intérêt pour l'entreprise. Le soutien constant et les conseils de mon chef de projet, des encadrants de la formation, ainsi que l'environnement de travail collaboratif chez Unit Solutions, ont été un facteur clé de la réussite de cette mission. Le travail réalisé tout au long de cette année pour la migration de base de données est maintenant installé en production et fonctionne de manière nominale pour tous les utilisateurs et services tiers de l'application. Cette migration permettra à l'avenir d'étendre les fonctionnalités et les performances de l'application. Cette alternance, marquée par des défis techniques aussi bien sur l'apprentissage de nouveaux éléments que leur mise en pratique, a non seulement enrichi mon parcours académique, mais a également posé les bases solides pour mon avenir professionnel. En effet, cette expérience se concrétise par mon intégration prochaine en CDI au sein de l'entreprise, marquant ainsi le début de ma carrière dans le domaine professionnel à temps plein. Ce parcours chez Unit Solutions, alliant théorie et pratique, a été une étape déterminante pour mon développement personnel et professionnel, et je me réjouis de poursuivre cette collaboration fructueuse. + +"Julien clôture sa troisième année dans notre entreprise. + +Continuant sur sa lancée de fin de deuxième année, il a travaillé ces 12 derniers mois sur le module principal de l'application web en production chez nos clients (par opposition aux deux premières années où il avait plus développé sur des modules et outils destinés aux administrateurs de l'application, donc moins sensibles). Ce passage sur le module principal témoigne de notre confiance en son travail. + +Julien a continué à progresser sur le développement côté client comme celui côté serveur, ce qui lui permet aujourd'hui de pouvoir développer un Change Request de façon autonome (une fois l'architecture posée et validée avec l'architecte) et d'avoir le statut de Full Stack Developer dans notre équipe. L'année passée nous attendions encore une amélioration au niveau de la rapidité de développement. De nets progrès ont été réalisés à ce sujet. + +Enfin, cette année a également été l'occasion de découvrir un talent de Julien pour le design de l'interface utilisateur. + +Tous ces éléments positifs ont conduit l'entreprise à proposer à Julien un poste en CDI à la fin de son stage, offre qu'il a accepté.\ +L'histoire avec Julien continue donc chez Unit Solutions AG à partir d'octobre 2024...» +#set align(right) +*M. Cédric Martin*, chef de projet de la suite logicielle « InfSuite » ], abstract: [Abstract], keywords: ("", "") diff --git a/olds/n-hbist-back/main.typ b/olds/n-hbist-back/main.typ index 5e18cd2..f38e477 100644 --- a/olds/n-hbist-back/main.typ +++ b/olds/n-hbist-back/main.typ @@ -41,13 +41,13 @@ "CRM": [un "CRM" (#display-def("CRM")) ou "gestion de la relation client" est un ensemble d'outils permettant d'améliorer les relations commerciales entre l'entreprise et ses clients.], "Plugin": [un "plugin" est un module d'extension qui permet d'ajouter un ensemble de fonctionnalités à un logiciel.], "POC": [un "POC" (#display-def("POC")) est une conception qui permet de démontrer qu'un projet est réalisable.], - "Back-end": ["Back-end" est la couche fonctionnelle d'une application, que l'utilisateur ne voit pas. Elle se situe généralement au niveau du serveur.], - "Front-end": ["Front-end" est la couche visible par l'utilisateur d'une application. Elle permet à l'utilisateur d'intéragir facilement avec l'application.], + "#ref-glossary(term: "Back-End")[Back-end]": ["#ref-glossary(term: "Back-End")[Back-end]" est la couche fonctionnelle d'une application, que l'utilisateur ne voit pas. Elle se situe généralement au niveau du serveur.], + "#ref-glossary(term: "Front-End")[Front-end]": ["#ref-glossary(term: "Front-End")[Front-end]" est la couche visible par l'utilisateur d'une application. Elle permet à l'utilisateur d'intéragir facilement avec l'application.], "Bibliothèque de développement": [une "bibliothèque de développement est un ensemble de codes prêts à l'emploi qui permettent de gagner en temps et en efficacité pour un développement.], "Notification push": [Une "notification push" est une alerte sur appareil mobile, similaire à un SMS, mais qui n'est envoyé qu'aux utilisateurs ayant installé l'application et qui ont autorisé les notifications.], "SQL": [le "SQL" (#display-def("SQL")) est un langage informatique utilisé pour manipuler les données d'une base de données relationnelle (comme par exemple MySQL et PostgreSQL).], "JSON": [le "JSON" (#display-def("JSON")) est un format de données flexible dérivé de la notation des objets JavaScript, et utilisé pour représenter et transmettre des données.], - "Service web": [les services web permettent à la couche serveur (back-end) de transmettre des données demandées. Dans le cas d'une application, la couche client (front-end) demande des informations à un service web, qui les lui renvoie aussitôt.], + "Service web": [les services web permettent à la couche serveur (#ref-glossary(term: "Back-End")[back-end]) de transmettre des données demandées. Dans le cas d'une application, la couche client (#ref-glossary(term: "Front-End")[front-end]) demande des informations à un service web, qui les lui renvoie aussitôt.], "CSV": [le "CSV" (#display-def("CSV")) est un format texte ouvert sans spécification formelle représentant des données tabulaires, délimitées par des virgules ou des points virgules pour le format français.], "ORM": [un "ORM" (#display-def("ORM")) est un processus de codes utilisé pour associer automatiquement la valeur d'un objet avec sa valeur en base de données, permettant de faciliter le processus d'enregistrement et de récupération de données en base de données.], "ERP": ["ERP" (#display-def("ERP")), ou "progiciel de gestion intégré", est une solution informatique permettant à une entreprise de piloter facilement des processus liés à son activité.], @@ -140,7 +140,7 @@ La formation UHA 4.0, délivrée par l'Université de Haute-Alsace, forme des Pendant 3 ans, les étudiants y découvrent tout d'abord les bases de la programmation par le biais des applications web, puis des concepts plus avancés comme la #ref-glossary(term: "POO", acr("POO")) qui est au cœur des applications les plus complexes. Cette formation se démarque des autres car elle propose une approche unique dite "par projets" : les étudiants sont amenés à travailler en groupe de 4 à 6 sur des projets réels apportés par des entreprises et en suivant la #ref-glossary(term: "Méthode Agile")[méthode Agile] de gestion de projet "SCRUM". Cela permet aux étudiants d'être formés en travaillant dans des conditions similaires à celles d'une entreprise, tout en ayant un contact permanent avec le client final.\ -Les étudiants sont également formés pour devenir chefs de projets (ou "Scrum masters"), c'est-à-dire qu'ils vont apprendre à diriger une équipe de développeurs et à réagir face à toutes sortes de situations et d'imprévus. +Les étudiants sont également formés pour devenir chefs de projets (ou "#ref-glossary(term: "Scrum-Master")[Scrum master] s"), c'est-à-dire qu'ils vont apprendre à diriger une équipe de développeurs et à réagir face à toutes sortes de situations et d'imprévus. En plus de leurs propres recherches personnelles (ressources en ligne, aide par d'autres étudiants et encadrants, ressources mises à disposition par l'école...), les étudiants découvrent de nouveaux concepts grâce à des topos donnés par les encadrants. Ces concepts théoriques sont mis en pratique par l'étudiant lors du "fil rouge" : une période de 2 mois durant laquelle l'étudiant travaillera sur un projet individuel, qu'il fera évoluer chaque semaine en intégrant ces nouveaux concepts. @@ -156,13 +156,13 @@ En plus de leurs propres recherches personnelles (ressources en ligne, aide par #formation-step[Badgeuse] Le projet "Badgeuse" est un projet interne créé et maintenu depuis 2018 par les étudiants et les encadrants d'UHA 4.0 pendant les phases de projets. \ L'objectif du projet est d'apporter un ensemble d'outils pratiques aux encadrants et aux étudiants : il permet aux étudiants de pointer pour déclarer leur présence dans l'école, de constater en temps réel les absences et présences, de consulter et de postuler à des projets proposés pour les phases de projets... L'équipe pédagogique peut également utiliser l'application pour suivre le temps de présence des étudiants, diffuser des annonces, répartir les étudiants dans les projets et suivre leur activité journalière. \ - Le projet ayant été développé avec les technologies Angular pour la partie client, NodeJS pour la partie serveur et MariaDB pour la base de données, j'ai pu approfondir mes connaissances dans ces technologies. \ + Le projet ayant été développé avec les technologies #ref-glossary(term: "Angular")[Angular] pour la partie client, NodeJS pour la partie serveur et MariaDB pour la base de données, j'ai pu approfondir mes connaissances dans ces technologies. \ J'ai été nommé chef de projet pour la première fois. Ma contribution a été la refactorisation complète du code du serveur, en collaboration avec un autre étudiant d'UHA 4.0, *Octave Blandet*. De plus, je me suis occupé d'une grande partie de la refonte des profils utilisateurs sur l'application, afin d'apporter une bien meilleure expérience utilisateur. J'ai également corrigé de nombreuses anomalies signalées. #formation-step[Admission] Mon second projet de première année se nomme "Admission".\ Également initié par l'UHA 4.0, c'est un outil destiné à l'équipe pédagogique d'UHA 4.0 afin de répondre à la problématique d'admission des nouveaux étudiants au sein de l'école : aujourd'hui, les candidatures d'admission à l'école se font par le biais de formulaires Google. Dès que la candidature est retenue, les candidats reçoivent par email une invitation à un entretien d'admission avec l'école. Ensuite, les candidats retenus doivent fournir des documents administratifs par email à l'école. Ce processus d'admission est aujourd'hui fastidieux pour l'équipe pédagogique. C'est pourquoi la mise en place de la plateforme Admission a été décidée, afin de permettre aux candidats de déposer et de consulter l'état de leur candidatures directement sur la plateforme, et également de pouvoir déposer les différents documents administratifs nécessaires à leur inscription. Pour l'équipe pédagogique, ce sera un gain de temps considérable car l'ensemble du processus pourra se faire à partir d'un même outil.\ - Cette application est construite avec les technologies Angular pour la partie client, NestJS pour la partie serveur et MariaDB pour la base de données.\ + Cette application est construite avec les technologies #ref-glossary(term: "Angular")[Angular] pour la partie client, NestJS pour la partie serveur et MariaDB pour la base de données.\ Dans ce projet, ma tâche principale a été de mettre en place un système d'authentification complet et sécurisé, basé sur la technologie des #ref-glossary(term: "JWT", acr("JWT")). De plus, j'ai également contribué à l'ajout de plusieurs fonctionnalités importantes dans l'application telle que la possibilité de créer des configurations de candidats par année, pour pouvoir les retrouver ultérieurement. #formation-step[Stage chez Conselio] @@ -179,7 +179,7 @@ En plus de leurs propres recherches personnelles (ressources en ligne, aide par "Steamer" est une application mobile que nous avons créée à la demande de l'entreprise "Mithra Productions", et qui a pour but de faciliter les rencontres entre passionnés de jeux-vidéos : lorsqu'un joueur de jeux-vidéos souhaite jouer en mode "multijoueurs" mais que ses partenaires de jeu habituels ne sont pas disponibles, l'application Steamer lui permettra de trouver d'autres partenaires pour jouer avec lui.\ Steamer se présente comme une application mobile de type "#ref-glossary(term: "POC", acr("POC"))" inspirée des applications de rencontre (par exemple Tinder).\ Le cahier des charges fourni par le client nous imposait de faciliter l'inscription des joueurs, de leur proposer des profils de partenaires en fonction de leurs préférences, et de leur donner accès à un tchat. - Pour réaliser ce projet, mes 4 collègues et moi avons choisi d'utiliser les technologies GraphQL, Cloudflare Workers, NestJS et MongoDB pour la partie #ref-glossary(term: "Back-end")[back-end], et Flutter pour la partie #ref-glossary(term: "Front-end")[front-end]. \ + Pour réaliser ce projet, mes 4 collègues et moi avons choisi d'utiliser les technologies GraphQL, Cloudflare Workers, NestJS et MongoDB pour la partie #ref-glossary(term: "#ref-glossary(term: "Back-End")[Back-end]")[#ref-glossary(term: "Back-End")[back-end]], et Flutter pour la partie #ref-glossary(term: "#ref-glossary(term: "Front-End")[Front-end]")[#ref-glossary(term: "Front-End")[front-end]]. \ J'ai quant à moi principalement contribué au développement des différents services web nécessaires au fonctionnement de l'application, et mis en place l'algorithme permettant la mise en relation des utilisateurs compatibles. \ Nous avons réussi à livrer le projet dans les temps, en respectant les 3 fonctionnalités imposées par le cahier des charges. @@ -187,7 +187,7 @@ En plus de leurs propres recherches personnelles (ressources en ligne, aide par Le projet "Alertes" nous a été confié par un ancien étudiant d'UHA 4.0, *M. Luc Ratelli*, et s'adresse à des informaticiens.\ L'objectif d’Alertes est de surveiller diverses sources de données et d'alerter l'utilisateur par mail ou par "#ref-glossary(term: "Notification push")[notification push]" lorsqu'une condition, configurée par l'utilisateur avec une syntaxe similaire au #ref-glossary(term: "SQL", acr("SQL")), est remplie. Les sources de données peuvent être des bases de données #ref-glossary(term: "SQL", acr("SQL")) (par exemple PostgreSQL ou MySQL) ou des réponses #ref-glossary(term: "JSON", acr("JSON")), provenant d'appels automatiques à un #ref-glossary(term: "Service web")[service web].\ Par exemple, Alertes pourrait prévenir un commerçant du stock faible d'un article lorsque la valeur du champ "stock" de cet article en base de données passe sous un seuil établi.\ - Pour le développement de ce projet, les technologies suivantes nous ont été imposées par le client : Angular pour la partie client, Spring pour la partie serveur et PostgreSQL pour la persistance des données de l'application. \ + Pour le développement de ce projet, les technologies suivantes nous ont été imposées par le client : #ref-glossary(term: "Angular")[Angular] pour la partie client, Spring pour la partie serveur et PostgreSQL pour la persistance des données de l'application. \ Mon rôle a été de mettre en place les connecteurs intelligents entre l'application Alertes et les différentes sources de données sujettes aux notifications. J'ai également créé un #ref-glossary(term: "Service web")[service web] permettant l'introspection des sources de données : il permet d'afficher graphiquement à l'utilisateur un schéma de la structure d'une source de données. \ Ce projet a été très enrichissant pour notre équipe, car il a impliqué un grand travail de recherche et de nombreuses contraintes techniques auxquelles il a fallu faire face. Notre client a été très satisfait du travail réalisé. @@ -215,7 +215,7 @@ En plus de leurs propres recherches personnelles (ressources en ligne, aide par Pour faciliter la gestion du stock de ses pièces détachées dans ses entrepôts, Envie a demandé à UHA 4.0 de concevoir son nouveau système de gestion logistique. L'objectif était d'obtenir un nouveau système permettant de gérer facilement l’entrée et la sortie de stock des pièces détachées des entrepôts de l'entreprise.\ J'ai été affecté à ce projet avec 2 autres étudiants de 3ème année et 3 autres étudiants de 1ère année.\ Le client souhaitait disposer d'une application web destinée au paramétrage et à la consultation de ses diverses pièces détachées en stock, et d'une application mobile pour pouvoir gérer facilement l'entrée et la sortie de stock de ces pièces détâchées.\ - Pour ce projet, ma contribution s'est majoritairement concentrée sur le #ref-glossary(term: "Back-end")[back-end] (développé avec NestJS) et l'application mobile : je me suis occupé de mettre en place des services web nécessaires au fonctionnement du système, et j'ai également eu la responsabilité de la création de l'application mobile avec la mise en place des fonctionnalités d'entrée et de sortie de stock dans celle-ci.\ + Pour ce projet, ma contribution s'est majoritairement concentrée sur le #ref-glossary(term: "#ref-glossary(term: "Back-End")[Back-end]")[#ref-glossary(term: "Back-End")[back-end]] (développé avec NestJS) et l'application mobile : je me suis occupé de mettre en place des services web nécessaires au fonctionnement du système, et j'ai également eu la responsabilité de la création de l'application mobile avec la mise en place des fonctionnalités d'entrée et de sortie de stock dans celle-ci.\ Étant donné que le client voulait pouvoir utiliser l'application sur tout type d'appareils mobiles, mon choix technologique s'est porté sur Flutter : ce framework permet de développer des applications fonctionnant nativement sur tout type d'appareils avec une même base de code.\ J'ai également travaillé sur certaines fonctionnalités de l'interface web du système. Cela m'a permis de découvrir le framework NextJS choisi initialement par l'équipe. Le projet a été réalisé avec succès, les demandes du client ont pu être respectées. Par la suite, il a été poursuivi par d'autres étudiants lors d'autres itérations de projets. @@ -224,9 +224,9 @@ En plus de leurs propres recherches personnelles (ressources en ligne, aide par COP AMACO est le dernier projet sur lequel j'ai pu travailler à l'école.\ COP AMACO est une entreprise strasbourgeoise spécialisée dans l'équipement des points de vente commerciaux. Elle commercialise notamment l'écosystème "Atmos". Atmos permet le contrôle et la gestion d'un ensemble d'appareils connectés dans le magasin (par exemple les caisses), la diffusion de bandes sonores dans plusieurs rayons du magasin à des moments précis de la journée...\ Pour ce projet, notre tâche a consisté à mettre en place une nouvelle pièce de l'écosystème Atmos : la gestion d'écrans connectés dans le magasin.\ - À cette occasion, j'ai été une nouvelle fois nommé "Scrum Master" pour diriger 4 étudiants de première année.\ + À cette occasion, j'ai été une nouvelle fois nommé "#ref-glossary(term: "Scrum-Master")[Scrum Master] " pour diriger 4 étudiants de première année.\ L'objectif demandé était de permettre la diffusion de vidéos sur les écrans présents dans les points de vente en des lieux et à des fréquences choisies.\ - Les technologies utilisées pour le projet ont été imposées par le client : Angular pour la partie client, NestJS pour la partie serveur et #acr("AWS") pour les solutions cloud.\ + Les technologies utilisées pour le projet ont été imposées par le client : #ref-glossary(term: "Angular")[Angular] pour la partie client, NestJS pour la partie serveur et #acr("AWS") pour les solutions cloud.\ Ma contribution au sein de ce projet s'est portée sur la mise en place des différents services web nécessaires au fonctionnement du système, la mise en place de l'envoi des vidéos, la génération d'une miniature pour la vidéo envoyée et la lecture en streaming des vidéos.\ Les demandes du client ont pu être réalisées dans les temps. @@ -297,10 +297,10 @@ Comme évoqué précédemment dans le @2e-annee-formation, Suivefluid est aujour - Etc. Afin d'optimiser la conception de ses logiciels, des équipes d'Efluid développent activement deux frameworks utilisés dans la totalité des applications de l'entreprise dont Suivefluid : -+ Le framework "historique", developpé à l'origine par un prestataire, est écrit dans le langage Java. Il est conçu pour les couches #ref-glossary(term: "Back-end")[back-end] (serveur) et #ref-glossary(term: "Front-end")[front-end] (client) des applications. Ce framework repose sur la technologie des #acr("JSP") et des services REST, et est utilisé aujourd'hui par la totalité des applications de l'entreprise. -+ Le framework "FullJS", développé initialement par Efluid SAS et écrit dans le language JavaScript, a été créé pour être en adéquation avec les nouvelles technologies et les contraintes imposées par celles-ci. Ce framework, conçu uniquement pour la couche #ref-glossary(term: "Front-end")[front-end], repose sur la #ref-glossary(term: "Bibliothèque de développement")[bibliothèque de développement] "lit-html", elle-même basée sur la nouvelle technologie des composants web en cours de normalisation par le "#acr("W3C")", organisme international régulateur des standards techniques liés au web. Il apporte un ensemble de composants graphiques utilisés afin de réduire le temps de développement des fonctionnalités tout en garantissant une cohérence graphique pour l'ensemble des applications développées par l'entreprise. ++ Le framework "historique", developpé à l'origine par un prestataire, est écrit dans le langage Java. Il est conçu pour les couches #ref-glossary(term: "#ref-glossary(term: "Back-End")[Back-end]")[#ref-glossary(term: "Back-End")[back-end]] (serveur) et #ref-glossary(term: "#ref-glossary(term: "Front-End")[Front-end]")[#ref-glossary(term: "Front-End")[front-end]] (client) des applications. Ce framework repose sur la technologie des #acr("JSP") et des services REST, et est utilisé aujourd'hui par la totalité des applications de l'entreprise. ++ Le framework "FullJS", développé initialement par Efluid SAS et écrit dans le language JavaScript, a été créé pour être en adéquation avec les nouvelles technologies et les contraintes imposées par celles-ci. Ce framework, conçu uniquement pour la couche #ref-glossary(term: "#ref-glossary(term: "Front-End")[Front-end]")[#ref-glossary(term: "Front-End")[front-end]], repose sur la #ref-glossary(term: "Bibliothèque de développement")[bibliothèque de développement] "lit-html", elle-même basée sur la nouvelle technologie des composants web en cours de normalisation par le "#acr("W3C")", organisme international régulateur des standards techniques liés au web. Il apporte un ensemble de composants graphiques utilisés afin de réduire le temps de développement des fonctionnalités tout en garantissant une cohérence graphique pour l'ensemble des applications développées par l'entreprise. -Suivefluid est conçu avec ces 2 frameworks mais la majeure partie de l'application repose sur le framework historique, alors qu'une partie plus minoritaire et plus récente de l'application côté #ref-glossary(term: "Front-end")[front-end] est développée avec le framework FullJS. Désormais, la volonté est de développer dès que possible les nouvelles fonctionnalités #ref-glossary(term: "Front-end")[front-end] de Suivefluid avec le framework FullJS. +Suivefluid est conçu avec ces 2 frameworks mais la majeure partie de l'application repose sur le framework historique, alors qu'une partie plus minoritaire et plus récente de l'application côté #ref-glossary(term: "#ref-glossary(term: "Front-End")[Front-end]")[#ref-glossary(term: "Front-End")[front-end]] est développée avec le framework FullJS. Désormais, la volonté est de développer dès que possible les nouvelles fonctionnalités #ref-glossary(term: "#ref-glossary(term: "Front-End")[Front-end]")[#ref-glossary(term: "Front-End")[front-end]] de Suivefluid avec le framework FullJS. #pagebreak(weak: true) = Cahier des charges