TP 4

Intégration continue, joueurs dynamiques et visibilité du projet.

Méta

• Date limite : 19 avril, 23 h 59
• Remise : GitLab
• Équipes : Équipes de trois étudiants, mêmes équipes que pour le TP précédent.
• Remise en retard : Impossible. Vous serez évalués selon le contenu présent sur votre branche master/main à la date limite.

Il est de votre responsabilité de remettre votre code à temps. N’attendez pas à la dernière minute, GitLab pourrait échouer.

Objectifs d’apprentissage

Dans ce dernier TP, vous transformerez votre projet Skyjo en une application présentable que vous pourrez ajouter à votre CV ou à votre portfolio.
Cette dernière étape est plus courte que les TPs précédents, mais elle vous aidera à démontrer votre polyvalence avec des outils et des pratiques avancées en génie logiciel. L’objectif est d’utiliser l’intégration continue et des techniques de documentation afin d’amener votre projet à un état soigné - de cette façon, les personnes intéressées à vous embaucher pourront facilement être convaincues de vos compétences.

Plus concrètement, dans ce dernier TP, vous allez…

1. Compléter votre code fonctionnel avec une pipeline d’intégration continue (CI).

2. Votre pipeline CI doit réexécuter toutes les vérifications de qualité de code Maven introduites précédemment.

3. Votre pipeline CI doit prendre en charge des publications continues de la documentation sur une page Web dédiée ( HTML).

4. Votre pipeline CI doit prendre en charge des publications continues des versions binaires sur une page de téléchargement (JAR).

5. Prendre en charge des parties dynamiques

6. noms de joueurs arbitraires

7. nombre (valide) arbitraire de joueurs
8. remplacement automatique de noms de joueurs spécifiques par des joueurs robots

Aperçu étape par étape

1. Corrections : Vérifiez votre remise précédente.
   • Utilisez la rétroaction reçue sur GitLab (cela peut encore prendre quelques jours, vous pouvez déjà relancer vos tests).
   • Corrigez tout problème, en particulier les tests en échec. Utilisez le débogueur.

2. Ajouter une page de documentation du projet :

   • Ajoutez un README.md servant de point d’entrée lisible pour un humain.
   • Assurez-vous qu’il contient des liens vers la documentation, le téléchargement binaire et qu’il explique comment utiliser votre logiciel.

3. Mettre en place une pipeline CI utile :

   • Configurez la réexécution automatique de toutes les vérifications de code Maven.
   • Configurez des publications continues de la documentation.
   • Configurez des publications continues des fichiers jar.

4. Modifiez votre lanceur pour permettre des parties arbitraires.

   • Prenez en charge des noms et des quantités de joueurs dynamiques.
   • Prenez en charge des joueurs robots (au moins Keksli et MadMax).

Instructions détaillées

Vérifiez votre remise précédente

• Mettez à jour vers les interfaces et les tests finaux :
  • Interfaces :

    <dependency>
        <groupId>ca.uqam.info.max</groupId>
        <artifactId>skyjo-interfaces</artifactId>
        <version>tp4-01</version>
    </dependency>
    

  • Tests :

    <dependency>
        <groupId>ca.uqam.info.max</groupId>
        <artifactId>skyjo-tests</artifactId>
        <version>tp4-01</version>
    </dependency>
    

• Assurez-vous que tous les tests réussissent, y compris les nouveaux scénarios de fin de partie.

Documentation

• La première chose que les gens voient en accédant à votre projet est le README.md.
• Une bonne page d’accueil doit présenter l’intérêt et l’utilisation de votre application, sans submerger l’utilisateur.
• Ajoutez ou modifiez le README.md existant et créez au moins les sections suivantes :
  • Nom du projet
  • Contexte du projet
  • Lien vers la documentation (voir section CI)
  • Lien vers le téléchargement du JAR
  • Instructions d’exécution, c.-à-d. comment lancer votre JAR
  • Contributeurs

CI

• La CI est essentielle pour assurer une qualité de code constante. Vous configurerez votre pipeline CI pour réexécuter toutes les vérifications de qualité déjà imposées par Maven.
• Ajoutez un profil de build Maven personnalisé (non par défaut) nommé nomutation qui ignore les tests de mutation. Le pipeline CI doit utiliser exclusivement ce profil afin d’accélérer son exécution.
• Un bon logiciel possède une documentation accessible. Vous activerez une tâche pages pour héberger le javadoc à jour de votre code sur une page Web dédiée, liée depuis le README.md.
• Un bon logiciel prend en charge des publications continues. Vous réutiliserez la tâche pages pour également héberger le fichier JAR fonctionnel de votre application sur une URL dédiée, liée depuis le README.md.

Lanceur

• Jusqu’à présent, le code du lanceur démarrait toujours la même partie, avec les mêmes joueurs.
• Modifiez votre code pour accepter les noms des joueurs comme arguments, par exemple : java -jar Skyjo.jar Max Ryan Hafedh. (2 à 4 joueurs doivent être pris en charge)
• Modifiez votre code pour substituer automatiquement les joueurs robots, c.-à-d. si un nom de joueur est Keksli ou MadMax, le joueur doit être remplacé par une instance d’IA correspondante.
• Si vous avez implémenté votre propre IA / joueur robot, vous pouvez réserver des mots-clés supplémentaires pour votre IA.

Barème de correction

Critère	Pourcentage max
Tous les tests réussissent	15 %
Toutes les métriques de qualité de code précédentes respectées dans le pom (mutations, couverture, checkstyle, complexité, javadoc)	25 %
CI	25 %
Configuration dynamique des parties via des arguments à l’exécution	15 %
README + liens fonctionnels vers le javadoc et le JAR	10 %

Recommandation

Simulez le processus de correction avant la remise : reclonez votre propre projet et exécutez mvn clean verify, puis assurez-vous que votre projet se construit sans avertissements ni erreurs.

Refus automatique

Voici une liste de vérification des éléments à éviter absolument. Si au moins un élément s’applique, votre remise perdra tous les points liés au code. D’autres critères de refus peuvent s’appliquer.

• Solution non fournie dans le répertoire GitLab dédié, ou non présente sur la branche main.
• Solution répartie sur plusieurs branches.
• Le dépôt contient un fichier zip.
• Le code ne compile pas avec la commande Maven fournie.
• Le fichier pom.xml contient des plugins ou dépendances non autorisés.
• Les classes fournies n’implémentent pas les interfaces fournies.
• L’implémentation des classes de tests abstraites n’est pas fournie dans le package de test.
• La structure du projet a été modifiée / n’est pas respectée.
• Le programme tente de communiquer sur le réseau à l’exécution.
• Le programme se bloque à l’exécution.

DIVERS

Cette section fournit des ressources supplémentaires pour la réalisation technique de votre TP.

Parties d’exemple

• Le TP3 ne contenait pas de tests d’intégration allant jusqu’à la fin de partie.
• Vous trouverez ci-dessous les fichiers de journal pour trois scénarios de test supplémentaires atteignant la fin de partie.

Fichiers

Itérations	Joueurs	Fichier de traces
61	Keksli VS Keksli	keksliColEliminationEnd.txt
82	Keksli VS Keksli VS MadMax	keksliVsKeksliVsMadMaxEnd.txt
144	MadMax VS MadMax	madMaxVsMadMaxR43End.txt
445	MadMax VS MadMax VS MadMax VS MadMax	maxMaxQuadrupelR51End.txt