Aller au contenu

Travail pratique

ID : A08-TP06.1

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 avec HTML et CSS

Travail à réaliser

Code style

Configurez les code styles pour HTML et CSS dans IntelliJ IDEA :

  1. Depuis l'écran d'accueil, cliquez sur Customize puis All settings….
    • Les réglages faits depuis l'écran d'accueil s'appliquent à tous les nouveaux projets.
    • Dans la liste Scheme, utilisez le schéma Default, enregistré au niveau de l'IDE et valable pour tous vos projets, plutôt que Project, enregistré dans le dossier .idea du projet.
  2. Configurez les divers paramètres relatifs aux code styles vus durant le cours sous Editor → Code Style → HTML et sous Editor → Code Style → Style Sheets → CSS.

Inspections du code

Configurez les inspections du code pour HTML et CSS dans IntelliJ IDEA :

  1. Depuis l'écran d'accueil, cliquez sur Customize puis All settings….
    • Dans la liste Profile, utilisez le profil Default, enregistré au niveau de l'IDE, plutôt que Project Default, enregistré dans le dossier .idea du projet.
  2. Configurez les diverses inspections du code relatives aux langages HTML et CSS sous Editor → Inspections.
    • Configurez tout ce qui peut vous être utile pour détecter les erreurs ou problèmes dans votre code source.
    • Apprenez à utiliser ces aides et testez-les.

Sources :

Projet

  1. Clonez le projet du travail pratique qui se trouve sur GitLab, puis ouvrez-le dans IntelliJ IDEA.
  2. Installez les dépendances du projet déclarées dans le fichier package.json (Prettier, Stylelint et ses extensions).

Prettier

