---
name: project_release_deploy
description: ~/sync.sh génère un tar.gz de release (git archive HEAD) dans releases/ ; c'est le pont vers le serveur AlmaLinux de prod
metadata:
  type: project
---

`~/sync.sh dhcpman` fait DEUX choses : (1) rsync miroir du projet vers `192.168.1.2`
(cf. [[project_sync_ip]]), et (2) si le commit HEAD a changé, il génère une **archive de
release** dans `releases/` via `git archive HEAD | gzip` :
- une archive horodatée `dhcpman-AAAAMMJJ-HHMM-<commit>.tar.gz`
- une copie stable `dhcpman-current.tar.gz`

**À quoi sert le tar.gz :** c'est la release déployable. `git archive` produit un instantané
propre au commit courant (sans `.git`, sans fichiers ignorés). Le **déploiement sur le serveur
AlmaLinux de prod** se fait en récupérant `dhcpman-current.tar.gz` et en le décompressant côté
serveur. C'est le SEUL pont documenté entre le poste de dev et la prod AlmaLinux — il n'existe
aucun script de déploiement direct vers l'AlmaLinux dans le repo.

**Piège :** `git archive` archive **HEAD**, pas `master`. Si HEAD est sur une branche de
feature, la release `current` reflète cette branche. Pour ne publier une feature en prod
qu'après fusion, fusionner dans `master` (donc HEAD=master) AVANT le sync qui régénère `current`.

**Ne rien changer à ~/sync.sh** — il fonctionne, l'utilisateur ne veut pas y toucher.

**Rappel des deux modes de l'appli** (indépendant du déploiement) : AlmaLinux (prod, API Kea
directe + config-reload) vs FreeBSD/lab (via kea-sync-from-db.py). Le serveur maison de test
est en mode lab ; il n'exerce PAS le chemin config-reload de l'API Kea AlmaLinux.