- Backend : Yasmine CHETTATI + Elena FRISON
- Frontend web : Anatole VOLTZ + Yuri SMOLIAK
- Frontend mobile : Amine BENOMAR + Matthias SAMI
- Cheffe de projet : Elena FRISON
Les installeurs pour Linux, Windows, Mac OS et Android sont disponibles ici.
Important ! Au moment de l'échange avec l'application desktop, il est impératif que l'utilisateur du smartphone se connecte sur le même réseau local pour que le trasnfert soit possible.
Dans la version actuelle de Stras'Flow, il est vivement conseillé d'être sur le mode clair pour un affichage optimal sur smartphone.
.deb
Temps de première installation indicatif : 10 min (c'est l'extraction de la carte qui prend du temps, merci de votre compréhension).
Une réinstallation ne prendra qu'une ou deux minutes.
- Installation :
sudo dpkg -i /path/to/strasflow_2.0.0_amd64.deb - Lancement :
strasflow(ou depuis le menu Applications --> Bureautique)
AppImage
- Lancement :
chmod +x /path/to/StrasFlow-2.0.0-x86_64.AppImage
/path/to/StrasFlow-2.0.0-x86_64.AppImages
.zip
- Décompresser l'archive
StrasFlow-2.0.0-Windows.zip; - Double-clic sur
start.bat.
.zip
- Décompresser l'archive
StrasFlow-2.0.0-macOS.zip; - Glisser
StrasFlow.appdans Applications ; - Double-clic.
.apk
Ouvrir le fichier sur smartphone et attendre la fin de l'installation.
Au premier lancement, accepter la géolocalisation.
main: Production - Push direct interdit - Merge requests uniquementdevelop: Intégration - Réservé aux mainteneursfeature/<ticket_n>-<feature_name>: Fonctionnalités - Push autorisé par le créateur uniquementgit push --forceest interdit (sur GitLab)- Les Git hooks sont recommandés
- Les branches
feature/*sont backupées tous les jours sur un autre dépôt, privé
- Créer sa branche (elle peut dériver d'une autre) :
feature/<ticket_number>-<feature_name> - Développer et tester localement
- Pusher sur sa branche
- Créer une Merge Request vers
develop, ou vers la branche forkée - Review et merge par un mainteneur sur
develop, par l'auteur de la branche si branche forkée
.
├── README.md
├── .gitignore
├── .gitlab-ci.yml
├── docker-compose.yml
│
├── api/ # API
├── docs/ # Documentation
├── mobile/ # Client mobile
│ └── tests # Tests
├── scripts/ # Scripts (notamment pour la CI/CD)
├── visuals/ # Maquettes, design, screenshoot
├── web/ # Client lourd
│ ├── public/ # Données (carte)
│ ├── tests/ # Tests
│ └── Dockerfile
└── websocket-server/ # Mini-serveur de synchronisation
Lors de manifestations dans l’espace public de la ville de Strasbourg, de nombreuses opérations de logistique sont nécessaires pour assurer le bon déroulement et la sécurisation de l’événement. Les services de la ville sont amenés à poser des barrières pour sécuriser ou gérer les flux de spectateurs, mettre en place des blocs de béton ou des engins pour éviter la pénétration de véhicules dans les zones de spectacle, poser des tribunes, proposer des auges pour la prise d’eau, installer des prises électriques, …
Cette logistique permettant d’assurer la tenue d’événements sur le territoire de Strasbourg, nécessite d’être analysée en amont et d’être intelligemment construite pour assurer sa mise en œuvre de manière efficace en toute sécurité pour les personnes et les biens.
Aussi, afin de faciliter les différentes étapes de ce travail, il est proposé de développer un outil d'aide à la planification d'événements.
- L'outil de planification doit être utilisable localement sur poste de travail sans accès réseau ou internet.
- Le développement doit être clairement structuré et documenté, afin de permettre la maintenance et l'évolution de l'application.
- L'accès à l'application doit être sécurisé.
- Opérations de logistique sur les voies publiques de la ville de Strasbourg (zone pouvant être étendue à l'Eurométropole).
- Liste des équipements nécessaires pour la logistique (barrières, etc.) : voir le document ici.
- Terminologie : page Wiki ci-contre.
Cette évolution de l'application concerne principalement la manière d'afficher les informations chronologiques des poses et déposes des équipement, l'ajout d'informations sur la carte et la gestion des plannings des équipes.
- Saisie sous forme de polyligne des éléments de type barrière ou bloc de béton sur la carte
- Calcul automatique du nombre d'éléments nécessaires en fonction de la longueur de la polyligne
- Saisie d'informations chronologiques pour les parcours (date et heure de début, vitesse la plus rapide et la moins rapide)
- Affichage chronologique des équipements sur la carte entre le début et la fin de la manifestation (défilement pas à pas)
- Possibilité de filtrer les équipements par type (ex. ne voir que les barrières Héras)
- Possibilité d'ajouter des points d'attention sur la carte (symbole ! avec une description associée, pas de notion de temps pour ces éléments)
- Affectation d'éléments de sécurité à une équipe, associés à une action (pose ou dépose)
- Génération d'un planning par équipe (PDF)
- Récupération d'un planning sur l'application mobile
Cette version vient compléter le prototype précédent en ajoutant les fonctionnalités nécessaires pour obtenir une première version exploitable de l'outil. Pour cela, il convient d'ajouter la possibilité de s'authentifier de manière sécurisée, de sauvegarder différents projets d'événements et d'enregistrer les informations chronologiques de pose et dépose des équipements liés aux points à sécuriser.
- Authentification via login/mot de passe sécurisé pour accéder à l'application compte admin créé à l'installation (le mot de passe est demandé lors de l'installation)
Gestion des personnels
- création, modification, suppression d'une personne (nom, prénom)
- création, modification, suppression d'une équipe (numéro, nom, liste des membres)
Gestion des projets d'événement
- création, modification, suppression d'un projet d'événement, identifié par un nom, une date et un ensemble de géométries permettant de le décrire (zone de couverture, tracé de la course, etc.)
- sauvegarde des projets dans un format sécurisé non lisible hors de l'application
- sélection et visualisation d'un projet existant
- modification du projet sélectionné (ajout de point d'intérêt, modification, déplacement, suppression, récupération de nouveaux points via mobile, etc.)
Gestion des points à sécuriser
- ajout d'indications temporelles liée à un point (dates et heures prévues de pose et de dépose)
- affichage chronologique (listes) des points à sécuriser (une liste de pose et une liste de dépose)
- Affectation du mobile à un projet d'événement via QRCode sur l'application lourde (transfert des informations globales sur le projet)
- Visualisation des géométries liés au projet courant
- Fonctionnalités de la v0 : saisie de points, géolocalistation, transfert vers l'application lourde
Cette version constituera un prototype permettant de valider les choix technologiques (notamment sur les outils de cartographie et d'export des fichiers Excel).
Attention : les applications ne doivent pas dépendre d'une connexion internet, toutes les ressources doivent être disponibles localement
- affichage d'une carte offline de Strasbourg
- navigation
- recherche d'une adresse ou d'un lieu
- placement sur la carte d'un type équipement sélectionné dans une liste de choix (barrière, bloc béton, etc.) en indiquant le nombre d'éléments de ce type placés
- export possible des informations au format Excel (à définir avec le client)
- génération d'un fichier PDF pour impression de la carte avec les informations pertinentes
- affichage de sa position actuelle
- enregistrement d'un point d'intérêt (coordonnées GPS + commentaire textuel + photos)
- affichage et ordonnancement de la liste des points d'intérêt
- simulation d'un déplacement ordonné dans la liste des points d'intérêt (détection automatique de l'arrivée à un point puis guidage vers le suivant)
- Un pipeline d'intégration continue doit être mis en place pour l'application web avec GitLab CI permettant de la builder, de la tester et d'analyser la qualité du code.
- Un commit n'est validé que si son nom est conforme à Conventional Commits.
- Le code TS/JS est vérifié à chaque push, mais l'échec est toléré.
- Les tests unitaires sont réalisés à chaque push, et il est exigé qu'ils passent.
- Les tests (linting et tests unitaires) ne sont réalisés que si un fichier de code a changé.
- La couverture de code est affichée dans le readme.
- Un backup des branches des features (non protégées contre les pushs directs) est réalisé tous les soirs et envoyé vers un dépôt privé distant.
- Concevoir une image docker conteneurisant votre application web et qui puisse être déployée rapidement et facilement.
- Trouver (ou concevoir) une solution technique permettant d'automatiser complètement l'intégration des modifications et le déploiement de votre application.
- Ce déploiement automatique doit s'effectuer dès qu'une nouvelle version stable est disponible.
- Installer les dépendances (au premier run) :
./docker.sh install- Configurer l'environnement de l'API :
cp api/.env.example api/.env- Construire l'image Docker :
./docker.sh build
- Tester (optionnel) :
./docker.sh test
- Déployer :
./docker.sh deploy
- Vérifier :
./docker.sh status
- Accéder à l'application :
- Client : http://localhost:3000
- API : http://localhost:4000
- Gestion de l'application :
./docker.sh logs
./docker.sh stop
./docker.sh clean
./docker.sh prune
Description de l'image Docker obtenue :
- Build multi-stage (Node.js 22-alpine)
- Taille (API + client lourd) : 887Mo
- Tuiles + données OSM (fonctionnement offline), montées en bind mount
tinipour gérer les signaux