Prépare un déploiement reproductible, sécurisé et réversible

01Crée le dossier de changement

change-glpi-001/
├── 01-scope.md
├── 02-prerequisites.md
├── 03-architecture.md
├── 04-installation-record.md
├── 05-acceptance-tests.md
├── 06-backup-restore.md
├── 07-rollback.md
└── evidence/

Le dossier doit permettre à une autre personne de comprendre ce qui a été préparé, exécuté et vérifié.

02Valide les prérequis

[ ] FQDN réservé
[ ] résolution DNS contrôlée
[ ] certificat TLS prévu
[ ] runtime et extensions compatibles avec la version choisie
[ ] base dédiée et encodage adapté
[ ] compte applicatif limité
[ ] répertoires persistants préparés
[ ] scheduler système défini
[ ] sauvegarde avant changement
[ ] fenêtre et responsable du changement

Les exigences exactes de runtime et les commandes d’installation doivent être relues dans la documentation de la version réellement déployée. Le cours ne fige pas une commande qui deviendrait fausse après une évolution du produit.

03Vérifie la provenance

Téléchargement
- source officielle ou miroir approuvé
- version explicitement choisie
- somme de contrôle ou signature lorsqu'elle est fournie
- archive conservée dans le dossier de changement
- aucune exécution directe d'un script récupéré sans lecture

Exemple générique de contrôle :

sha256sum glpi-package.tar.gz
sha256sum -c checksums.txt

La valeur attendue doit provenir d’un canal distinct et fiable, pas du même fichier téléchargé.

04Sépare configuration et secrets

Dans Git ou BookStack
- architecture
- noms de variables
- procédure
- exemple sans valeur sensible

Dans un secret store ou un fichier protégé
- mot de passe de base
- clé d'authentification
- secret SMTP
- identifiant d'annuaire

Ne place pas un secret dans une capture d’écran, un ticket, un export ou un historique Git sous prétexte qu’il sera supprimé plus tard.

05Définis les tests d’acceptation

Accès
[ ] HTTPS sans erreur
[ ] redirection HTTP contrôlée
[ ] compte administrateur d'urgence accessible
[ ] compte demandeur limité

Fonctionnel
[ ] création d'un utilisateur de test
[ ] création d'un actif de test
[ ] création et affectation d'un ticket
[ ] exécution récente des tâches automatiques

Exploitation
[ ] journaux accessibles
[ ] sauvegarde produite
[ ] restauration testée sur environnement isolé
[ ] version et plugins consignés

06Prépare le rollback avant l’installation

Déclencheurs de rollback
- erreur de migration ;
- perte de fonctions critiques ;
- incompatibilité plugin ;
- échec d'authentification généralisé ;
- corruption ou perte de données.

Moyens
- snapshot ou sauvegarde cohérente ;
- archive de la version précédente ;
- configuration précédente ;
- procédure de restauration testée ;
- décisionnaire identifié.

Un snapshot seul n’est pas une stratégie si personne ne sait vérifier le retour au service.

07Génère et contrôle le rapport

lab=/tmp/soria-glpi-foundations-$USER
bash module1-glpi-foundations.sh run "$lab"
cat "$lab/output/readiness-report.txt"
(cd "$lab" && sha256sum -c evidence/checksums.sha256)

Le checksum protège le dossier de preuves contre une modification silencieuse après validation.

08Écris le journal d’installation

Date et heure
Opérateur
Version et source
Hôte cible
Commandes ou actions exécutées
Résultats observés
Écarts par rapport à la procédure
Tests réussis et échoués
Décision : poursuivre, corriger ou revenir en arrière