Aller au contenu

Travail pratique

ID : A07-TP05.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 avec MkDocs et Git
  • Déployer un site web supplémentaire sur nginx (Linux) en production

Travail à réaliser

Prettier

  1. Installez et configurez Prettier dans IntelliJ IDEA.
    • Configurez Prettier dans IntelliJ IDEA, pour formater les fichiers Markdown (.md).

MkDocs

  1. Formez des groupes de 2 personnes, puis choisissez un des thèmes suivants (un thème par groupe) :

    • Topic A : title et meta
    • Topic B : main et img
    • Topic C : article et section
    • Topic D : header et footer
    • Topic E : nav et aside

  2. Dans le projet GitLab du TP, avec IntelliJ IDEA :

    • Une des personnes du groupe crée une branche feature/topic-x (remplacez x par la lettre de votre thème) depuis la branche develop.
    • La même personne crée un fichier topic-x.md (remplacez x par la lettre de votre thème) dans le dossier docs.
    • Elle effectue un commit du fichier (vide) avec un message de commit clair, puis push la branche feature/topic-x sur origin.
    • L'autre membre du groupe doit ensuite faire un fetch et un checkout de la branche pour synchroniser son environnement.

  3. Rédaction du contenu pour les balises HTML :

    Le but de l'exercice est que chaque personne rédige ces contenus de son côté et les mette à disposition de l'autre membre du groupe avec des push de la branche feature/topic-x sur origin.

    • Dans la page de votre thème, faites un chapitre principal puis un sous-chapitre par balise.
    • Chaque membre du groupe rédige, dans le sous-chapitre de sa balise, 3 sous-chapitres pour présenter celle-ci : Description, Utilisation et Compatibilité.
      • Vous pouvez utiliser les documentations en ligne pour vous aider à rédiger le contenu des divers chapitres, tel que MDN Web Docs - HTML
      • Pour la compatibilité, utilisez le tableau sur le site de Mozilla (ci-dessus) sous forme d'image.
      • Il doit y avoir au moins un commit par chapitre.
      • Une fois les contenus terminés par chaque membre du groupe, les deux versions du fichier doivent être "consolidé" en utilisant Git pour n'en faire qu'une avec l'ensemble des textes.

  4. Exemples d'utilisation :

    • Chaque membre du groupe ajoute un sous-chapitre Exemples entre les sous-chapitres Utilisation et Compatibilité de la balise de l'autre membre du groupe et ajoute un exemple d'utilisation de celle-ci.
    • Utilisez l'extension Highlight pour avoir la coloration syntaxique dans les blocs de code.
    • Chaque membre du groupe ajoute un deuxième exemple d'utilisation dans le chapitre Exemples de sa balise.
    • Il doit y avoir au moins un commit par exemple.
    • Une fois les contenus terminés par chaque membre du groupe, les deux versions du fichier doivent être "consolidé" en utilisant Git pour n'en faire qu'une avec l'ensemble des textes.

Workflow Git

Utilisez le workflow Git Gitflow Workflow pour gérer les versions de votre code source et le partager entre vous.

  • Respecter 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.

Pour le workflow :

  1. Créez une branche feature par thème (ex. feature/topic-a).
  2. Faites un "merge commit" (merge no-fast-forward) de votre branche feature dans la branche develop une fois la rédaction du thème complètement terminée.
  3. Ajoutez votre thème dans la table des matières de la page principale du site MkDocs index.md (dans l'ordre alphabétique A-D).
    • Faites un commit de cette modification dans la branche develop après le merge de la branche feature.
  4. Créez une branche release avec le bon numéro de version.
    • Chaque ajout d'une nouvelle feature (thème) incrémente la version mineure du projet : 0.X.0 (ex. release-0.4.0).
  5. Dans la branche release, mettez à jour le fichier CHANGELOG.md.
  6. Pour terminer, faites un "merge commit" (merge no-fast-forward) de la branche release dans les branches master puis develop (dans cet ordre).
  7. A la fin du travail pratique, seules les branches master et develop doivent exister sur origin (plus de branches feature ou release).

🚨 Pas de merge dans ou depuis les branches origin, uniquement dans les branches locales !

  • Si votre push ne passe pas sur origin, faites un fetch et résolvez les conflits (éventuellement faites un rebase).
  • Evitez de faire un pull afin de ne pas générer de merge inutile.
  • Utilisez "interactive rebase" pour repositionner, modifier, arranger vos commits dans votre branche feature, si besoin.
  • Utilisez les branches hotfix pour corriger les erreurs ou les oublis dans le code fusionné dans la branche master.

Mise en production

  1. Déployez la dernière version du site MkDocs (le site web produit avec la commande build) sur votre serveur de production (VPS) avec l'URL https://tp05.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.
    • Par "dernière version du site MkDocs", on entend la version finale du code avec les thèmes de tous les groupes.

Rendu du TP

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

Le dernier commit sur Git doit être fait au plus tard le dimanche 3 novembre à 23h59.

La dernière version du site MkDocs doit avoir été mise en ligne sur votre VPS au plus tard le lundi 4 novembre à 13h.

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

  • Respect de toutes les consignes de ce document
  • Utilisation correcte du workflow Git
  • Commits respectant les règles vues ensemble
  • Mises à jour correctes et pertinentes du changelog
  • Numérotation correcte des versions
  • Disponibilité de la dernière version du site sur votre VPS
  • Uniformité dans la rédaction des thèmes entre les groupes