Jour 12 - Déployer ton blog Symfony en production proprement

Tu peux avoir un super blog local, mais la vraie valeur arrive quand la prod est stable et maintenable.

On termine la série avec un process de déploiement simple, clair et répétable.

Objectif d’apprentissage

Livrer un déploiement production fiable avec des commandes claires, des logs exploitables et un plan de secours.

Ce que tu vas pratiquer aujourd’hui

• Préparer les variables d’environnement prod.
• Déployer avec migrations + warmup cache.
• Vérifier la santé applicative après release.
• Superviser les erreurs et garder un rollback possible.

1. Préparer une checklist de release

Ne déploie jamais “à l’aveugle”. La checklist évite les oublis critiques (env, migration, droits, cache).

Documente aussi le point de retour arrière.

php bin/console doctrine:migrations:migrate --no-interaction
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod
php bin/console app:homepage:bootstrap --env=prod

2. Vérifier les endpoints clés après déploiement

Teste les pages critiques immédiatement après release: homepage, blog, login admin, healthcheck.

Une vérification simple peut t’éviter une panne longue.

curl -I https://lemoncef.fr/
curl -I https://lemoncef.fr/blog
curl -I https://lemoncef.fr/admin/login
curl -I https://lemoncef.fr/healthz

3. Mettre en place une supervision basique mais solide

Installe des outils simples: monitoring système et checks HTTP. C’est largement suffisant pour une petite prod sérieuse.

Ajoute aussi une lecture des logs applicatifs par niveau de sévérité.

# Exemples de commandes utiles sur VPS
df -h
free -m
journalctl -u apache2 -n 100 --no-pager
tail -n 200 var/log/prod.log

Checklist de fin de session

• Déploiement exécuté avec migrations et cache.
• Checks HTTP critiques validés.
• Monitoring système actif.
• Logs applicatifs consultables rapidement.

Erreurs fréquentes à éviter

• Sauter la vérification finale parce que “ça marche chez moi”.
• Mélanger trop de logique dans le controller au lieu de garder un flux clair.
• Oublier la cohérence entre la donnée, le template Twig et le comportement en production.

Pourquoi cette étape compte en conditions réelles

Dans un vrai projet client, chaque étape technique doit rester compréhensible par l’équipe, duplicable sur un autre environnement et fiable dans le temps. Ici, l’objectif est de transformer la théorie en un flux de travail concret, avec des décisions simples que tu peux défendre en revue de code.

Si tu appliques sérieusement les points du jour (préparer les variables d’environnement prod.), tu réduis la dette technique dès le départ et tu facilites la suite: SEO, publication, maintenance et déploiement. C’est exactement la différence entre un blog “démo” et un blog exploitable en production.

Mini plan de révision

• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Préparer les variables d’environnement prod.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Déployer avec migrations + warmup cache.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Vérifier la santé applicative après release.

Exercice rapide

Écris ton propre runbook “incident prod” en 10 lignes: qui fait quoi, quelles commandes, quel plan rollback.

Et demain ?

Bravo. Tu as maintenant une série complète pour construire, publier et exploiter un blog Symfony + Twig en conditions réelles.