Travail pratique

ID : A09-TP06.2

But du TP

Prendre en main l'IDE IntelliJ IDEA
Se familiariser avec l'utilisation du système de gestion de versions Git et la plateforme de gestion de projets GitLab
Réaliser collaborativement un site web responsive avec HTML et CSS

Travail à réaliser

Projet

Mettez à jour votre branche main locale : elle contient maintenant les 9 pages personnelles de la partie 1 et les nouveaux modèles de la page d'un blog.
```
git switch main
git fetch
git rebase origin/main
```

Site web

Implémentez le menu déroulant Autres pages et le responsive design de votre page web en vous basant sur les modèles disponibles sous forme d'images dans le dossier /web/template/img :
- template-1000px-menu-open.png : desktop, avec le sous-menu Autres pages ouvert
- template-999px.png : tablette
- template-768px.png : smartphone paysage
- template-480px.png : smartphone portrait
- Les modèles sont aussi visibles dans le navigateur avec la page /web/template/index.html : réduisez la largeur de la fenêtre pour passer d'un modèle à l'autre.
- Travaillez dans une nouvelle branche feature (voir Workflow Git).
Adaptez les styles des textes afin d'utiliser l'unité rem (voir Font size).
Adaptez les images de votre page à la densité de pixels de l'écran (voir Images et densité de pixels).

Spécifications

Votre page de la partie 1 correspond au modèle desktop : complétez-la avec des media queries (approche Desktop First).
Les breakpoints sont :
- Desktop : ≥1000px
- Tablette : ≤999px et ≥769px
- Smartphone paysage : ≤768px et ≥481px
- Smartphone portrait : ≤480px
Aucune barre de défilement horizontale ne doit apparaître en dessous de 1000px de largeur.
Testez chaque breakpoint avec le mode responsive des outils de développement du navigateur (F12).
Toutes les tailles de texte de la partie 1 (14px, 20px, 22px et 24px) sont exprimées en rem.
- Avec la taille de police par défaut du navigateur (16 pixels), le rendu reste identique au modèle.
- Si l'utilisateur augmente la taille de police par défaut dans les paramètres de son navigateur, les textes s'agrandissent.

Images

La photo de profil et les images des articles existent chacune en deux versions au format WebP, proposées au navigateur avec l'attribut srcset et les descripteurs 1x et 2x (l'attribut src contient la version 1x) :
- Photo de profil : 160×160 pixels (1x) et 320×320 pixels (2x)
- Images des articles : au moins 700 pixels de large (1x, assez pour l'image la plus large, affichée sur toute la largeur de l'article en tablette) et le double (2x)
- Nommez la version 2x comme la version 1x, suivie de -2x (ex. post-1.webp et post-1-2x.webp).
Vérifiez avec les outils de développement que le navigateur télécharge la bonne version : en mode responsive, réglez le DPR (Device Pixel Ratio) à 1, puis à 2, et contrôlez le fichier chargé dans l'onglet Network.

Menu `Autres pages`

Le menu Autres pages affiche un sous-menu déroulant, au passage de la souris ou en appuyant dessus depuis un écran tactile (Android et iOS).
Ce sous-menu contient des liens vers les pages des 8 autres personnes de la classe (sauf le template et la page web affichée), au format Nom Prénom et dans l'ordre alphabétique des noms de famille, comme la liste des blogs de la page d'accueil.
Ce sous-menu doit être réalisé en CSS.
Chaque case du sous-menu doit être entièrement cliquable (pas juste le texte).
La souris doit afficher le curseur pointer sur tous les éléments cliquables du menu et sous-menu.
La bordure de chaque entrée du sous-menu est de 1px avec la couleur #e2e2e2.
Chaque entrée du sous-menu a un padding de 10px.
Le texte des entrées du sous-menu est #777 et la couleur de fond est #fff.
Toutes les entrées du sous-menu ont un effet de survol (hover) qui met le texte en noir #000 et la couleur de fond à #f0f0f0.
Le sous-menu est aussi utilisable au clavier, pour les personnes qui ne peuvent pas utiliser de souris :
- Avec la touche Tab, le focus passe sur Autres pages, ce qui ouvre le sous-menu, puis sur chacun de ses liens. Le sous-menu se referme quand le focus le quitte.
- Utilisez la pseudo-classe :focus-within : elle s'applique à un élément quand lui-même ou l'un de ses descendants a le focus.
- Testez dans Chrome ou Firefox, en cliquant dans la barre d'adresse, puis en appuyant plusieurs fois sur Tab (et Shift + Tab pour revenir en arrière).

Workflow Git

Comme pour la partie 1, utilisez le Feature Branch Workflow : chaque page personnelle est modifiée dans sa propre branche, puis intégrée à la branche main par une merge request (MR) relue par une autre personne.

