# Partie 3 — DevOps (infrastructure, déploiement, exploitation)

## Infrastructure as Code

`docker-compose.yml` décrit l'état désiré de l'infrastructure complète :
7 services (caddy, flask, mariadb, keycloak, keycloak-db, mattermost,
mattermost-db), 1 réseau interne (`gesthub-net`), 7 volumes persistants.
Seul `caddy` publie des ports (80/443) — tous les autres services
communiquent uniquement via le réseau Docker interne (vérifié par le test
automatisé TS-06, qui parse le fichier et échoue si un autre service
déclare une clé `ports`).

## Procédure de déploiement

```bash
git clone <repo>
cd gesthub
cp web/.env.example web/.env   # renseigner les secrets réels
docker compose up -d --build
docker compose logs -f flask   # vérifier le démarrage
```

**Avant / après** (réingénierie de processus, Bloc 2 — C2) :

| | Avant (mai 2025) | Après |
|---|---|---|
| Déploiement | Copie manuelle SSH, redémarrage serveur | `docker compose up -d` |
| Durée | 30 à 60 min | < 5 min |
| Reproductibilité | Dépend de la mémoire de l'opérateur | Totale (fichier versionné) |

## Procédure de mise en exploitation (checklist TD)

| ID | Vérification | Méthode |
|---|---|---|
| TD-01 | Tous les conteneurs sont `Up` | `docker compose ps` |
| TD-02 | Healthcheck MariaDB au vert | `docker compose ps` (colonne STATUS) |
| TD-03 | HTTPS répond (redirection HTTP→HTTPS) | `curl -I https://dashboard.ninolbt.com` |
| TD-04 | SSO Keycloak fonctionnel | Connexion manuelle de bout en bout |
| TD-05 | Persistance des données après redémarrage | `docker compose restart mariadb` puis vérification des annonces existantes |
| TD-06 | Sauvegarde exécutable | `scripts/backup.sh` en mode manuel, vérification de l'archive produite |

**[⇒] Projection méthodologique — procédure ITIL complète.** Cette
checklist couvre les principes ITIL de base (prérequis vérifiés,
environnement de test avant production, liste de contrôle, rollback
possible via `docker compose down` + restauration du dernier backup) mais
n'a pas fait l'objet d'une signature formelle d'un « bon à intégrer » ni
d'un PV de recette signé par un tiers, faute de contexte client réel sur ce
projet personnel. En entreprise, ces deux documents formaliseraient
l'accord du responsable d'exploitation et du Product Owner avant bascule en
production.

## Scripts d'exploitation

- `scripts/backup.sh` : dump MariaDB (`mysqldump` + gzip) et archive des
  fichiers uploadés, purge des sauvegardes de plus de 30 jours, prévu pour
  être planifié via cron.
- `web/init.sql` : création automatique du schéma au premier démarrage du
  conteneur MariaDB (monté sur `/docker-entrypoint-initdb.d/`).

## Réutilisation plutôt que réimplémentation (Bloc 2 — C6)

Bibliothèques et outils intégrés tels quels plutôt que réécrits :
**Authlib** (protocole OIDC), **PyMySQL** (connecteur MariaDB),
**python-magic** (détection MIME), **Mattermost** (chat + Kanban complet,
avec SSO partagé) — décision explicite de ne pas réinventer un outil de
chat/Kanban alors qu'une solution mature et intégrable existe.