Git

Toute la branche feature sera ainsi déplacée sur la pointe de la branche master, et tous les nouveaux commits seront intégrés à master.

Rebase consiste à réécrire l'historique du projet en créant de nouveaux commits pour chaque commit de la branche d'origine.

git rebase -i HEAD~3 : Vous devez indiquer jusqu'à quand remonter dans votre historique en donnant à la commande le *commit* sur lequel vous voulez vous rebase

Un nouveau « commit de merge » est créé dans la branche feature. Il relie les historiques des deux branches.

Je m'appelle XXXX et je suis un développeur Full Stack spécialisé dans les technologies Angular, React et Node.js. Avec 11 ans d'expérience en développement, j'ai travaillé sur une variété de projets passionnants et stimulants.

Tout 'abord je vais commencer par ma mission actuelle

Plus récemment, j'ai travaillé chez MesDocteurs en tant que développeur Full Stack. J'ai participé au développement d'une application de téléconsultation en ligne qui a permis de mettre en relation les patients avec les professionnels de santé. Dans ce projet, je travaille avec une équipe Agile y a un Scrum Master, un Product Owner, un Lead Dev, un Designer et des Ops. Nous avons suivi la méthodologie Scrum avec des sprints de 2 semaines. Et 6 développeurs full-stack pour travailler sur ce projet.

J'ai été impliqué dans le développement d'un module de rendez-vous pour cette application. Ce module permet aux patients de prendre des rendez-vous en ligne selon les disponibilités des praticiens, qu'ils soient programmés ou non programmés. Pour les rendez-vous programmés, les patients peuvent se connecter à l'application et choisir un créneau horaire qui convient à leur emploi du temps. Pour les consultations d'urgence, nous avons développé un système dédié.

Ensuite , j'ai fait la mise en place un module de paiement en ligne en utilisant Stripe, ce qui a permis une gestion plus efficace et sécurisée des transactions.

Ensuite, j'ai participé à l'intégration de l'application IoT développée en Angular 14 par notre partenaire Tessan, couplée avec l'application MesDocteurs existante. Cette intégration permettrait de diagnostiquer les patients en temps réel pendant la téléconsultation, par exemple en prenant leur température ou leur tension artérielle.

J'ai participé aussi au découpage des tâches et à leur estimation pendant les réunions de planification de sprint.

Pour l'architecture du projet côté Frontend :

Nous avons opté pour une architecture orientée Micro-frontend, car elle offre une modularité et une meilleure gestion de la complexité. Comme nous utilisons deux technologies différentes, React pour la partie RDV et Angular pour l'objet connecté, permet de répondre aux besoins métier spécifiques de l'application car le but est de fusionner les deux application en une seule application

nous avons mis en place des composants partagés pour garantir une Cohérence visuelle(une expérience utilisateur homogène sur l'ensemble de l'application).

Maintenance facilitée (Les développeurs peuvent apporter des modifications à un composant partagé, qui seront automatiquement appliquées à toutes les instances de ce composant dans l'ensemble de l'application).

Réutilisation des composants : Les composants partagés peuvent être réutilisés dans plusieurs projets et applications

Pour assurer la sécurité de l'application, nous avons utilisé un système d'authentification et d'autorisation. Dans React, nous avons créé un hook permettant de contrôler si l'utilisateur est autorisé ou non pour effectuer certaines actions. En Angular, il existe déjà un composant qui gère cela avec les guards tels que CanActivate ou Deactivate.

nous utilisons JWT en tant qu'en-tête de chaque appel de requête pour renforcer la sécurité de l'application.

nous utilisons aussi le système OTP (one time password) pour renforcer la sécurité au niveau

En ce qui concerne l'architecture backend de notre projet, nous avons opté pour une approche orientée microservices et tous les services sont développés avec Nest JS c'est le framework de Node JS et avons utilisé le clean architecture en appliquant les principes de SOLID et de KISS, DRY. Pour communiquer ou exposer notre api, nous avons aussi utilisé des API REST comme style architectural sécurisées via JWT .

Pour améliorer la performance de l'application, nous avons utilisé le redis, au lieu de charger les données à base de données physiques.

Pour mapper avec la base de donnée, nous utilisons TypeORM, ce qui facilite les mappages et garantit la sécurité contre les injections SQL et les failles de sécurité. Notre base de donnée en PostgreSql

Nous utilisons aussi TypeScript pour le développement tant côté front-end que back-end, ce qui nous permet d'avoir un code robuste, une meilleure lisibilité et un typage fort.

Pour le test; nous utilisons les librairies Jest, Jasmine pour Angular et React Library testing pour react

Et notre application sont dockernisé par le docker

Nous utilisons le système de versioning Git

Ça dépend de la convention d'équipe.

Personnellement, pour une feature branch, j'aime bien rebase avant la merge request pour garder un historique propre.

Ensuite, au moment de merger, le squash est souvent pratique si les commits intermédiaires n'apportent pas de valeur.

Mais sur des projets où l'historique détaillé est important, on peut conserver les commits.

Merge conserve l'historique réel des branches. Il crée souvent un commit de merge.

Rebase rejoue mes commits au-dessus de la branche cible. Cela donne un historique plus linéaire.

cherry-pick permet de récupérer un commit précis d'une branche vers une autre.

Par exemple, si un fix urgent est dans une branche feature mais doit partir rapidement en production, je peux cherry-pick uniquement ce commit vers une branche de hotfix.

Pour moi, une bonne MR doit être facile à comprendre.

Je mets :

• le contexte ;
• ce qui a été modifié ;
• comment tester ;
• les impacts techniques ;
• les captures si UI ;
• les points de vigilance.

Je vérifie aussi :

• lint OK ;
• tests OK ;
• pas de console.log ;
• pas de code mort ;
• pas de changement hors scope.

Une MR propre fait gagner du temps à toute l'équipe.

Sur mes dernières missions, on a une organisation avec trois branches principales :

• main pour la production ;
• develop pour les développements ;
• integration pour les validations.

Chaque fonctionnalité était développée sur une branche dédiée créée depuis develop.

Après revue de code et validation de la CI, elle était fusionnée sur develop.

Lorsque plusieurs fonctionnalités étaient prêtes, elles étaient promues sur integration pour les tests QA et métier.

Une fois validées, elles étaient fusionnées sur main, puis la mise en production était déclenchée manuellement via notre pipeline GitLab.

Pour un correctif critique ou hotfix en prod, on repartit de main, puis on reporte le correctif sur develop et integration.