update some content
This commit is contained in:
parent
a713c7d0c8
commit
2c8a042aa2
@ -45,15 +45,15 @@ En ouvrant les détails de l'objet, on peut retrouver un onglet regroupant les i
|
||||
|
||||
D'autres onglets permettent de retrouver des informations plus précises telles que les observations de l'ouvrage, des graphiques sur l'évolution de l'ouvrage dans le temps, visualiser l'ouvrage en 3D (si fourni par le client)…
|
||||
|
||||
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.
|
||||
Chaque ouvrage appartient à un canton nommé dataowner, 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 #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 #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.
|
||||
Le second tiers de l'application correspond à l'#ref-glossary(term: "API")[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 #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.
|
||||
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] #ref-glossary(term: "EF")[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é #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 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 TypeScript, un language surrensemble de JS et 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 #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.
|
||||
|
||||
@ -69,9 +69,9 @@ Le schéma @three-tier-archi-diagram ci-dessous représente les trois tiers de l
|
||||
|
||||
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
|
||||
=== Présentation de #ref-glossary(term: "PostgreSQL")[PostgreSQL]
|
||||
|
||||
#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.
|
||||
#ref-glossary(term: "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.
|
||||
|
||||
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].
|
||||
|
||||
@ -79,7 +79,7 @@ L'une des forces majeures de ce système est d'être Open Source, ce qui signifi
|
||||
|
||||
=== Les principes de base
|
||||
|
||||
Comme dit précédemment, #ref-glossary(term: "PostgreSQL")[PostgreSQL]est un SGBDR. Il utilise le langage SQL#footnote("Structured Query Language")<SQL_def> 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 #ref-glossary(term: "SGBDR")[SGBDR]. Il utilise le langage SQL#footnote("Structured Query Language")<SQL_def> 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.
|
||||
@ -94,9 +94,9 @@ Comme dit précédemment, #ref-glossary(term: "PostgreSQL")[PostgreSQL]est un SG
|
||||
- Des notions de concurrence et d'isolation
|
||||
- De la réplication et du #ref-glossary(term: "Sharding")[Sharding].
|
||||
|
||||
=== Les avantages de PostgreSQL
|
||||
=== Les avantages de #ref-glossary(term: "PostgreSQL")[PostgreSQL]
|
||||
|
||||
#ref-glossary(term: "PostgreSQL")[PostgreSQL]est un SGBDR très populaire pour plusieurs raisons :
|
||||
#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un #ref-glossary(term: "SGBDR")[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.
|
||||
@ -110,13 +110,15 @@ En type de fichiers volumineux, on peut par exemple citer les fichiers MAJICS, R
|
||||
=== Les inconvénients de #ref-glossary(term: "PostgreSQL")[PostgreSQL]
|
||||
|
||||
#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).
|
||||
- Il peut être plus complexe à installer et à configurer que d'autres #ref-glossary(term: "SGBDR")[SGBDR], tels que MySQL ou SQLite.
|
||||
- Il peut nécessiter plus de ressources matérielles (mémoire, CPU, espace disque) que d'autres #ref-glossary(term: "SGBDR")[SGBDR] pour fonctionner de manière optimale.
|
||||
- Il peut être moins performant que d'autres #ref-glossary(term: "SGBDR")[SGBDR] pour certaines tâches spécifiques, telles que les requêtes de type OLAP (Online Analytical Processing).
|
||||
|
||||
=== Conclusion
|
||||
|
||||
#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.
|
||||
#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un #ref-glossary(term: "SGBDR")[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, #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
|
||||
@ -127,7 +129,7 @@ Par exemple, dans le cas où Google déploierait des changements de code majeurs
|
||||
|
||||
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, #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.
|
||||
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 #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.
|
||||
@ -143,7 +145,7 @@ Pour faire une migration de base de données, il existe de nombreuses solutions,
|
||||
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 #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).
|
||||
Microsoft propose sa solution alternative SSMA pour importer les types de bases Access, DB2, MySQL, Oracle, SAP ASE vers leurs différents #ref-glossary(term: "SGBDR")[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 #ref-glossary(term: "PostgreSQL")[PostgreSQL].
|
||||
|
||||
Les principaux désavantages de ce genre de solutions sont :
|
||||
@ -175,4 +177,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 SGBDR au sein de l'application InfSuite.
|
||||
Je peux maintenant m'intéresser à la place de ce #ref-glossary(term: "SGBDR")[SGBDR] au sein de l'application InfSuite.
|
@ -5,19 +5,19 @@
|
||||
|
||||
== Introduction
|
||||
|
||||
Je présente dans cette section le travail réalisé durant les neuf mois au sein de l'entreprise Unit Solutions. Portant sur le sujet d'une migration de base de données dans le but de maintenir les technologies de l'application à jour, je présente tout d'abord les différents éléments qui justifient le choix d'effectuer cette migration de base de données, par la suite, j'expose l'analyse préliminaire réalisée pour s'assurer que la migration reste pertinente, j'aborde plus tard les changements réalisés dans le code et enfin, je présente les résultats obtenus post-migration.
|
||||
Je présente dans cette section le travail réalisé durant les neuf mois au sein de l'entreprise Unit Solutions. Portant sur le sujet d'une migration de base de données dans le but de maintenir les technologies de l'application à jour, je présente tout d'abord les différents éléments qui justifient le choix d'effectuer cette migration de base de données. Par la suite, j'expose l'analyse préliminaire réalisée pour s'assurer que la migration reste pertinente. J'aborde plus tard les changements réalisés dans le code et enfin, je présente les résultats obtenus post-migration.
|
||||
|
||||
== 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, #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.
|
||||
Lorsque le sujet de mettre à jour le #ref-glossary(term: "SGBDR")[SGBDR] a été présenté, il n'a pas été décidé de remplacer #ref-glossary(term: "PostgreSQL")[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 #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.
|
||||
Maintenir #ref-glossary(term: "PostgreSQL")[PostgreSQL] en tant que #ref-glossary(term: "SGBDR")[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 #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.
|
||||
|
||||
Si deux utilisateurs récupèrent la même version d'un document, qu'ils effectuent tous deux des mises à jour sur ce document, que l'utilisateur A sauvegarde ses changements en premier, que l'utilisateur B essaye de sauvegarder a son tour le document avec ses changements, alors le serveur lui signalera qu'il ne possède pas la dernière version du document, qu'il a été modifiée entre-temps et donc qu'il ne peut pas sauvegarder ses modifications sans mettre à jour la version de son document.
|
||||
Si deux utilisateurs récupèrent la même version d'un document, qu'ils effectuent tous deux des mises à jour sur ce document, que l'utilisateur A sauvegarde ses changements en premier, que l'utilisateur B essaye de sauvegarder à son tour le document avec ses changements, alors le serveur lui signalera qu'il ne possède pas la dernière version du document, qu'il a été modifié entre-temps et donc qu'il ne peut pas sauvegarder ses modifications sans mettre à jour la version de son document.
|
||||
|
||||
Pour assurer ce suivi de version, le document contient une version en base, qui est un timestamp sans fuseau horaire. Un problème peut alors apparaître si deux utilisateurs, sur des fuseaux horaires différents, effectuent des modifications au même instant.
|
||||
|
||||
@ -27,16 +27,16 @@ Dans le schéma @file-versionning-schema, deux utilisateurs génèrent des versi
|
||||
|
||||
#figure(
|
||||
image("../assets/images/file-versionning.png"),
|
||||
caption: [Schéma d'un conflit de version entre deux version d'un document]
|
||||
caption: [Schéma d'un conflit de version entre deux versions d'un document]
|
||||
)<file-versionning-schema>
|
||||
|
||||
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.
|
||||
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] #ref-glossary(term: "PostgreSQL")[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, #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 #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 #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.
|
||||
Dans le cas de la base #ref-glossary(term: "PostgreSQL")[PostgreSQL], elle est aussi utilisée pour le système d'information #ref-glossary(term: "GIS")[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 #ref-glossary(term: "SGBDR")[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.
|
||||
|
||||
@ -64,11 +64,11 @@ Les sous-solutions d'un projet sont des solutions indépendantes intégrées au
|
||||
|
||||
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: "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: "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.
|
||||
|
||||
#figure(
|
||||
image("../assets/images/ik-webapi-dependencies.png"),
|
||||
caption: [Arbre de dépendances du projet Web#ref-glossary(term: "API")[Api ]d'InfSuite]
|
||||
caption: [Arbre de dépendances du projet Web#ref-glossary(term: "API")[API] d'InfSuite]
|
||||
)<ik-webapi-dependencies>
|
||||
|
||||
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.
|
||||
@ -92,7 +92,7 @@ L'objectif de ce système est d'avoir une base de tests sur laquelle je peux m'a
|
||||
|
||||
Avec la validation obtenue précédemment sur la compatibilité des deux systèmes, j'ai pu valider, toujours avec l'approbation de mon chef de projet et de l'architecte d'application, que la migration la plus adaptée dans notre cas serait une migration hybride.
|
||||
|
||||
Le but de la migration hybride est de combiner deux types de migration de données que j'ai pu citer précédemment dans ce document. Comme je veux ajouter un fuseau horaire aux horodatages qui servent de versions, je dois modifier les données de la base source. Cependant, cela implique de modifier les données et les modèles de données associés.
|
||||
Le but de la migration hybride est de combiner deux types de migration de données que j'ai pu citer préalablement dans ce document. Comme je veux ajouter un fuseau horaire aux horodatages qui servent de versions, je dois modifier les données de la base source. Cependant, cela implique de modifier les données et les modèles de données associés.
|
||||
|
||||
Pour éviter de devoir utiliser un logiciel tel que PgAdmin et de passer du temps à manipuler le modèle de données qui pourrait causer des problèmes, je préfère utiliser des outils bien maîtrisés et intégrés sur le projet InfSuite.
|
||||
|
||||
@ -104,19 +104,20 @@ Pour l'exemple des horodatages, je rédige un script SQL que je pourrais exécut
|
||||
|
||||
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")[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].
|
||||
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].\
|
||||
Il faut bien différencier #ref-glossary(term: "EF")[EntityFramework] qui n'est plus activement développé, de son successeur #ref-glossary(term: "EF")[EntityFramework]Core qui offre de nouvelles fonctionnalités qui ne seront plus implémentées dans #ref-glossary(term: "EF")[EntityFramework].
|
||||
|
||||
#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.
|
||||
#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 #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")[EntityFramework] é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] 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.
|
||||
|
||||
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.
|
||||
|
||||
Si on souhaite passer sur la nouvelle version du paquet Npgsql, la version 8.X.X, il n'y a pas d'autre choix que de passer d'EF à EFCore. Faire le choix de mettre à jour l'application EFCore permettrait de compléter l'objectif de maintenir l'application à jour et saine. En effet, pour rappel, EF n'est maintenant plus mis à jour régulièrement.
|
||||
Si on souhaite passer sur la nouvelle version du paquet Npgsql, la version 8.X.X, il n'y a pas d'autre choix que de passer d'#ref-glossary(term: "EF")[EF] à #ref-glossary(term: "EF")[EF]Core. Faire le choix de mettre à jour l'application #ref-glossary(term: "EF")[EF]Core permettrait de compléter l'objectif de maintenir l'application à jour et saine. En effet, pour rappel, #ref-glossary(term: "EF")[EF] n'est maintenant plus mis à jour régulièrement.
|
||||
|
||||
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.
|
||||
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'#ref-glossary(term: "EF")[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 #ref-glossary(term: "PostgreSQL")[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 #ref-glossary(term: "EF")[EF], 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"),
|
||||
@ -137,7 +138,7 @@ Il est possible de créer des règles avec chaque propriété d'un objet d'infra
|
||||
É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 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 #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.
|
||||
|
||||
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.
|
||||
|
||||
@ -165,6 +166,7 @@ J'obtiens dans les données les informations d'identification des groupes testé
|
||||
Pour comparer les performances de la base, je commence par récupérer les données globales des deux bases, à savoir le nombre total d'objets d'infrastructures qui ont étés traités et le temps global d'exécution de traitement. Pour connaître le temps total qu'a mis la base pour traiter tous les groupes, j'utilise la requête ``` =SUM(pg14[Load_Duration_In_Ms])``` qui fait une simple somme de tous les résultats de la colonne ``` Load_Duration_In_Ms```. Je fais la même chose pour les résultats des deux bases et pour la colonne ``` Count_Ios``` que je réutilise avec un simple calcul de différence dans la requête ``` =Total_Ios_Count_14 - Total_Ios_Count_16```. Comme le présente le tableau des résultats @result_sheet_benchmark_1, les données dans la base de production ont déjà changées, il faut donc que je tienne compte dans mes résultats.
|
||||
|
||||
#figure(
|
||||
caption: "Comparatif brut des performances entre les deux bases",
|
||||
table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: horizon,
|
||||
@ -180,14 +182,15 @@ Structure du tableau de résultats:
|
||||
- La colonne *``` Gap_From_14_To_16```* contient les résultats des comparaisons des données obtenues entre Postgres 14 et Postgres 16.
|
||||
- La ligne *``` Total_Io_Count```* indique le nombre total d'objets d'infrastructures qui ont été filtrés par les différents groupes traités.
|
||||
- La ligne *``` Total_Duration```* indique le temps total de traitement (en millisecondes) de tous les groupes.
|
||||
- La ligne *``` Identical_Ios_Duration```* indique le temps de traitement total (en millisecondes) uniquement pour les OIs identiques entre les deux bases.
|
||||
- La ligne *``` Identical_Ios_Duration```* indique le temps de traitement total (en millisecondes) uniquement pour les #ref-glossary(term: "OIs")[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 avec lesquelles les groupes analysé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 pour 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.
|
||||
|
||||
#figure(
|
||||
caption: "Résultat des gains de performances entre PGSQL 14 et 16",
|
||||
table(
|
||||
columns: (auto, auto),
|
||||
align: horizon,
|
||||
@ -201,7 +204,7 @@ Comme je l'ai remarqué rapidement, le gain réel de performances entre les deux
|
||||
|
||||
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 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.
|
||||
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 tels 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
|
||||
@ -220,9 +223,9 @@ 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é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 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és 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, 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.\
|
||||
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 prend 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])<codebloc-dt-unspecified>
|
||||
@ -251,6 +254,7 @@ La mise en production étant un environnement sensible et n'ayant pas les compé
|
||||
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(
|
||||
caption: "Nouveau comparatif brut des performances entre les deux bases",
|
||||
table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: horizon,
|
||||
@ -262,9 +266,10 @@ Une fois le serveur de production mis à jour avec les nouveaux éléments, j'ef
|
||||
)
|
||||
)<result_sheet_benchmark_2>
|
||||
|
||||
Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas forcément de gros indices sur les différences par rapport à la première analyse comportant potentiellement un biais. Je constate une inversion sur la quantité de données traitées, cette fois-ci la nouvelle base de données à eu plus d'OIs à traiter et par conséquent les temps de traitements ont aussi augmenté. Une comparaison avancée me permet d'obtenir un comparatif plus explicite entre les deux bases.
|
||||
Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas forcément de gros indices sur les différences par rapport à la première analyse comportant potentiellement un biais. Je constate une inversion sur la quantité de données traitées, cette fois-ci la nouvelle base de données à eu plus d'#ref-glossary(term: "OIs")[OIs] à traiter et par conséquent les temps de traitements ont aussi augmenté. Une comparaison avancée me permet d'obtenir un comparatif plus explicite entre les deux bases.
|
||||
|
||||
#figure(
|
||||
caption: "Résultat des gains réels de performances entre PGSQL 14 et 16",
|
||||
table(
|
||||
columns: (auto, auto),
|
||||
align: horizon,
|
||||
@ -274,7 +279,7 @@ Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas fo
|
||||
)
|
||||
)<perf_gain_sheet_2>
|
||||
|
||||
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.
|
||||
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 #ref-glossary(term: "OIs")[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 #ref-glossary(term: "OIs")[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 #ref-glossary(term: "PostgreSQL")[PostgreSQL], mais surtout, de performances encore plus accrues que prévu par rapport à l'ancien système.
|
||||
|
||||
|
27
main.typ
27
main.typ
@ -10,33 +10,24 @@
|
||||
),
|
||||
degree: "Master informatique et mobilité",
|
||||
promotion: (title: "UHA 4.0.5", year: 2024),
|
||||
acronyms: (
|
||||
"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.],
|
||||
"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],
|
||||
"EF": [Entity Framework qui se décline également en Entity Framework Core, est une librairie #ref-glossary(term: "C#")[C\#] qui sert d'#ref-glossary(term: "ORM")[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.],
|
||||
"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.],
|
||||
"PostgreSQL": [Un #ref-glossary(term: "SGBDR")[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'#ref-glossary(term: "ORM")[ORM] Entity Framework.],
|
||||
"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.],
|
||||
"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.]
|
||||
"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.],
|
||||
"OIs": [Les objets d'infrastructures sont les données principales d'InSuite, ils peuvent représenter des ponts, des routes, des voies férrées,etc.]
|
||||
),
|
||||
hayagriva-bibliography: "bibliographie.yml",
|
||||
thanks: [
|
||||
@ -53,7 +44,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é à 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é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.
|
||||
|
||||
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.
|
||||
|
||||
@ -62,9 +53,9 @@ Dans ce document, je commencerai par présenter ce qui m'a amené à rejoindre l
|
||||
conclusion: [
|
||||
Pour conclure cette seconde année de master en alternance chez Unit Solutions, travailler sur un sujet étant aussi ancré dans le projet qu'est la base de données est d'une importance cruciale pour mon parcours académique et professionnel. Travailler sur la migration de base de données pour l'application InfSuite m'a permis de développer et d'approfondir des compétences essentielles en gestion de données et en technologies web.
|
||||
|
||||
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.
|
||||
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 #ref-glossary(term: "SGBDR")[SGBDR], etc.), m'a offert dans un premier temps une expérience 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 à 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 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.
|
||||
|
||||
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.
|
||||
|
||||
@ -74,7 +65,7 @@ Cette alternance, marquée par des défis techniques aussi bien sur l'apprentiss
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
@ -45,7 +45,7 @@
|
||||
"#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).],
|
||||
"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 #ref-glossary(term: "PostgreSQL")[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 (#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.],
|
||||
@ -185,9 +185,9 @@ En plus de leurs propres recherches personnelles (ressources en ligne, aide par
|
||||
|
||||
#formation-step[Alertes]
|
||||
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].\
|
||||
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 #ref-glossary(term: "PostgreSQL")[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 : #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. \
|
||||
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 #ref-glossary(term: "PostgreSQL")[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é.
|
||||
|
13
template.typ
13
template.typ
@ -11,7 +11,6 @@
|
||||
company: (),
|
||||
degree: "",
|
||||
promotion: (),
|
||||
acronyms: (),
|
||||
glossary: ( : ),
|
||||
hayagriva-bibliography: none,
|
||||
thanks: lorem(150),
|
||||
@ -117,7 +116,6 @@
|
||||
)
|
||||
set text(font: "Times New Roman", size: 12pt)
|
||||
set par(justify: true, leading: 0.8em)
|
||||
init-acronyms(acronyms)
|
||||
counter(page).update(1)
|
||||
|
||||
// Defining, how marked glossary entries in the document appear
|
||||
@ -199,17 +197,6 @@
|
||||
]
|
||||
pagebreak()
|
||||
|
||||
// Acronyms page.
|
||||
[
|
||||
= Liste des abréviations
|
||||
#acros.display(acronyms => {
|
||||
for acr in acronyms.keys().sorted() [
|
||||
- *#acr* : #acronyms.at(acr) \
|
||||
]
|
||||
})
|
||||
]
|
||||
pagebreak()
|
||||
|
||||
// Bibliography.
|
||||
bibliography(hayagriva-bibliography, title: "Bibliographie et webographie", style: "chicago-notes")
|
||||
pagebreak()
|
||||
|
Loading…
Reference in New Issue
Block a user