# 📦 I. Déploiement de Terra Partus
**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 :
- 🧪 **Développement local (`dev`)**
- 🧪🧪 **Préproduction / Staging (`staging`)**
- 🚀 **Production (`prod`)**
Chaque section précise les étapes nécessaires en cas de mise à jour de code, de configuration, de secrets, ou d’infrastructure.
## 🧪 1. Développement (`dev`)
### ✔️ 1.1. Étapes de développement local
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 :
#### 1.1.1 Via PyCharm:
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.
##### 1.1.1.1 **🔄 Mettre à jour la branche `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`).
##### 1.1.1.2. **🌿 Passer sur votre branche de travail**
- Si vous n’êtes pas encore sur votre branche :
- **Clic droit sur votre branche → `Checkout`**
- ⚠️ Si vous avez des modifications non enregistrées :
- Commitez-les d’abord (voir étape suivante) pour éviter tout conflit ou perte.
##### 1.1.1.3. **💾 Committer vos modifications en sécurité**
1. Ouvrir le panneau `Version Control` avec l’icône `-o-` (ou raccourci `Alt+0`)
2. Dans l’onglet `Local Changes` :
- Cochez les fichiers à inclure
- (Optionnel) Double-cliquez pour visualiser les différences
3. Rédigez un message de commit clair
4. Cliquez sur **`Commit`**
💡 *Il est recommandé de faire des **commits atomiques** : un commit par changement logique (ex: correction de bug, ajout d’une feature, refactor CSS, etc.).*
##### 1.1.1.4. **🔀 Fusionner `main` dans votre branche**
- Dans le menu des branches (en bas à droite ou dans `Git > Branches`) :
- **Clic droit sur `main` → `Merge into current`**
PyCharm proposera une interface pour résoudre les conflits s’il y en a.
##### 1.1.1.5. **✅ Résumé rapide**
| É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 |
##### 1.1.1.6. **🔒 Astuce sécurité :**
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.
---
#### 1.1.2. En ligne de commande git:
##### 1.1.2.1. **🔄 1. S'assurer que la branche `main` est à jour**
git checkout main
git pull origin main
##### 1.1.2.2. **🌿 2. Revenir sur votre branche de travail**
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"
##### 1.1.2.3. **🔁 3. Fusionner `main` dans votre branche**
git 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
##### 1.1.2.4. **🚀 4. Pousser vos changements (optionnel)**
git push origin nom-de-votre-branche
##### 1.1.2.5. **✅ Résumé**
| É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` |
##### 1.1.2.6. **💡 Bonnes pratiques :**
* Faites des **commits fréquents et atomiques** pour chaque modification logique : 1 modification = 1 commit
* Toujours **tester et valider localement** avant de pousser
* Ne jamais faire de `merge` si vous avez des fichiers modifiés non enregistrés (`git status` est votre ami)
---
### 1.2 Faire tourner le serveur de dev django
- Assurez vous :
- d'avoir votre base de donnée qui tourne
- 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
### 1.3 📂 Fichiers à surveiller
* `pyproject.toml`, `poetry.lock` : dépendances
* `.env.local` : secrets et variables spécifiques au dev
* `settings/local.py` ou `config/settings/dev.py`
* `docker-compose.override.yml` (si existant)
### 1.4. 🧪 Tests à réaliser
* Tests Django (`pytest`, `coverage`)
* Affichage UI dans les navigateurs récents
* Vérification Dropzone, Leaflet, pages notaires/parcelles
* Formsets + onglets Bootstrap
* Traduction i18n active (`LANGUAGE_CODE`, `LOCALE_PATHS`)
---
## 2. 🧪🧪 Préproduction / Staging
Utilisé pour tester l'intégration complète avant passage en production.
### 2.1. 🔁 Workflow standard
# Étapes
git checkout staging
git merge feature/ma-fonctionnalité
poetry install
make test
make build-docker
docker-compose up -d --build
### 2.2. ✅ Check avant push vers `staging`
* [ ] Code review effectuée
* [ ] Tous les tests passent (`make test`)
* [ ] Dockerfile fonctionnel (`make build-docker`)
* [ ] Fichier `.env.staging` à jour
* [ ] Secrets mis à jour si besoin via `settings/staging.py`
### 2.3. ⚙️ Fichiers sensibles à surveiller
| 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é |
---
## 3. 🚀 Production (`prod`)
⚠️ Déploiement **manuel ou automatique via CI/CD GitLab**. Toujours effectuer d’abord en **staging**.
### 3.1 ✅ Checklist avant merge sur `main`
* [ ] Le merge sur `staging` est validé
* [ ] `git diff` sur :
* `.gitlab-ci.yml`
* `pyproject.toml`
* `Dockerfile`
* `settings/production.py`
* `poetry.lock`
* Fichiers `*.env` (via vault)
* [ ] Revue du pipeline GitLab (jobs `build`, `test`, `deploy`)
* [ ] `make migrate` appliqué sur staging
### 3.2. 🔁 Pipeline de prod (CI GitLab)
* **Trigger** sur `main` après merge
* **Étapes** :
* Lint & tests
* Build docker
* Push registry
* Déploiement via SSH ou runner
* Restart gunicorn + collectstatic + migrate
### 3.3. 📄 Configuration critique à surveiller
| 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 |
### 3.4. 🔒 Secrets sensibles
* Stockés dans les variables GitLab CI/CD
* Chargés automatiquement par Docker via `env_file`
* Ne jamais pousser `.env.production`
---
## 4. 🛠️ En cas de modifications spécifiques
### 4.1. 🔧 Modif `.gitlab-ci.yml`
* Vérifier que tous les jobs `build`, `test`, `deploy` fonctionnent
* Si des images Docker sont utilisées → vérifier `image:` et `before_script:`
### 4.2. 🧪 Modif `Dockerfile`
* Rebuild avec `make build-docker`
* Tester manuellement avant merge
### 4.3. 🔐 Modif `.env*` ou variables
* Ajouter les variables dans GitLab CI/CD (`Settings > CI/CD > Variables`)
* Jamais dans le dépôt Git
### 4.4. 🧬 Modif des settings (`config/settings/*.py`)
* Adapter le fichier `staging.py` ou `production.py`
* Ne pas toucher à `base.py` sauf nécessité
* Relancer le serveur après modification
### 4.5. 🧾 Modif des dépendances
poetry add nom-du-paquet
poetry lock
git commit -am "ajout de X"
---
## 5. 📌 Notes complémentaires
* Toujours faire un `rebase` avant un merge vers `main`
* Le dossier `media/` est monté via S3 (OVH) — vérifier la synchronisation si changement de backends
* Les fichiers statiques sont collectés via `collectstatic` après chaque déploiement