Déployer Symfony (et PHP métier en général) : je veux un artefact (ou un `composer install --no-dev` reproductible), des Doctrine migrations jouées une fois, un `cache:warmup`, un lien `current` atomique, un retour arrière. Pas de FTP de `vendor/`. Cet article décrit une procédure tenue (Deployer, CI, ou scripts), ce que la TMA surveille, et le lien avec Messenger (le worker oublié après deploy).
🚀 Ce que « déployer » veut dire
Une révision connue (git sha) arrive en prod, les migrations passent, le cache est neuf, le worker reprend, un smoke test (`/health`, login). Si ça rate, on re-pointe `current` vers l'ancienne release.
FTP + modifier un fichier en prod : la prochaine personne écrase. Ce n'est pas de la TMA. C'est de l'archéologie.
🗄️ Migrations
Doctrine se joue une fois, en deploy, pas à la main « j'ai oublié ». Une migration destructive a un plan. Les sauvegardes se restaurent (voir l'article dédié).
Les secrets hors dépôt. `.env.local` n'est pas dans le zip FTP du stagiaire.
- SHA déployé visible
- Migrations dans le script
- Rollback testé une fois
- Worker redémarré
👷 CI
Tests sur la branche, puis deploy. Même une CI minuscule évite le « ça marchait en local ». Voir TMA Symfony sans tout réécrire.
Déployer Symfony : ennuyeux, répétable. Si c'est excitant, c'est trop risqué.
↩️ Le retour arrière et la base
Re-pointer `current` ne défait pas une migration. Si la nouvelle version a supprimé une colonne, l'ancienne plante. Je découpe donc : d'abord ajouter (nouvelle colonne, code qui lit les deux), ensuite supprimer, dans un déploiement suivant.
Avant une migration lourde, une sauvegarde de la base, horodatée avec le SHA. Le rollback devient deux gestes connus : remettre l'ancienne release, restaurer si besoin. Pas une nuit à réécrire du SQL.
✅ Les étapes écrites pour un déploiement Symfony
On écrit l'ordre : construire, migrer, vider le cache, redémarrer les workers, vérifier. Chaque étape a une commande et un résultat attendu.
Sauvegarde de la base restaurable, accès à votre nom, tag de la version précédente. Puis 24 à 72 h de surveillance (erreurs, files, logs). Sans cette phase de suivi, un déploiement réussi peut cacher une régression silencieuse.
- Version précédente taguée et déployable
- Recette sur une copie de la production
- Une migration à la fois, relue
- Contrôle humain puis 24 h de suivi des logs
📌 Ce que je refuse sur ce sujet
Je refuse les déploiements à la main sans trace écrite. Je refuse les migrations lancées en production sans sauvegarde. Je refuse de livrer un vendredi soir sans rollback possible.
Je refuse aussi de me taire : si le vrai sujet est une application à réécrire ou un hébergement inadapté, je le dis. Cet article n'est pas un prétexte pour vendre un outil de plus.
Un déploiement sans rollback n'est pas une release. C'est un saut.
🧭 Questions fréquentes
Faut-il changer la méthode de déploiement tout de suite ? Oui si une mise en production se fait encore en FTP ou sans rollback possible. Sinon, planifiez l'automatisation avant la prochaine grosse évolution.
Peut-on déployer sans environnement de recette ? Pour une application qui sert des clients, non. Une copie de la production avec une base anonymisée attrape les migrations qui échouent avant qu'elles ne touchent les vraies données.
Combien de temps ? Une à deux journées pour écrire le script de déploiement, la vérification et la procédure de rollback. Un « pipeline en une heure » oublie les migrations et le cache.
