Un déploiement met en ligne une nouvelle version de votre code sur votre serveur. Vimonto Deploy clone votre branche dans un nouveau répertoire de release, y exécute votre script de déploiement, et seulement ensuite bascule le site en une seule étape atomique. Jusqu'à ce moment, les visiteurs continuent de recevoir la version précédente : un build raté ne met donc jamais votre site hors ligne.
Vous pouvez déployer avec un bouton, à chaque push sur votre branche, ou depuis votre CI avec une URL de déploiement. Les dernières releases restent sur le serveur : revenir à une version antérieure prend quelques secondes.
Comment fonctionne un déploiement sans interruption ?
Chaque site est organisé sur le disque pour les déploiements sans interruption :
/home/{user}/{directory}/
├── releases/
│ ├── 20261007141502/ one directory per deploy
│ └── 20261007153044/
├── shared/
│ ├── .env kept between releases
│ └── storage/ Laravel only
└── current -> releases/20261007153044
Nginx sert le site depuis current. Un déploiement exécute ces étapes, que vous pouvez suivre en direct :
| Étape | Ce qui se passe |
|---|---|
| Récupérer le code | La branche est clonée dans une nouvelle release nommée d'après la date et l'heure (un clone superficiel du dernier commit). Le hash du commit, son auteur et son message sont enregistrés. |
| Exécuter le script de déploiement | Le .env partagé est lié dans la release (ainsi que storage/ pour Laravel). Votre script de déploiement s'exécute ensuite dans la release, sous l'utilisateur du site. |
| Mettre en ligne | current est pointé vers la nouvelle release en un seul renommage atomique. PHP-FPM est rechargé pour qu'OPcache prenne en compte les nouveaux fichiers. |
| Nettoyer les anciennes releases | Les anciennes releases sont supprimées ; les cinq plus récentes sont conservées. |
Après la mise en ligne, Vimonto Deploy redémarre aussi ce qui exécute votre code : les queue workers Laravel reçoivent artisan queue:restart, les processus Node.js sont redémarrés, et chaque fonctionnalité de site activée exécute sa propre commande (par exemple horizon:terminate pour Horizon).
Lors du premier déploiement d'un site, si votre dépôt contient un .env.example, le .env est reconstruit à partir de celui-ci avant l'exécution du script de déploiement : les clés, l'ordre et les commentaires de l'exemple, complétés par les valeurs générées par Vimonto Deploy. Le log du déploiement l'indique, et l'historique du .env le conserve sous Construit sur .env.example. Cela ne se produit qu'une fois. Consultez environnement.
Chaque récupération lit aussi les paquets de votre composer.json et de votre package.json, afin que le menu des fonctionnalités de site puisse signaler les outils qu'utilise votre application.
Que se passe-t-il quand un déploiement échoue ?
Si la récupération ou le script de déploiement échoue, la nouvelle release est abandonnée et current n'est pas modifié. La page du déploiement affiche Le déploiement a échoué avec l'erreur et La version en ligne n'a pas changé. Ouvrez Détails et log pour voir la sortie de chaque étape, corrigez le problème et cliquez sur Redéployer.
Déployer maintenant
Cliquez sur Déployer maintenant dans l'en-tête du site, en haut de chaque page du site. Vous arrivez sur la page du déploiement, qui affiche les phases, l'étape en cours et la progression. Inutile de garder la fenêtre ouverte : le déploiement tourne sur le serveur, vous recevez un message dans l'application quand il est terminé, et un déploiement terminé ou échoué envoie aussi une notification. Pour envoyer aussi les résultats des déploiements d'un site vers votre propre endpoint ou d'autres adresses e-mail, configurez ses notifications de déploiement.
Un seul déploiement à la fois peut tourner par site. Si vous en lancez un autre pendant qu'un déploiement tourne, vous voyez Un déploiement est déjà en cours pour suivi du domaine.
Connecter ou changer le dépôt
Le panneau Dépôt affiche le dépôt, la branche et l'état de la Deploy key. Cliquez sur Connecter un dépôt ou Modifier pour choisir un dépôt chez un hébergeur Git connecté ou utiliser une URL Git personnalisée.
- Hébergeur Git connecté : la deploy key du site est enregistrée sur le dépôt comme deploy key en lecture seule, et retirée de l'ancien dépôt quand vous changez. Un dépôt nouvellement lié reçoit immédiatement Déployer à chaque push activé.
- URL Git personnalisée : utilisez une URL SSH (
git@…) pour un dépôt privé et ajoutez la clé affichée sous Clé de déploiement de ce site comme deploy key chez votre hébergeur Git. Utilisez une URL HTTPS pour un dépôt public. Déployer à chaque push est désactivé, car seul un hébergeur Git connecté peut recevoir un webhook de Vimonto Deploy.
Modifier le script de déploiement
Le panneau Script de déploiement contient le script Bash qui construit une release, dans un éditeur de code avec coloration syntaxique shell. Il démarre avec un script adapté à votre framework, que vous pouvez modifier librement et enregistrer avec Enregistrer (ou ⌘ S, Ctrl S). Le déploiement suivant l'utilise. Par défaut remet le script généré dans l'éditeur ; il n'est enregistré que lorsque vous cliquez sur Enregistrer.
Le script par défaut d'un site Laravel ressemble à ceci :
$VIMONTO_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader
if [ -f package.json ]; then
if [ -f package-lock.json ]; then npm ci; else npm install; fi
npm run build
fi
$VIMONTO_PHP artisan storage:link --force
$VIMONTO_PHP artisan migrate --force
$VIMONTO_PHP artisan optimize
Les sites Symfony vident le cache et exécutent les migrations Doctrine quand il existe un dossier migrations. Les sites Statamic préchauffent aussi le Stache. Les sites statiques et Node.js installent les paquets et exécutent la commande de build.
Le script s'exécute sous l'utilisateur du site, dans le répertoire de l'application au sein de la nouvelle release (le répertoire racine, pour un monorepo), avec set -e : la première commande qui échoue arrête le déploiement.
Quelles variables le script de déploiement peut-il utiliser ?
| Variable | Valeur |
|---|---|
$VIMONTO_PHP |
Le binaire PHP de la version de PHP du site, comme php8.4. |
$VIMONTO_COMPOSER |
Composer, exécuté avec la version de PHP du site. |
$VIMONTO_RELEASE_PATH |
Le répertoire de l'application dans la nouvelle release. |
$VIMONTO_SITE_PATH |
Le répertoire du site, comme /home/vimonto/shop.example.com. |
$VIMONTO_BRANCH |
La branche en cours de déploiement. |
$VIMONTO_COMMIT |
Le hash complet du commit en cours de déploiement. |
Utilisez $VIMONTO_PHP et $VIMONTO_COMPOSER plutôt que php et composer, pour que le script suive la version de PHP du site quand vous la changez.
Push to deploy
Avec un dépôt issu d'un hébergeur Git connecté, le panneau Déploiement rapide propose Déployer à chaque push. Il s'active de lui-même quand vous liez le dépôt, à la création ou plus tard : Vimonto Deploy ajoute un webhook au dépôt chez GitHub, GitLab ou Bitbucket. Chaque push sur la branche du site lance alors un déploiement ; les push sur d'autres branches sont ignorés. Le désactiver supprime à nouveau le webhook.
Pour un dépôt avec une URL Git personnalisée, le panneau indique d'appeler plutôt l'URL de déploiement depuis votre hébergeur Git ou votre CI.
Déployer depuis la CI avec l'URL de déploiement
Le panneau URL de déploiement affiche une URL secrète pour le site, aux personnes qui peuvent gérer les sites. Une requête POST vers celle-ci déploie la branche du site :
curl -X POST https://…/deploy/your-secret-token
Utilisez-la comme dernière étape d'un pipeline GitHub Actions, GitLab CI ou autre, pour qu'un déploiement ne démarre qu'une fois vos tests passés. Les réponses sont du JSON simple :
| Statut | Message | Signification |
|---|---|---|
202 |
Deploy started. |
Le déploiement est en file d'attente ; la réponse contient son identifiant. |
409 |
A deploy is already running. |
Réessayez quand le déploiement en cours est terminé. |
422 |
La raison | Le site n'est pas prêt ou n'a pas de dépôt. |
404 |
Le token est erroné. |
L'URL accepte 60 requêtes par minute. Toute personne qui a l'URL peut lancer un déploiement : gardez-la secrète. Cliquez sur Régénérer pour en créer une nouvelle ; l'ancienne URL cesse immédiatement de fonctionner, et le webhook chez votre hébergeur Git est mis à jour pour vous.
Suivre un déploiement et lire sa sortie
La liste Déploiements affiche chaque déploiement, du plus récent au plus ancien, 15 par page : son statut, son commit, la façon dont il a été lancé (Manuel, Push, URL de déploiement, Rollback ou API, pour les déploiements lancés via l'API REST ou la CLI), qui l'a lancé, l'auteur du commit, la branche et sa durée. La release en ligne porte un badge En ligne. La vue d'ensemble du site affiche aussi les déploiements les plus récents.
Cliquez sur Voir pour ouvrir un déploiement. Sa page affiche les phases Récupérer, Build et En ligne, la progression pendant l'exécution et, sous Détails et log, la sortie de chaque étape. Le panneau Commit indique le message, le commit, l'auteur, la branche, la release et l'heure de lancement. Utilisez Précédent et Suivant pour passer d'un déploiement à l'autre.
Revenir à une release antérieure
Comme les cinq releases les plus récentes restent sur le serveur, vous pouvez remettre en ligne une release antérieure sans rien reconstruire :
- Trouvez le déploiement dans la liste Déploiements et cliquez sur Revenir en arrière, ou ouvrez-le et cliquez sur Revenir à cette release.
- Confirmez.
currentpointe immédiatement à nouveau vers cette release, PHP-FPM est rechargé et les workers sont redémarrés.
Un rollback apparaît dans la liste sous la forme Revenu à …. Les rollbacks nécessitent les déploiements sans interruption et ne fonctionnent que pour les releases encore présentes sur le serveur.
Déploiements sur place sans zero downtime
Quand Déploiements sans interruption est désactivé (choisi lors de la création du site ou dans les paramètres du site), chaque déploiement met à jour sur place une seule release, releases/live. Le code est récupéré et réinitialisé sur la branche, tandis que les fichiers ignorés comme vendor/ et node_modules/ restent : les builds sont donc plus rapides.
Les contreparties :
- Les visiteurs peuvent voir le site pendant sa construction.
- Un build raté n'est pas abandonné : le code en ligne est celui dont le build a échoué.
- Il n'y a pas d'anciennes releases, donc ni rollback ni étape de nettoyage.
Questions fréquentes
Dois-je garder la page du déploiement ouverte ?
Non. Les déploiements tournent sur le serveur sous forme de tâches en arrière-plan. Vous pouvez fermer la page, et la personne qui a lancé le déploiement reçoit une notification quand il se termine. Suivez toutes les tâches sur la page Activité. Chaque déploiement et chaque rollback est aussi enregistré dans le journal d'audit.
Un site à charge répartie a-t-il des déploiements ?
Non. Un site sur un load balancer n'a pas de code, et donc pas de page Déploiements. Déployez le site sur chaque serveur d'application placé derrière. Consultez répartition de charge.
Combien de releases sont conservées ?
Cinq : les releases les plus récentes, toujours y compris celle en ligne. Les plus anciennes sont supprimées après chaque déploiement réussi.
Pourquoi mon push n'a-t-il pas lancé de déploiement ?
Vérifiez que Déployer à chaque push est activé et que vous avez poussé sur la branche du site. Les push sur d'autres branches sont ignorés. Un déploiement déjà en cours refuse aussi d'en lancer un second.
Puis-je exécuter les migrations seulement lors de certains déploiements ?
Le script de déploiement est du Bash simple : vous pouvez donc utiliser des conditions. Par exemple, testez $VIMONTO_BRANCH ou un fichier dans la release avant d'exécuter $VIMONTO_PHP artisan migrate --force.