Pour coder et tester votre code, vous allez avoir besoin d'une instance (à peu près) fonctionnelle de TiBillet sur votre ordinateur.
Vérifions que vous avez l'outillage requis sous la main. Vous avez besoin de :
docker-compose,git,docker-compose. S'installe super facilement icigitA partir de la, vous avez le choix entre deux chemins :
Vous pouvez même faire les deux, pour un effet maximal !
On va commencer en créant un dossier qui contiendra les différents dépôts requis à sa racine, dans votre dossier de travail par exemple. Ça ressemblera à :
tibillet-dev
├── Fedow
├── LaBoutik
├── Lespass
├── Test-Driven-Development
└── Traefik
| Nom | Environnement cible | Nullable | Valeur par défaut | Notes |
|---|---|---|---|---|
SECRET_KEY | Tous | Non | Une des clés secrètes Django générées précédemment | |
FERNET_KEY | Tous | Non | Une des clés Fernet générées précédemment | |
DOMAIN | Tous | Non | laboutik.tibillet.localhost | À adapter à votre nom de domaine et sous-domaine en production |
FEDOW_URL | Tous | Non | https://fedow.tibillet.localhost/ | URL du moteur Fedow |
LESPASS_TENANT_URL | Tous | Non | https://lespass.tibillet.localhost/ | URL de l'instance Lespass |
TIME_ZONE | Tous | Non | Europe/Paris | Plage horaire TZ de l'instance |
ADMIN_EMAIL | Tous | Non | Email administrateur (pour le⋅a premier⋅e admin) | |
MAIN_ASSET_NAME | Tous | Non | Le nom de votre unité de valeur cashless (Piécette, CoeurDor… comme vous voulez) | |
POSTGRES_DB | Tous | Non | laboutik | À changer en production si nécessaire |
POSTGRES_USER | Tous | Non | laboutik_user | À changer en production |
POSTGRES_PASSWORD | Tous | Non | Mot de passe fort (une des clés Fernets par exemple) | |
EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD | Tous | Oui | Serveur d'email, requis pour confirmer des abonné⋅es par exemple | |
BORG_PASSPHRASE | Tous | Oui | Mot de passe utilisé pour la sauvegarde des données | |
DEBUG | Développement | Non | 0 | Passer à 1 pour le développement |
TEST | Tests | Non | 0 | Passer à 1 pour les tests |
DEMO | Développement, Tests | Non | 0 | Passer à 1 pour une simulation de terminal de caisse |
SENTRY_DNS | Développement, Tests | Oui | Sentry Debug pour le back-end | |
SENTRY_FRONT_DNS, SENTRY_FRONT_ASSET | Développement, Tests | Oui | Sentry Debug pour le front-end | |
DEMO_TAGID_CM, DEMO_TAGID_CLIENT1, DEMO_TAGID_CLIENT2 | Oui | Aucune idée |
La configuration devrait être maintenant complète pour les trois moteurs.
Pour une raison… une raison, l'image Docker de dev est assemblée à partir des tests. L'installation est similaire au moteurs :
+Pour une raison de cohérence d'environnement, l'image Docker de dev est assemblée à partir des tests. L'installation est similaire au moteurs :
git clone git@github.com:TiBillet/Test-Driven-Development.git
cp Test-Driven-Development/env_example Test-Driven-Development/.env
C'est fait ☺️ On peut maintenant conteneuriser l'application entière depuis le dossier des tests :
docker compose up -d
Vous pouvez accéder en prime aux logs avec la commande :
docker compose logs -f
Ce docker-compose.yml en particulier s'appuie sur la structure décrite au début de l'installation, donc sur la structure du dossier parent aux tests, appelé pour l'exemple tibillet-dev. Contre-intuitif, mais maintenant vous savez 😉
La principale différence entre les conteneurs de dev et de prod, c'est qu'en dev la commande docker compose ne démarre pas les applications Django individuelles. C'est un niveau de contrôle fin qui est utile pour le développement, mais ça veut dire que vous avez besoin de les lancer manuellement.
La principale différence entre les conteneurs de dev et de prod, c'est qu'en dev la commande docker compose up ne démarre pas les applications Django individuelles. C'est un niveau de contrôle fin qui est utile pour le développement, mais ça veut dire que vous avez besoin de les lancer manuellement.
On va les lancer de préférence dans l'ordre :
Si tout marche comme prévu, félicitations : vous êtes prêt⋅es à vous lancer 🔧
Sinon, venez nous en parler, on est là pour aider !
N'oubliez pas de docker compose down à la fois dans les tests et dans Trafik quand vous avez fini votre session de travail. Votre ordinateur aussi a besoin de faire des pauses !
Si vous avez peur de ne pas vous en souvenir, enlevez l'option -d à compose up et la commande se lancera directement dans le terminal, pas en tâche de fond. C'est pas grave, vous aurez juste besoin de plus d'onglets 😋
Pour rester à jour durant le développement, télécharger l'image la plus récente :
-docker compose pull
docker compose up -d # démarrer ou redémarrer les conteneurs
Pour rester à jour durant le développement, pensez à télécharger les images les plus récente et/ou à builder les images django :
+docker compose pull
docker compose up -d --build # démarrer ou redémarrer les conteneurs
Vous pouvez lancer les tests Python de la même façon que pour un démarrage manuel. Commencez par réinitialiser les trois app Django pour obtenir les données testables, puis lancez cette commande depuis votre conteneur Django LaBoutik :
./manage.py test
Avant de vous attaquer à un changement majeur, sauvegardez toute donnée qui a de la valeur pour votre développement. Sur votre instance Fedow, par exemple, il suffit de sauvegarder le dossier database régulièrement. Les autres moteurs peuvent être sauvegardés par l'utilitaire Borgbackup, des tâches cron et des dump de bases de données. Plus sur ce sujet à l'avenir.