Une documentation détaillée de l'installation en local est disponible sur ONBOARDING.md.
git clone https://github.com/MTES-MCT/aides-territoires
cd aides-territoires
Pour faire tourner les tests :
cd src && make test
Note : certains tests utilisent Selenium qui dépend de geckodriver.
Pour les faire tourner, il conviendra donc d'en télécharger
la dernière version pour
l'intégrer dans son $PATH.
GeckoDriver s'attend à trouver Firefox installé.
# Firefox on debian
apt-get update
apt-get purge firefox-esr
Si geckodriver n'est pas trouvé automatiquement par pytest, il est possible de spécifier directement son emplacement en ajoutant une ligne comme
GECKODRIVER_PATH="/snap/bin/geckodriver"
au fichier .env.local
Avant chaque mise en production, les intervenant·es sont prié·es de passer cette liste en revue.
Le projet utilise Pipenv pour gérer les dépendances de paquets Python et produire des builds déterministes.
Pour installer les dépendances du projet :
pipenv install --dev
Pour installer un nouveau paquet et l'ajouter aux dépendances :
pipenv install <paquet>
Pour un paquet ne servant que pour le développement, e.g debug-toolbar :
pipenv install --dev <paquet>
Le projet utilise django-environ pour gérer les settings des différents environnements ne pouvant être embarquées dans le dépôt git.
Typiquement :
- configuration locale spécifique à chaque intervenant·e sur le projet, e.g paramètres de connexion à la base de données ;
- configuration de production.
Pour surcharger la configuration locale de développement, il est possible de
créer un fichier .env.local à la racine du projet Django. Cf. le fichier
.env.example pour l'exemple. Ce fichier est facultatif car
des paramètres par défaut sont définis.
En staging et en production, les variables d'environments sont spécifiées directement sur Scalingo.
Le projet utilise Le Système de Design de l'Etat pour faciliter le développement, proposer un rendu homogène.
Les intervenant·es sur le code sont donc *prié·es d'utiliser autant que possible les classes spécifiques au Système de Design de l'Etat dans le HTML.
Le projet utilise
django-compressor, une application
qui permet de gérer la pipeline de compression des fichiers statiques.
Django-compressor propose plusieurs modes de déploiement :
- la compilation / compression se fait manuellement une fois pour toute ;
- la compilation / compression se fait automatiquement à chaque requête.
Le premier mode de fonctionnement est adapté à un déploiement en production. Le second dans un environnement de développement.
Il faut noter que le second mode peut significativement dégrader les performances et ralentir le travail. Pour améliorer les performances, deux possibilités :
- Installer la version native de Sassc et pas
la version en pure js (sous Ubuntu:
sudo apt-get install sassc); - Désactiver en local la compression par requête dans le fichier
.env.local.
COMPRESS_OFFLINE=False
Il faudra alors manuellement lancer la compression en cas de besoin.
python manage.py compress
Nous utilisons Redis en production :
- Comme backend de cache pour Django
- Comme backend pour Django-Defender
- Comme broker pour Celery
En locale et pour les Review Apps, il n'y a généralement pas besoin d'utiliser Redis.
Il est cependant possible de le faire, avec la commande
sudo apt-get install redis-server sous Ubuntu)
Il faut alors également ajouter les valeurs suivantes dans le .env.local :
CACHE_BACKEND="django_redis.cache.RedisCache"
CACHE_LOCATION="redis://localhost:6379/0"
Note : les traductions ont été abandonnées et sont progressivement supprimées.
Ce project utilise le système de traduction de Django :
Le texte dans le code est en anglais et la traduction qui
s'affiche sur le site en Français, se trouve dans le fichier
.po du dossier locales.
https://docs.djangoproject.com/en/dev/topics/i18n/translation/
Pour générer la traduction dans le fichier .po :
make makemessages
Django utilise une version compilée du fichier .po, c'est le
fichier .mo que l'on obtient avec :
python manage.py compilemessages
En production, ce fichier est généré automatiquement lors du déploiement. Il n'est donc pas inclus dans le code github.
Nous utilisons pep8, ruff et black
Pour vérifier son code, on peut intégrer le linter adapté à son IDE et aussi faire ceci :
make checkstyle
En staging et en production, les variables d'environments sont spécifiées directement sur Scalingo.
Les emails transactionnels sont envoyés via SendingBlue.
Pour les environnements de Staging, il existe un mécanisme qui permet de n'envoyer les emails qu'à une liste restreinte d'adresses.
Cette "Whitelist" est définie dans les settings.
Pour connaître le fonctionnement historique de ce filtrage : #399
En local vous avez la possibilité de visualiser les emails dont le template n'est pas hébergé sur Brevo depuis le terminal. Pour ce faire la variable EMAIL_BACKEND doit être définie avec django.core.mail.backends.console.EmailBackend dans votre fichier .env.local
Alternativement, définir la variable EMAIL_BACKEND à emails.backends.WhitelistEmailBackend permet d’envoyer les emails aux adresses définies dans la liste blanche EMAIL_WHITELIST.
Nous utilisons un service d'« Object Storage » compatible avec l'API S3 pour le stockage de tous les fichiers medias.
Pour mettre en place la double authentification, il faut mettre ceci dans le
fichier .env ou dans les variables d'environnement Scalingo :
ADMIN_OTP_ENABLED=True
Ceci va activer une double authentification pour l'accès au site d'admin : mot de passe et jeton d'authentification. Le jeton d'authentification peut-être obtenu via une application mobile comme Google Authenticator ou Authy.
Lors de la première utilisation et avant d'activer la double authentification,
il faudra faire en sorte qu'un premier utilisateur admin puisse se connecter.
Pour cela, il faudra penser à créer un Device pour cet utilisateur initial,
avec le QR code associé qu'il faudra scanner avec l'application mobile.
Pour plus de détail : https://django-otp-official.readthedocs.io/en/stable/overview.html
Le site est actuellement hébergé sur Scalingo. Cf. la documentation d'infogérance.
Note : demander l'accès au moment de l'onboarding.