Respectez l'ensemble des règles, vues en cours, relatives aux messages de commit, aux conventions de nommage des branches et à la numérotation des versions.
La branche main est protégée : personne ne peut y faire de push, elle n'est modifiée que par la fusion d'une MR sur GitLab.
Une MR ne peut être fusionnée qu'après avoir été approuvée par une autre personne que son auteur (voir Approbation obligatoire).
Le projet utilise la méthode de fusion "Merge commit with semi-linear history" : une MR ne peut être fusionnée que si sa branche est à jour par rapport à main (voir Méthodes de fusion dans GitLab).

Organisation

Classez les 9 personnes de la classe par ordre alphabétique des noms de famille.
Chaque personne relit la MR de la personne qui la précède dans cette liste (la première relit la MR de la dernière) : ce n'est pas la même personne que pour la partie 1.
Choisissez ensemble la personne responsable de la release 0.7.0 (voir Release ci-dessous), une autre personne que pour la release 0.5.0, et communiquez votre choix sur le canal Teams du cours au plus tard le jeudi 12 novembre à 13h.
- La MR de la release est relue et approuvée par les 8 autres personnes : chacune vérifie que sa ligne figure correctement dans le changelog.

Votre page personnelle

Depuis votre branche main à jour, créez votre branche feature (ex. feature/rwd-joel.dacomo) :
```
git switch -c feature/rwd-joel.dacomo
```
Réalisez le travail dans cette branche, avec des commits réguliers, et envoyez la branche sur origin dès les premiers commits (git push -u origin feature/rwd-joel.dacomo).
Dans la même branche, une fois le travail terminé, ajoutez une ligne pour votre page dans la section ## [Unreleased] du fichier CHANGELOG.md (voir Changelog).
Sur GitLab, créez une merge request de votre branche vers main :
- Titre clair et description de votre travail : la description est pré-remplie par le modèle de MR du projet, complétez-la et cochez chaque contrôle effectué.
- Personne qui relit votre MR dans le champ Reviewer.
- Option de suppression de la branche source après la fusion cochée, sans regrouper les commits (squash).
Corrigez votre travail selon les commentaires de la relecture, dans de nouveaux commits sur la même branche, puis push : la MR se met à jour automatiquement.
Quand GitLab indique que votre branche n'est plus à jour par rapport à main (une autre MR a été fusionnée entre-temps), mettez-la à jour avec un rebase (voir Mettre à jour la branche) :
```
git fetch
git rebase origin/main
git push --force-with-lease
```
- Toutes les MR modifient la section [Unreleased] de CHANGELOG.md : des conflits sont attendus. Résolvez-les en gardant les lignes des autres et la vôtre.
Après la fusion, nettoyez votre dépôt local (voir Nettoyer).

Relecture de la MR d'une autre personne

Récupérez la branche de la MR et testez la page dans votre navigateur (git fetch, puis git switch feature/rwd-<prénom.nom>).
Contrôlez les points suivants :
- La page respecte les spécifications de ce document et les modèles, à chaque breakpoint (mode responsive des outils de développement)
- Le sous-menu Autres pages fonctionne à la souris, en mode tactile (outils de développement) et au clavier (touche Tab)
- Les versions 1x et 2x des images ont les bonnes dimensions et le navigateur charge la version adaptée au DPR
- Le code HTML et CSS respecte le code style, sans erreur signalée par Stylelint, le Nu Html Checker et le CSS Validation Service
- Seuls le dossier personnel de l'auteur et sa ligne dans CHANGELOG.md sont modifiés (onglet Changes de la MR)
- Les messages de commit respectent les règles vues en cours
Laissez au moins un commentaire dans la MR (correction demandée, question ou remarque), sur la ligne concernée.
Une fois les corrections faites et toutes les discussions résolues, approuvez la MR (Approve), puis fusionnez-la (Merge) : GitLab bloque la fusion tant que la MR n'a pas été approuvée.
- Si GitLab bloque la fusion parce que la branche n'est pas à jour, demandez à l'auteur de faire le rebase (étape 6 ci-dessus). N'utilisez pas vous-même le bouton Rebase : les commits réécrits seraient enregistrés à votre nom (committer) et GitLab ne vous autoriserait plus à approuver la MR.

Release

Dès que la 9e et dernière MR des pages personnelles est fusionnée, la personne responsable de la release publie la version 0.7.0, au plus tard le jeudi 12 novembre à 23h59 :

Depuis la branche main à jour, créez la branche release/0.7.0.
Dans CHANGELOG.md, transformez la section ## [Unreleased] en section ## [0.7.0] - <date du jour> (date au format AAAA-MM-JJ), ajoutez une nouvelle section ## [Unreleased] vide au-dessus, faites un commit et push la branche.
Créez une MR vers main et indiquez les 8 autres personnes dans le champ Reviewer.
- Les contrôles du modèle de MR concernent les pages personnelles : remplacez-les par un résumé de la version.
- Chaque personne vérifie la MR, en particulier sa ligne dans le changelog, puis l'approuve (Approve).
- Fusionnez-la vous-même (Merge) uniquement une fois qu'elle a été approuvée par les 8 autres personnes (liste Approved by de la MR).
- Une seule approbation manquante bloque la release : assurez-vous que chacun est disponible pour l'approuver avant l'échéance.
Après la fusion, créez le tag annoté v0.7.0 sur le dernier commit de main et envoyez-le sur origin (voir Tags).
Sur GitLab, créez la release v0.7.0 à partir de ce tag (Deploy → Releases → New release), avec les notes de version reprises du changelog.

