Prérequis : Vous devez avoir déjà installé Terra Partus sur votre PC - voir ici ()
Ce guide décrit les procédures de déploiement pour les environnements suivants :
dev)staging)prod)Chaque section précise les étapes nécessaires en cas de mise à jour de code, de configuration, de secrets, ou d’infrastructure.
dev)Depuis une console ou sur PyCharm toujours mettre à jour sont git local
git pull
Ensuite s'il y a eu des merge sur la branche main, votre branche de "travail" n'est plus synchro avec la branche main, il faudra la mettre à jour :
Ce guide décrit les étapes à suivre dans PyCharm pour mettre à jour votre branche de travail avec la dernière version de main, tout en évitant les conflits ou la perte de modifications.
main (pull)Dans le panneau Git ou via le menu contextuel des branches :
- Faites un clic droit sur main → Update
Cela récupère les dernières modifications depuis GitHub (git pull).
CheckoutVersion Control avec l’icône -o- (ou raccourci Alt+0)Local Changes :
- Cochez les fichiers à inclure
- (Optionnel) Double-cliquez pour visualiser les différencesCommit💡 Il est recommandé de faire des commits atomiques : un commit par changement logique (ex: correction de bug, ajout d’une feature, refactor CSS, etc.).
main dans votre brancheGit > Branches) :main → Merge into currentPyCharm proposera une interface pour résoudre les conflits s’il y en a.
| Étape | Action |
|---|---|
| 1 | Update la branche main |
| 2 | Checkout votre branche |
| 3 | Committer vos modifications locales |
| 4 | Merge 'main' into votre-branche |
| 5 | Résoudre les conflits si nécessaire |
Avant toute opération de merge, committez vos changements pour éviter de les perdre.
Une fusion n’annule pas une perte de modifications non enregistrées.
main est à jourgit checkout main
git pull origin main
git checkout nom-de-votre-branche
⚠️ Avant de continuer, assurez-vous que vos fichiers modifiés sont commités :
git status
S’il y a des fichiers non suivis ou modifiés, vous pouvez les committer :
git add chemin/fichier.py
git commit -m "Votre message de commit"
main dans votre branchegit merge main
Si des conflits apparaissent, Git vous les signalera. Utilisez votre éditeur ou PyCharm pour les résoudre, puis :
git add fichiers-concernés
git commit # pour valider la résolution des conflits
git push origin nom-de-votre-branche
| Étape | Commande |
|---|---|
1. Mettre main à jour |
git checkout main + git pull |
| 2. Revenir sur votre branche | git checkout ma-branche |
| 3. Fusionner | git merge main |
| 4. Résoudre les conflits | git add + git commit |
| 5. Pousser si besoin | git push origin ma-branche |
merge si vous avez des fichiers modifiés non enregistrés (git status est votre ami)d'avoir votre serveur redis qui tourne
Lancer le serveur local python manage.py runserver
Appliquer les migrations python manage.py migrate
Lancer les tests unitaires python manage.py test
pyproject.toml, poetry.lock : dépendances.env.local : secrets et variables spécifiques au devsettings/local.py ou config/settings/dev.pydocker-compose.override.yml (si existant)pytest, coverage)LANGUAGE_CODE, LOCALE_PATHS)Utilisé pour tester l'intégration complète avant passage en production.
# Étapes
git checkout staging
git merge feature/ma-fonctionnalité
poetry install
make test
make build-docker
docker-compose up -d --build
stagingmake test)make build-docker).env.staging à joursettings/staging.py| Type | Fichier | Étapes si modifié |
|---|---|---|
| CI/CD GitLab | .gitlab-ci.yml |
Vérifie les runners, les variables d'environnement |
| Dépendances | pyproject.toml |
poetry install + rebuild docker |
| Variables | .env.staging |
Relancer les containers |
| Secrets | settings/staging.py |
Mettre à jour le vault ou les ENV GitLab |
| Docker | Dockerfile, docker-compose.yml |
make build-docker obligatoire |
| Gunicorn | gunicorn.conf.py ou équivalent |
Redéploiement manuel si modifié |
prod)⚠️ Déploiement manuel ou automatique via CI/CD GitLab. Toujours effectuer d’abord en staging.
mainstaging est validé[ ] git diff sur :
.gitlab-ci.yml
pyproject.tomlDockerfilesettings/production.pypoetry.lock*.env (via vault)build, test, deploy)make migrate appliqué sur stagingmain après mergeÉtapes :
Lint & tests
| Fichier | Impact | Action |
|---|---|---|
.gitlab-ci.yml |
Pipeline | Relire entièrement les jobs |
Dockerfile |
Build | Tester en local ou staging |
gunicorn.conf.py |
Performance | Redémarrer le service |
poetry.lock |
Dépendances exactes | Garder aligné avec pyproject.toml |
.env.production |
Secrets | Ne jamais versionner, stocker dans GitLab ENV |
env_file.env.production.gitlab-ci.ymlbuild, test, deploy fonctionnentimage: et before_script:Dockerfilemake build-docker.env* ou variablesSettings > CI/CD > Variables)config/settings/*.py)staging.py ou production.pybase.py sauf nécessitépoetry add nom-du-paquet
poetry lock
git commit -am "ajout de X"
rebase avant un merge vers mainmedia/ est monté via S3 (OVH) — vérifier la synchronisation si changement de backendscollectstatic après chaque déploiement