Des conférences téléphoniques pour les agents de l'Etat.
L'environnement de développement est préconfiguré pour Visual Code. Pour profiter de l'intégration avec ESLint, il faut installer le plugin du même nom.
Demander à vos collègues les identifiants pour générer la clé sur ce lien : https://eu.api.ovh.com/createToken/ Pour créer le token, il faut :
OVH_ROOM_ACCOUNT_NUMBER: il est de la formeaa1111111-ovh-1. L'account ID à renseigner doit êtreaa1111111-ovh- Password : à récupérer auprès de vos collègues
- Script name : Local ton nom
- Script description : Local ton nom
Avec OVH_ROOM_ACCOUNT_NUMBER à demander à vos collègues
POST /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/*
PUT /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/*
GET /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/*
Installer et lancer postgres et maildev en local, ensuite:
cp .env.sample .env. Remplir le fichier avec les configurations obtenues par OVHnpm installnpm run migratenpm run dev
cp .env.sample .env.conferences.dev. Remplir le fichier avec les configurations obtenues par OVH- Récupérer les dépendences :
docker-compose run -u root web npm install - Créer les tables de la DB :
docker-compose run web npm run migrate - Lancer le service :
docker-compose upoudocker-compose run -p 8080:8080 web npm run dev
Pour consulter les mails envoyés avec Docker, se connecter à l'adresse http://localhost:1080
Vous devriez normalement voir dans les logs ceci :
CoucouCollègues listening at http://localhost:8080
docker-compose run web npm test
npm test
- Se connecter sur http://localhost:8080
- Remplir son adresse mail et son horaire
- Consulter le http://localhost:1080/#/ pour voir l'email envoyé par le service
KnexJS permet de créer des migrations de base de données. Un shortcut a été ajouté au package.json pour créer une migration :
npm run makeMigration <nom de la migration>
Une fois la migration créée, vous pouvez l'appliquer avec :
npm run migrate
Pour utiliser d'autres commandes, le CLI de KnexJS est disponible avec ./node_modules/knex/bin/cli.js. Par exemple, pour faire un rollback :
./node_modules/knex/bin/cli.js migrate:rollback
cd locustdocker-compose up --scale worker=8(8 c'est pour 8 CPU)- Ouvrir http://localhost:8089/
npm run checkHTML -- <url du site à tester>
Si on veut checker pour une PR donnée, utiliser l'url de la review app de la PR (voir les checks dans la PR).
Pour valider le code en local :
npm run checkHTMLLocal
Pour afficher des annonces de service (maintenance, formulaire, ...), on utilise la variable d'environnement ANNOUNCEMENTS (voir .env.sample ou le fichier docker-compose) qui peut être configurée sur l'hebergeur Scalingo. Elle permet d'afficher de l'HTML ou du texte.
Le système de session est in memory. Dans un environnement à plusieurs containers web, cela peut poser des problèmes.
Comme la production est dans ce cas, il faut activer les sticky sessions.
Bien vérifier donc qu'ils sont activés (dans Scalingo > Settings).
- Total de réservation par nom de domaine :
select substring(email from '@[^@]*$') as domain, count(*) from conferences group by domain order by count DESC; - Nombre de réservations par durée de réservation :
SELECT "durationInMinutes" , count(*) as count from conferences GROUP BY "durationInMinutes" ORDER BY count DESC; - Nombre de réservations annulées :
SELECT "canceledAt" IS NOT NULL as canceled, count(*) from conferences GROUP BY canceled;### Configuration OVH de Prod
Points d'API nécessaires pour les fonctionalités actuelles, pour l'API Rooms :
POST /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/rooms
PUT /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/rooms/*
GET /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/roomsStats
Pour le job qui récupère les stats :
GET /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/histories
GET /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/histories/*
Pour le job qui récupère le web access:
POST /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/rooms/*/webAccess
Pour le dashboard
POST /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${phoneNumber}/rooms/${roomNumber}/*
GET /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${phoneNumber}/rooms/${roomNumber}/participants
GET /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${phoneNumber}/rooms/${roomNumber}/participants/${id}
POST /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${phoneNumber}/rooms/${roomNumber}/participants/${id}/*
Création des confs
Les appels que nous faisons à l'API OVH sont les suivants :
- Créer une conférence :
POST /telephony/${OVH_ROOM_ACCOUNT_NUMBER}/conference/${OVH_ROOM_PHONE_NUMBER}/rooms
L'API retourne le code d'accès de la conférence (roomNumber).
- Configurer la conférence créée :
PUT /telephony/${config.OVH_ROOM_ACCOUNT_NUMBER}/conference/${config.OVH_ROOM_PHONE_NUMBER}/rooms/${roomNumber}
On fait ce deuxième appel API pour enlever le PIN qu'on utilise pas et ajouter une date d'expiration à la conférence.
Obtenir des stats sur les confs
- Obtenir des stats sur les conférences actuellement en cours :
GET /telephony/${config.OVH_ROOM_ACCOUNT_NUMBER}/conference/${config.OVH_ROOM_PHONE_NUMBER}/roomsStats
On récupère des stats sur les confs actuellement en cours, dont : le nombre de conférences réservées (bookedRoomsCount), le nombre d'appels actuellement en cours (activeConfsCount), le nombre total de participants en ligne dans ces appels (onlineParticipantsCount).
On utilise également cet appel dans la page de status, pour vérifier que la connection à OVH marche toujours (si cet appel répond bien, on considère qu'on est bien connectés).
-
Obtenir la liste des confs passées :
GET /telephony/${process.env.OVH_ACCOUNT_NUMBER}/conference/${phoneNumber}/histories -
Obtenir l'historique d'une conf passée donnée :
GET /telephony/${process.env.OVH_ACCOUNT_NUMBER}/conference/${phoneNumber}/histories/${callId}
La mise en prod est faite à la main pour le moment.
Procédé basique :
- On crée une branche release:
git checkout main
git pull
git checkout -B release/X.Y.Z
- On incrémente le numéro de version dans package.json et on commit dans la branche de release.
- On crée une PR de cette branche de release vers la branche
prod, la PR est testée par la CI. - On crée une release sur github (https://github.com/betagouv/audioconf/releases/new) en décrivant les modifications apportées par cette release. Ce process crée un tag sur le commit de la release.
- Quand on merge la PR, la branche prod est déployée automatiquement sur scalingo.
- Créer ensuite une PR depuis
prodversmain, pour récupérer le numéro de version et les éventuelles modifs de test.
Les PR sont nécessaires car les branches prod et main sont protégées, on ne peut pas push directement dessus.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
