changing spacing between bulleted lists and changed heading for cahier des charges
This commit is contained in:
parent
5e4d09d7aa
commit
f4542c3429
1 changed files with 6 additions and 23 deletions
|
|
@ -123,21 +123,21 @@ As our group’s application was being maintained on Github, we used Github acti
|
|||
|
||||
# Cahier des charges
|
||||
|
||||
### Contexte et définition du projet
|
||||
## Contexte et définition du projet
|
||||
|
||||
L’entreprise Oros est un magasin spécialisé dans la location de biens pour diverses activités en montagne. Ainsi, elle doit gérer ses stocks et ses réservations de manière fiable. Pour cette raison, l’entreprise aurait besoin d’une application web qui gère ces deux besoins en parallèle afin de faciliter leur organisation.
|
||||
|
||||
### Objectifs du projet
|
||||
## Objectifs du projet
|
||||
|
||||
Au niveau administrateur, il faut gérer les références produits ainsi que le nombre d’exemplaires en stock. Il devrait également pouvoir consulter les réservations qui ont été effectuées par les clients.
|
||||
Pour les clients qui utilisent le site, ils devraient pouvoir rechercher les produits disponibles, gérer leur panier avec la possibilité d’ajouter, retirer ou modifier le nombre de produits sélectionnés.
|
||||
Un récapitulatif du panier et la saisie des informations de facturation sera disponible, ainsi qu’un passage de commande et une validation finale par paiement.
|
||||
|
||||
### Les rôles
|
||||
## Les rôles
|
||||
|
||||
Un visiteur du site peut voir tous les produits disponibles pour réservation. Une fois son compte créé, il peut réserver les produits choisis pour les dates sélectionnées. Seul un administrateur peut créer des nouveaux produits, en supprimer ou modifier si besoin, ainsi que consulter toutes les réservations en cours. Un utilisateur ne peut accéder à la partie administrative, mais un administrateur a accès à toutes les rubriques du site.
|
||||
|
||||
### Structure et fonctionnalités
|
||||
## Structure et fonctionnalités
|
||||
|
||||
Le site est composé de deux parties : back-office et front-office.
|
||||
Le back-office concerne seulement l’administrateur. Il permet la gestion des références produits ainsi que la consultation des réservations et du nombre d’exemplaires en stock. L’administrateur contrôle le nombre, le nom, la description et l’image de chaque produit qui apparaît sur le site. Il peut en outre retirer du catalogue tout produit rendu endommagé.
|
||||
|
|
@ -145,7 +145,7 @@ Le front-office concerne ce qu’un visiteur ou un client peuvent voir.
|
|||
Pour un simple visiteur, il peut consulter les produits qui sont disponibles en magasin.
|
||||
Un client peut non seulement consulter les produits, mais il peut également s’authentifier sur le site, ajouter des produits dans son panier, puis en retirer ou modifier si besoin. Une fois décidé, il peut consulter un récapitulatif de son panier, puis créer une réservation pour les produits sélectionnés et finaliser la réservation par paiement.
|
||||
|
||||
### Technologies et outils tiers
|
||||
## Technologies et outils tiers
|
||||
|
||||
Pour le back-end, nous utilisons :
|
||||
|
||||
|
|
@ -172,7 +172,7 @@ Pour l'environnement général, nous utilisons :
|
|||
* Docker et Dockerhub, pour les images à déployer et hébergement des images
|
||||
* Visual Studio Code, pour l'édition du code
|
||||
|
||||
### Déploiement
|
||||
## Déploiement
|
||||
|
||||
*Le code*
|
||||
Notre groupe ayant choisi d’avoir un dépôt par module, nous hébergeons sur github le code source dans une organisation commune avec :
|
||||
|
|
@ -1775,20 +1775,14 @@ Dans notre composant MainNav, nous avons mis ce lien pour le test également :
|
|||
Pour faciliter le déploiement et réduire les interventions manuelles, nous avons instauré un système d'intégration et de déploiement continu (CI/CD) tant en pré-production qu'en production. Ce système utilise divers outils, notamment GitHub Actions, des webhooks, Docker, DockerHub, et Caddy en tant que proxy inverse.
|
||||
|
||||
* Github Actions : Introduit en 2019, GitHub Actions est une solution CI/CD qui s'intègre directement aux dépôts GitHub. Elle permet d'activer des workflows en fonction d'événements, tels qu'un push sur une branche. Dans le cadre de mon projet, j'ai mis en place deux workflows YAML pour :
|
||||
|
||||
* Lancer des tests automatiquement
|
||||
|
||||
* envoyer des images Docker à Dockerhub
|
||||
|
||||
* Docker & Dockerhub : Les workflows de GitHub Actions créent des images Docker, qui sont ensuite sauvegardées sur DockerHub, un registre en ligne pour les conteneurs Docker. DockerHub facilite la gestion des images Docker en proposant des outils pour les créer, les tester, les stocker et les déployer.
|
||||
|
||||
* Caddy : Nous avons choisi Caddy comme reverse proxy pour gérer les requêtes HTTP vers notre domaine. Un reverse proxy est un serveur logiciel qui redirige les requêtes entrantes vers d'autres serveurs et renvoie ensuite la réponse au client. Ce dispositif permet de répartir la charge entre les serveurs et d'améliorer la sécurité.<br />
|
||||
En plus de sa fonction de redirection, Caddy facilite la gestion du protocole HTTPS (Hypertext Transfer Protocol Secure). HTTPS assure la confidentialité et l'intégrité des données échangées entre le client et le serveur grâce au protocole Transport Layer Security (TLS), qui remplace l'ancien SSL. Ce protocole offre trois niveaux essentiels de protection :
|
||||
|
||||
* Chiffrement des données pour éviter leur interception
|
||||
* Intégrité des données pour garantir qu'elles ne sont pas altérées
|
||||
* Authentification pour vérifier l'identité des parties en communication
|
||||
|
||||
* Webhooks : Enfin, les webhooks sont configurés pour exécuter des scripts sur le serveur lorsque se produit un événement particulier, comme une mise à jour de branche. Cela permet d'automatiser des actions telles que le déploiement ou la mise à jour d'une application, sans nécessiter d'intervention manuelle.
|
||||
|
||||
Nous avons donc mis en place des workflows d'intégration continue (CI) afin d'automatiser les tests et le déploiement Docker de nos applications front-end et back-end. Ces workflows s'activent à chaque push, garantissant ainsi que le code est systématiquement testé et que les images Docker sont construites et publiées en cas de réussite des tests. En suivant la documentation officielle pour la configuration des workflows, le fichier YAML doit être placé à la racine du projet dans le répertoire `.github/workflows`.
|
||||
|
|
@ -1884,27 +1878,16 @@ jobs:
|
|||
Ensuite, nous avons mis en place l'environnement serveur requis pour le déploiement continu, en supposant que le VPS, Docker et Docker Compose ont déjà été installés au préalable.
|
||||
|
||||
* Organisation des dossiers : Nous avons créé deux dossiers, *staging* et *production*, dans le répertoire principal de notre projet Oros sur le VPS. Chaque dossier renferme plusieurs fichiers de configuration essentiels :
|
||||
|
||||
* Docker-compose-prod.yml : Ce fichier indique à Docker comment construire et lancer les services du back-end, du front-end, et de la base de données. Il précise la version des services afin d'assurer des déploiements stables et reproductibles. Ce fichier est destiné à la production (prod), contrairement à *docker-compose.staging.yml*, qui est utilisé uniquement en phase de développement.
|
||||
|
||||
* Nginx.conf : Ce fichier gère la redirection des requêtes /graphql vers notre application Node.js et sert également les fichiers statiques en transmettant les informations à Caddy.
|
||||
|
||||
* fetch-and-deploy-${{ENV}}.sh : Ce script bash, appelé par la configuration de notre Webhook, redémarre les services via Docker Compose avec les dernières versions des images Docker. Il spécifie également les ports utilisés par Nginx (8000 pour la production et 8001 pour le staging), ce qui permet à Caddy de rediriger correctement les requêtes.
|
||||
|
||||
* .env : Ce fichier contient les variables d'environnement nécessaires au projet, telles que les secrets utilisés par les services. Il est lu par *docker-compose-prod.yml* pour fournir ces informations aux conteneurs Docker.
|
||||
|
||||
* Configuration de Caddy et des webhooks : Nous avons aussi configuré les fichiers de configuration pour Caddy et les webhooks :
|
||||
|
||||
* Caddyfile : Ce fichier permet de diriger les requêtes entrantes grâce à la directive reverse_proxy vers les ports appropriés. Les requêtes adressées à staging.1123-jaune-1.wns.wilders.dev sont redirigées vers le port 8001 (staging), celles destinées à 1123-jaune-1.wns.wilders.dev vont vers le port 8000 (production), tandis que les requêtes à ops.1123-jaune-1.wns.wilders.dev sont dirigées vers le port 9000 (service Webhook).
|
||||
|
||||
* Webhook.conf : Ce fichier de configuration au format JSON spécifie les actions à réaliser lors de la réception d'une notification. Nous avons configuré deux webhooks :
|
||||
|
||||
* update-staging : le premier peut être lancé en allant à `https://ops.1123-jaune-1.wns.wilders.dev/hooks/update-staging` lors de la disponibilité d'une nouvelle image sur Dockerhub, afin de vérifier les résultats attendus
|
||||
|
||||
* update-prod : le deuxième peut être lancé en allant à `https://ops.1123-jaune-1.wns.wilders.dev/hooks/update-prod` une fois que les résultats sur `https://staging.1123-jaune-1.wns.wilders.dev` ont été vérifé afin de mettre l'image la plus récente de Dockerhub
|
||||
|
||||
* Fichiers Docker Compose et Nginx : Voici un aperçu des fichiers utilisés pour la configuration de nos services et de notre proxy :
|
||||
|
||||
* services : backend, frontend, db, nginx : Le fichier docker-compose-staging.yml configure les services du back-end (Node.js), du front-end (Next), de la base de données (Postgres), ainsi que Nginx pour gérer le reverse proxy. Chacun de ces services est surveillé par Docker, avec des vérifications de santé (healthcheck) et des dépendances clairement établies entre eux.
|
||||
|
||||
```yml
|
||||
|
|
|
|||
Loading…
Reference in a new issue