68 lines
10 KiB
Plaintext
68 lines
10 KiB
Plaintext
#import "../template.typ" : *
|
||
|
||
#pagebreak(weak: true)
|
||
= Réalisation
|
||
|
||
== 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.
|
||
|
||
== Pertinence et philosophie
|
||
|
||
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.\
|
||
Maintenir PostgreSQL en tant SGBDR de l'application écarte déjà un bon nombre de solutions niveau logiciel. Je peux dores et déjà abandonner les logiciels payants et long d'expertises 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é important de 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,...) alors, il créait 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 le document avec ses changements après que la version ait changé, alors le serveur lui signalera qu'il ne possède pas la dernière version du document qui a été modifiée 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.\
|
||
Le serveur ne pourra pas vérifier l'information de fuseau horaire puisqu'elle n'est pas sauvegardée en base et donc si l'utilisateur effectue une sauvegarde même avec une ancienne version du document, cette dernière écrasera les derniers changements.
|
||
|
||
Dans le schéma @file-versionning-schema, deux utilisateurs génèrent des versions de fichiers différentes. Un utilisateur enregistre ses changements en premier et génère la version ``` AB``` du document. Quand le second utilisateur souhaite enregistrer ses changements ``` C```, un conflit de fichier l'en empêche. ``` C``` a comme origine la version ``` A``` et non pas ``` AB```, l'utilisateur doit donc récupérer les changements de la version ``` AB``` avant d'enregistrer ses changements.
|
||
#figure(
|
||
image("../assets/images/file-versionning.png"),
|
||
caption: [Schéma d'un conflit de version entre deux version d'un document]
|
||
)<file-versionning-schema>
|
||
|
||
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.\
|
||
Je dois dans un premier temps chercher les technologies utilisées dans l'application et m'assurer que ces dernières soient compatibles avec la nouvelle base. Par la suite, je vais devoir valider la compatibilité entre la version de la base source et de la base cible. Avec cette confirmation, je pourrais alors chercher la meilleure manière d'effectuer cette migration parmi les différentes options disponibles que j'ai pu exposer précédemment.
|
||
|
||
=== Analyse préliminaire
|
||
|
||
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.
|
||
Il existe des packages alimentés par Microsoft par exemple comme .NET, #ref-glossary(term: "EF")[#display-def("EF")], ... et d'autres librairies qui sont elles développés 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 Nugget Packages dans l'écosystème 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.\
|
||
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.\
|
||
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é 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 lui 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 sont déjà relativement complexes.
|
||
|
||
#figure(
|
||
image("../assets/images/ik-webapi-dependencies.png"),
|
||
caption: [Arbre de dépendances du projet WebApi 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.
|
||
|
||
=== Compatibilité
|
||
|
||
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].\
|
||
#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 disponibles 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.
|
||
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.\
|
||
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.
|
||
|
||
=== Tests de performance
|
||
|
||
== Adaptation du code
|
||
|
||
== Résultats
|
||
|
||
=== Performances finales
|
||
|
||
=== Problèmes rencontrés |