This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

Retour Accueil

Dorian HODIN

Nombre d'heure total : ~120 heures

Écriture du rapport partie perso ( ~ 1 heure )

J'ai écrit ma partie personnelle sur le premier rendu de Gestion de Projet, ainsi que relu le rapport et corriger les fautes d'orthographes qui subsistaient encore.

Écriture du .drone.yml et du Dockerfile pour l'API (~ 15 heures)

J'ai écrit le .drone.yml permettant de faire plusieurs étapes avec la CI. Tout d'abord, ce fichier permet de déployer notre projet sur SonarQube, afin de pouvoir tester le projet et vérifier que le projet ne comportent pas de bugs, et de les corriger s'ils étaient présents dans l'application. SonarQube nous a aussi permis de détecter des failles de sécurité comme par exemple des mots de passe en clair ou des 'echo' oubliés dans le code.
Ensuite, le .drone.yml nous permet de déployer différents fichiers en ligne sur un container Docker qui tourne sur CodeFirst. Avec ce fichier j'ai donc fait en sorte qu'il déploie certain fichier correspondant à l'API qui était anciennement sur un repos commun au reste du code de l'application.
J'ai aussi utilisé la CI pour vérifier la syntaxe des fichiers PHP présents.
J'ai aussi déployé une base de données sur CodeFirst avec ce fichier, base de données qui stockera les différentes informations sur les formulaires.
J'ai écrit un Dockerfile permettant de choisir ce que je veux envoyer dans le container Docker présenté précédemment, et qui permet de réaliser différentes installations sur le container. Cette étape m'as pris du temps car je devais trouver quels drivers je devais installer sur le container afin de pouvoir faire tourner l'API. J'avais besoin des différents drivers pour PDO, et d'installer composer ainsi que tout les paquets du vendor au bon endroit. En effet, j'ai choisi de ne pas pousser le dossier vendor qui est le dossier générer par le composer afin d'éviter de pousser trop de fichier inutiles. A la place j'installe le dossier vendor avec des lignes de commandes directement dans le container avec le Dockerfile.

Première version de l'API (~ 30 heures)

Au début, j'ai commencé à faire l'API sans utiliser de framework, et en faisant moi-même mes différentes routes. J'ai donc, dans l'API, les différentes Gateways qui communiquent avec la base de données de CodeFirst et un fichier APIControler.php qui permet de gérer les appels de l'API. Cependant, je n'avais pas de gestion d'erreur, et les routes que je définissait était "bancale". Sans utiliser de framework, il était compliqué d'avoir une API optimisé, mais je ne voulais pas pour l'instant utiliser de framework, car je voulais d'abord me familiariser avec le déploiement d'une API et comment l'utiliser.
Durant ces heures j'ai donc coder des appels des Gateways depuis le fichier de l'API, comment récupère des données et comment envoyer du Json au client qui appelle l'API. Cependant, ces envois de Json était très mauvais, car je faisait uniquement des 'print(json_encode(...))' à la fin des Gateways que j’appelai dans l'API. Je me suis rapidement rendu compte que c'était une très mauvaise solution, je suis donc passé par un framework pour réalisé cette API.

Deuxième version de l'API (~ 45 heures)

Nous avions déjà commencé à avoir des cours sur les différents frameworks pour réaliser des API, seulement celui qui m’intéressait était prévu pour le dernier cours. Par conséquent, j'ai du apprendre seul grâce au cours fournis par notre prof et grâce à la doc en ligne comment utiliser le framework que j'avais choisi : PHP SLim. J'ai donc passer beaucoup de temps à vraiment comprendre l'API au lieu de bêtement recopier les exemples de code fournit par notre professeur.
Après avoir bien compris le fonctionnement de PHP Slim, j'ai commencé à coder l'API, en reprenant légèrement le code que j'avais fait avant, et j'ai créer une seule route qui permettait, grâce au nom de la méthode passé en paramètre de l'URL, de communiquer avec toute les Gateways. J'ai donc paramétrer cette route, j'ai du gérer les utilisations de namespace et de paquets en modifiant le composer.json de nombreuses fois avant de bien comprendre comment ce fichier marchait.
J'ai ensuite créer plusieurs exceptions personnalisées, afin d'indiquer au mieux les différentes exceptions que l'API peut renvoyer, comme des PDO exceptions si l'API n'arrive pas à se connecter, ou alors si on met un nom de méthode incorrect.
Après avoir presque fini, je me suis rendu compte que d'avoir qu'une seule route était vraiment une mauvaise idée. Déjà, je faisait du GET pour faire toute les actions, ce qui est mauvais. J'ai donc créer une trentaine de route différentes, chacune accédant à une méthode des Gateways différente. J'ai changé l'appel des méthodes avec l'API, passant du nom de la méthode en QueryParams comme cela : http://api?method=exempleMethod à l'appel via des vraies routes dans l'URL comme cela : http://api/exempleMethod
J'ai du aussi modifier la GatewayQuestion. En effet, cette Gateway faisait appel à des classes du code de l'application, l'API n'y avait donc pas accès. Vu que les seuls appels des classes était sur leur méthode getId() ou bien get_class(), j'ai donc changé ces appels par des paramètres à mettre en plus à l'appel de la Gateway.
Cependant, je n'ai pas encore réussi à accéder à mes routes en ligne, car je n'ai pas utilisé la bonne image dans le Dockerfile, et avec le nouvelle image j'ai du mal à prendre en main son fonctionnement.

Montage vidéo des différents témoignages ( ~ 10 heures)

J'ai aussi réalisé le montage vidéo des différents témoignages que nous avons réalisé.

Codage du côté client de l'API ( ~ 5 heures)

J'ai codé le côté client de l'API, c'est en cours donc plus de précision quand j'aurais finis

Implémentation des tests unitaires ( ~ 5 heures)

J'ai essayé d'ajouter des tests unitaires à SonarQube, mais je n'ai pas réussi à relier le fichier coverage.xml à SonarQube, afin qu'il puisse valider les tests.