Objectifs du cours

  • Découvrir la gestion d'un serveur Linux
  • Concevoir en équipe une solution technique à un problème donné
  • Réaliser votre solution
  • Industrialiser/automatiser le déploiement de cette solution
  • Prendre du recul, analyser sa solution et l'améliorer
  • 4x4h séance dont soutenance à la dernière

Projet en bref

  • Fournir une API REST de gestion d'utilisateurs (USER)
  • La déployer sur un serveur Linux
  • Trois persona vont juger votre travail : le client, l'architecte et le prof

Côté client

  • Un client veut une API qui peut gérer plusieurs milliers d'utilisateurs
  • Il l'a veut rapidement et sans bug !
  • Il risque de vous demander des nouvelles fonctionnalités
  • Il va faire appel à un architecte informatique pour valider vos choix techniques

Côté architecte

  • L'application doit être testée (c'est dans votre intérêt)
  • Vous devez mettre en place de l'intégration continue
  • Vous devez mettre en place du déploiement continu

Côté prof

  • Vous formez des groupes de 4 et je vous fourni un serveur Linux sur lequel rien n'est configuré
  • 4 séances de TP de 4H (la dernière est consacrée à la soutenance)

Note finale

  • Client - une note automatique sur le fonctionnement de votre API (tests automatisés)
  • Architecte - une note de soutenance pendant laquelle vous présenterez et justifierez vos choix
  • Architecte - une note d'audit (sécurité, qualité de code et respect des règles)
  • Prof - une note sur l'organisation du groupe
  • Prof - ⚠️ une note de participation

⚠️ Vous êtes 4, il faut vous organiser !

Je ne veux pas voir 3 personnes qui attendent pendant qu'une personne recherche ou avance

Je peux vous aider à vous découper les tâches

⚠️ Ne faites pas n'importe quoi avec le serveur Linux


Rien d'illégal !

Je 🔍 tout ce qu'il se passe sur la machine, si je vois la moindre action illégal, c'est 0 et vous ne validez pas votre matière et par conséquance le semestre.

⚠️ Ne faites pas crash la machine de façon répétée.
#Demande du client n°1 Faire une API REST sur le port 80 du serveur permettant de manipuler ce type d'objet ```javascript { "id": "12121s12a23123", "firstName": "Antoine", "lastName": "Caron", "birthDay": "14/02/1993", "position": { "lat": 45.737526, "lon": 4.814719, } } ```
#Méthodes disponibles (1/2) * GET /user -> retourne tous les utilisateurs * PUT /user -> permet de remplacer la collection entière par une nouvelle liste d'utilisateur * DELETE /user -> supprime toute la collection des utilisateurs ⚠️ à vos codes de retour HTTP
#Méthodes disponibles (2/2) * GET /user/{id} -> retourne l'utilisateur correspondant * POST /user -> ajoute un nouvel utilisateur passé en paramètre * PUT /user/{id} -> met à jour l'utilisateur * DELETE /user/{id} -> supprime l'utilisateur correspondant
# Demande de l'architecte n° 1 * Mise en place de tests unitaires/fonctionnels de l'API * Mise en place d'une intégration continue (Travis ou Circle-CI) * Déploiement basique de la demande du client n° 1 sur le serveur
#Demande du client n° 2 - Pagination * GET /user?page=0 -> retourne les 100 premiers utilisateurs (⚠️ la page est par défaut à 0)
# Demande de l'architecte n° 2 * Maintient des tests unitaires/fonctionnels de l'API * Maintient de l'intégration continue
#Demande du client n° 3 - Recherche * GET /user/age?gt=0 -> retourne les 100 premiers utilisateurs dont l'age est supérieur à 0 * GET /user/age?eq=0 -> retourne les 100 premiers utilisateurs dont l'age est égal à 0 * GET /user/search?term=toto -> retourne les 100 premiers utilisateurs dont le nom est "toto" * GET /user/nearest?lat=43.12&lon=5.97 -> retourne les 10 utilisateurs les plus proches
# Demande de l'architecte n° 3 * Exposition d'un API GraphQL associée * HTTPS * Optimisation des temps de réponse (ex : cache)
# Soutenance finale * 6 slides attendues * ⚠️ Ne pas présenter le contexte projet/client
# Architecture * 1 schéma global + des explications de l'achitecture déployée * Expliquer l'évolution de l'architecture mise en place
# Choix techniques * Expliquer les choix techniques des technologies utilisées (côté serveur) * Avantages et inconvénients des technologies utilisées * Est-ce que ces choix étaient les bons ?
# Démonstration * On efface tout ce qu'il y a sur le serveur et on mesure le temps de ré-installation from scratch
# Organisation du groupe et du travail
# Justifier l'intérêt du CI/CD
# Difficultés rencontrées et retours sur l'UE

Concrètement, on fait quoi ?

Comme un ingénieur dans un contexte professionnel, vous avez (très souvent) la liberté d'implémentation

Vous être LIBRE des technologies que vous utilisez, mais ⚠️ à ne pas faire des choix trop ambitieux/WTF

# Séance n° 1 ### Avant 10h * Les groupes sont constitués et les choix technologiques pour le serveur et la BDD sont établis * Une personne de chaque groupe a un accès SSH à la machine distante ### Avant 12h * 75% des groupes doivent avoir une base d'API fonctionnelle
# Séance n° 2 ### Avant 10h * 75% des groupes doivent avoir la demande du client n° 1 Ok * 75% des groupes doivent avoir la demande de l'architecte n° 1 Ok ### Avant 12h * Les tests unitaires/fonctionnels sont en place * L'intégration continue est en place
# Séance n° 3 ### Avant 10h * 75% des groupes doivent avoir le déploiement continu Ok Objectif => Avancer au maximum sur le projet global
# Séance n° 4 ###Soutenance
Générateur de users aléatoires
Script d'évalutation des demandes clients