A la fin du travail pratique, seule la branche main doit exister sur origin (plus de branches feature ou release), avec le tag v0.7.0 et la release GitLab correspondante.

🚨 Aucun merge local dans main : toutes les fusions se font sur GitLab, par une merge request relue.

Evitez de faire un pull afin de ne pas générer de merge inutile : utilisez fetch puis rebase.
Le push forcé (git push --force-with-lease) est autorisé uniquement sur votre propre branche feature, après un rebase. Jamais sur une branche sur laquelle quelqu'un d'autre travaille.
Utilisez "interactive rebase" pour repositionner, modifier ou arranger vos commits dans votre branche feature, si besoin, de préférence avant de demander la relecture.
Pour corriger une erreur ou un oubli dans le code déjà fusionné dans main, créez une branche fix/… depuis main et une nouvelle MR (voir Corrections).
Organisez-vous entre vous pour que tout soit terminé à temps : relectures, corrections, rebase, fusions et release prennent du temps. Ouvrez votre MR (éventuellement en brouillon) dès que possible.

Mise en production

Déployez la dernière version du site web (le dossier /web du projet) sur votre serveur de production (VPS) avec l'URL https://tp06.apiXX.isc.heia-fr.ch (remplacez XX par le numéro de votre serveur personnel).
- La page d'accueil de nginx doit bien évidemment rester accessible avec l'URL https://apiXX.isc.heia-fr.ch.
- Le site web fait avec MkDocs doit aussi rester accessible avec l'URL https://tp05.apiXX.isc.heia-fr.ch.
- Par "dernière version du site web", on entend la version 0.7.0 (tag v0.7.0 de la branche main), avec les 9 pages personnelles du blog.

Lighthouse

Lighthouse est l'outil d'analyse de pages web intégré à Chrome (onglet Lighthouse des outils de développement). Il attribue à la page un score de 0 à 100 par catégorie : rouge de 0 à 49, orange de 50 à 89, vert de 90 à 100.

Votre page de blog personnelle, en production sur votre VPS (https://tp06.apiXX.isc.heia-fr.ch/<prénom.nom>/), obtient un score vert (de 90 à 100) dans chacune des 4 catégories Performance, Accessibility, Best Practices et SEO.
- Lancez l'analyse en mode Navigation, avec l'appareil Mobile, dans une fenêtre de navigation privée (les extensions du navigateur faussent les résultats).
- La catégorie expérimentale Agentic Browsing, si elle est affichée, n'est pas concernée (elle ne donne pas de score de 0 à 100).
- Le score de la catégorie Performance varie d'une analyse à l'autre : lancez-la plusieurs fois.
Analysez votre page en local avant de demander la relecture de votre MR, et corrigez les problèmes signalés : après la release, une correction du code demande une nouvelle MR et une nouvelle version.
- En production, d'autres problèmes peuvent apparaître (ex. erreurs dans la console dues à la CSP de votre serveur) : corrigez-les dans la configuration de nginx, sans modifier le code du site.
- La couleur #777 imposée par le modèle est signalée comme contraste insuffisant : gardez-la, le score vert reste atteignable.

Source : Chrome for Developers - How Lighthouse calculates your overall Performance score

Rendu du TP

Aucun rapport, manuel ou documentation n'est demandé pour ce travail pratique.

Echéances :

Jeudi 12 novembre à 13h : le nom de la personne responsable de la release est communiqué sur le canal Teams du cours.
Jeudi 12 novembre à 23h59 : toutes les MR sont fusionnées et la version 0.7.0 est publiée (tag v0.7.0 et release GitLab) par la personne responsable de la release.
Vendredi 13 novembre à 23h59 : chaque personne a mis en ligne la version 0.7.0 du site web sur son VPS.

Le TP sera évalué, entre autres, sur les critères suivants :

Respect de toutes les consignes de ce document
Utilisation correcte du Feature Branch Workflow (branche, merge request, mise à jour par rebase, fusion sur GitLab)
Relecture de la MR d'une autre personne : commentaires pertinents, approbation et fusion
Commits respectant les règles vues ensemble
Mises à jour correctes et pertinentes du changelog
Numérotation correcte des versions, tag et release GitLab
Disponibilité de la dernière version du site web sur votre VPS
Code source de qualité respectant tous les thèmes vus durant le cours
Résultat visuel identique ou le plus proche possible des modèles