Les réglages de Prettier dans IntelliJ IDEA sont propres à chaque projet : ceux du TP05.2 ne s'appliquent pas à ce nouveau projet.

  1. Configurez Prettier pour ce projet sous Languages & Frameworks → JavaScript → Prettier :
    • Automatic Prettier configuration → 🔘 : IntelliJ IDEA utilise le paquet prettier du dossier node_modules et la configuration du fichier .prettierrc.json du projet (option singleQuote: true).
    • Run for files: → ajoutez les extensions html et css au motif (ex. {**/*,*}.{html,css,md,json}).
    • Run on save → ✅
    • Run on paste → ✅
    • Prefer Prettier configuration to IDE code style → ✅

Source : JetBrains - IntelliJ IDEA (Prettier)

Stylelint

La configuration de Stylelint se trouve dans le fichier .stylelintrc.json du projet : configuration standard (stylelint-config-standard), vérification du CSS contenu dans les fichiers HTML (stylelint-config-html) et ordre alphabétique des propriétés (stylelint-order).

  1. Activez et configurez Stylelint dans IntelliJ IDEA pour ce projet sous Languages & Frameworks → Style Sheets → Stylelint :
    • Enable → ✅
    • Stylelint package: → le paquet stylelint du dossier node_modules du projet (normalement détecté automatiquement).
    • Run for files: → {**/*,*}.{css,html} : par défaut, Stylelint ne vérifie que les fichiers CSS, et avec html, il vérifie aussi le code CSS des fichiers HTML (ex. élément <style>).
    • Run stylelint --fix on save → ✅
  2. Testez la configuration : dans une feuille de style, écrivez une déclaration qui ne respecte pas les règles du cours (ex. margin: 0px; ou color: #FFFFFF;), puis vérifiez que Stylelint la signale ou la corrige à l'enregistrement.

Site web

  1. Implémentez une page web en vous basant sur le modèle template.png, disponible sous forme d'image dans le dossier /web/template/img (aussi visible dans le navigateur avec la page /web/template/index.html).
    • Le but est que votre page web, avec un contenu personnalisé, soit identique (ou le plus proche possible) au modèle en termes de présentation, disposition, agencement, etc.
    • Travaillez dans votre propre branche feature (voir Workflow Git).

Spécifications

  • La police de caractères à utiliser est Lato.
    • Utilisez le service Google Fonts pour l'intégrer à votre page web : copiez le code d'intégration (embed code) proposé pour l'élément HTML <link> (et non pour @import).
    • Sélectionnez les graisses nécessaires uniquement.
    • Tous les titres sont en gras (niveau de graisse : 700).
    • Les paragraphes de texte dans les articles et dans la biographie ont une hauteur de ligne de 145% (1.45).
  • Le contenu de la page a une largeur fixe de 1000px, marges intérieures (padding) comprises, et il est centré horizontalement : si la fenêtre est plus étroite, le navigateur affiche une barre de défilement horizontale.
  • Le lien Accueil (en haut, à droite) permet de revenir sur la page d'accueil du site web (/web/index.html).
  • Pour le moment, Autres pages est un menu sans utilité mais avec un effet de survol qui met le texte en noir.
    • On implémentera un menu déroulant dans la partie 2 du travail pratique.
  • La photo de profil est une image rectangulaire ou carrée : c'est avec CSS que vous l'afficherez en forme de disque.
  • Rédigez votre biographie avec 3 éléments textuels séparés par des lignes horizontales.
  • Créez 4 articles dans l'ordre du plus récent au plus ancien.
    • Les catégories sont à droite de la date séparées par une barre verticale.
    • Attention, utilisez des images rectangulaires (paysage) pour les articles (ça vous facilitera la mise en page pour la partie 2 du TP).
    • Dans les articles, les liens Lire la suite… ont un effet de survol qui met le texte en noir.
      • En cliquant sur ces liens, on peut accéder à l'article complet sur un site web externe qui s'ouvre automatiquement dans un nouvel onglet.
  • Votre page web, vos images, votre feuille de style personnelle et toutes autres ressources se trouvent dans un dossier portant le nom d'utilisateur de votre compte HES-SO (8.8) à la racine du dossier /web (qui est le répertoire à déployer sur votre serveur web).
    • Ex. /web/joel.dacomo (page web index.html)
    • Ex. /web/joel.dacomo/css (feuille de style CSS)
    • Ex. /web/joel.dacomo/img (images)
  • Intégrez la feuille de style modern-normalize (qui se trouve sous /web/css/modern-normalize.css) dans votre page web avec un élément <link>.
  • Sauf indication contraire, le texte est en noir.
  • Sauf indication contraire, le texte a une taille de 14px.
  • Tous les liens et le menu Autres pages, les dates et les catégories des articles ont la couleur #777.
  • Tous les liens et le menu Autres pages ont un effet de survol (hover) qui met le texte en noir.
En-tête

header.png

header-box.png

  • "Joël Dacomo" → Titre de niveau 1
    • Taille de la police : 24px
  • Accueil et Autres pages → navigation
    • Accueil → lien
    • Autres pages → menu déroulant
    • Chaque élément ci-dessus a une marge à gauche de 25px
  • La couleur de fond est #fff
  • Il y a un espace automatique entre le titre et la navigation (en violet)
Contenu principal

main.png

main-box.png

  • La bordure entre le contenu principal de la page et l'en-tête est de 1px avec la couleur #e2e2e2
  • La couleur de fond du contenu est #fff
  • La couleur de fond extérieur est #f0f0f0
  • Il y a un espace de 30px entre la biographie et la liste des articles (en violet)
Article

article.png

article-box.png

  • La bordure est de 1px avec la couleur #e2e2e2
  • Les coins arrondis de l'article et de l'image ont un rayon de 5px
  • La couleur de fond du contenu est #fff
  • La couleur de fond extérieur est #f0f0f0
  • Il y a un espacement de 30px entre chaque article
  • Les dimensions de l'image sont 180px en largeur et en hauteur
  • Il y a un espace de 20px entre l'image et le contenu de l'article (en violet)
  • L'article est composé :
    • D'un en-tête contenant le titre de niveau 2 ainsi que la date et la catégorie
      • Le titre a une taille de 22px
    • D'un paragraphe contenant le texte de l'article
    • D'un pied de page contenant le lien Lire la suite…
Biographie

aside.png

aside-box.png

  • La bordure est de 1px avec la couleur #e2e2e2
  • Les coins arrondis ont un rayon de 5px
  • La couleur de fond du contenu est #fff
  • Les dimensions de l'image sont 160px en largeur et en hauteur
  • La biographie est composée :
    • D'une photo de profil de l'auteur du blog
    • D'un titre de niveau 2
      • Le titre a une taille de 20px
    • De 3 paragraphes de texte séparés par une ligne horizontale
      • La ligne de séparation fait 1px de hauteur avec la couleur #e2e2e2
  • Il y a un espace de 20px entre la photo et le titre (en violet)
  • Il y a un espace de 10px entre le titre et le 1er paragraphe
  • Il y a un espace de 10px entre chaque paragraphe et la ligne de séparation
Pied de page

footer.png

footer-box.png

  • La couleur de fond du contenu est #000
  • La couleur du texte est #fff

Workflow Git

Utilisez le Feature Branch Workflow pour gérer les versions de votre code source et le partager entre vous : chaque page personnelle est développé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 suit dans cette liste (la dernière relit la MR de la première).
  • Choisissez ensemble la personne responsable de la release 0.5.0 (voir Release ci-dessous) et communiquez votre choix sur le canal Teams du cours au plus tard le jeudi 5 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

  1. Mettez à jour votre branche main locale, puis créez votre branche feature depuis celle-ci (ex. feature/blog-joel.dacomo) :

    git switch main
git fetch
git rebase origin/main
git switch -c feature/blog-joel.dacomo

  2. Réalisez votre page web dans cette branche, avec des commits réguliers, et envoyez la branche sur origin dès les premiers commits (git push -u origin feature/blog-joel.dacomo).

  3. Dans la même branche, une fois la page terminée :
    • Ajoutez un lien vers votre page personnelle dans la liste des blogs de la page d'accueil du site web /web/index.html, après le lien Template, dans l'ordre alphabétique des noms de famille (ex. Dacomo Joël).
    • Ajoutez une ligne pour votre page dans la section ## [Unreleased] du fichier CHANGELOG.md (voir Changelog).
  4. 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).
  5. 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.

  6. 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 liste des blogs de /web/index.html et la section [Unreleased] de CHANGELOG.md : des conflits sont attendus. Résolvez-les en gardant les lignes des autres et la vôtre, dans l'ordre alphabétique pour la liste des blogs.

  7. Après la fusion, nettoyez votre dépôt local (voir Nettoyer).

Relecture de la MR d'une autre personne

  1. Récupérez la branche de la MR et testez la page dans votre navigateur (git fetch, puis git switch feature/blog-<prénom.nom>).
  2. Contrôlez les points suivants :
    • La page respecte les spécifications de ce document et le modèle
    • 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, sa ligne dans la liste des blogs de /web/index.html 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
  3. Laissez au moins un commentaire dans la MR (correction demandée, question ou remarque), sur la ligne concernée.
  4. 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), ou utilisez le bouton Rebase de la MR s'il est proposé.

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.5.0, au plus tard le jeudi 5 novembre à 23h59 :

  1. Depuis la branche main à jour, créez la branche release/0.5.0.
    • Ce n'est pas une branche release de Gitflow : c'est une branche courte comme les autres, qui ne contient que la mise à jour du changelog.
  2. Dans CHANGELOG.md, transformez la section ## [Unreleased] en section ## [0.5.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.
  3. 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.
  4. Après la fusion, créez le tag annoté v0.5.0 sur le dernier commit de main et envoyez-le sur origin (voir Tags).
  5. Sur GitLab, créez la release v0.5.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.5.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

  1. 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.5.0 (tag v0.5.0 de la branche main), avec les 9 pages personnelles du blog.

Rendu du TP

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

Echéances :

  • Jeudi 5 novembre à 13h : le nom de la personne responsable de la release est communiqué sur le canal Teams du cours.
  • Jeudi 5 novembre à 23h59 : toutes les MR sont fusionnées et la version 0.5.0 est publiée (tag v0.5.0 et release GitLab) par la personne responsable de la release.
  • Vendredi 6 novembre à 23h59 : chaque personne a mis en ligne la version 0.5.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 du modèle