Déploiements
Des déploiements qui ne coupent jamais votre site
Chaque déploiement construit une nouvelle version à côté de celle en ligne et ne bascule que si toutes les étapes ont réussi. Poussez sur votre branche, appelez une URL de déploiement depuis votre CI ou cliquez sur Déployer maintenant.
Comment ça marche
Quatre étapes, et seule la dernière touche au site en ligne
- 1
Récupérer le code
Votre branche est clonée dans un nouveau répertoire de version nommé d’après la date et l’heure. Le commit, son auteur et son message sont enregistrés.
- 2
Construire la version
Le
.envpartagé (et pour Laravel,storage/) est lié, puis votre script de déploiement s’exécute dans la nouvelle version, sous l’utilisateur du site. - 3
Passer en ligne de façon atomique
currentpointe vers la nouvelle version en un seul renommage. PHP-FPM se recharge pour qu’OPcache voie les nouveaux fichiers, et les queue workers redémarrent. - 4
Garder cinq versions
Les anciennes versions sont nettoyées ; les cinq plus récentes restent sur le serveur, si bien qu’un rollback est instantané et ne demande aucun build.
Script de déploiement
Un script de déploiement lisible et modifiable
Chaque site démarre avec un script de déploiement adapté à son framework. C’est du Bash simple, lancé avec set -e dans la nouvelle version, et vous le modifiez dans le navigateur.
Utilisez $VIMONTO_PHP et $VIMONTO_COMPOSER au lieu de php et composer : le script suit ainsi la version de PHP du site quand vous la changez. La branche et le commit déployés sont aussi disponibles.
$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 optimizeLancez un déploiement comme il vous convient
Déploiement à chaque push
Liez un dépôt GitHub, GitLab (auto-hébergé compris) ou Bitbucket et un webhook est ajouté pour vous. Les push sur la branche du site déclenchent un déploiement ; les autres branches sont ignorées.
Une URL de déploiement pour la CI
Appelez une URL secrète en
POSTcomme dernière étape de votre pipeline : un déploiement ne démarre qu’une fois vos tests passés. Les réponses sont en JSON simple.Déployer maintenant
Un bouton dans l’en-tête du site. Suivez les phases en direct, ou fermez la page : le déploiement tourne sur le serveur et vous recevez un message quand il se termine.
API et CLI
Lancez des déploiements depuis vos propres scripts avec l’API REST, ou depuis la CI avec le CLI deploy et
Automatisation--watch, pour qu’un déploiement raté fasse passer le pipeline au rouge.
Suivez chaque déploiement en temps réel
La page d’un déploiement affiche les phases Récupération, Build et En ligne, l’étape en cours et la sortie de chaque étape. Un déploiement terminé ou échoué envoie une notification, dans l’app, par e-mail ou vers votre propre endpoint.
Quand un déploiement échoue, rien ne change
Si la récupération du code ou le script de déploiement échoue, la nouvelle version est écartée et current n’est pas touché. Les visiteurs continuent de voir la version en ligne, et la page du déploiement affiche l’erreur avec le log complet.
Revenir en arrière est tout aussi rapide : choisissez Revenir en arrière sur un déploiement précédent et cette version repasse en ligne, sans rien reconstruire. Les migrations de base de données ne sont pas annulées : défaites-les vous-même si une version l’exige.
- Un seul déploiement à la fois par site
- Le premier déploiement construit le
.envà partir de votre.env.example - Chaque modification du
.envest conservée : restaurez l’une des 50 dernières - Envie de builds plus rapides ? Passez un site en déploiements sur place
Des mises en production plus sûres
Sites de staging
Une copie d’un site pour une autre branche, comme develop, sur sa propre adresse et avec sa propre base de données. Chaque push sur cette branche le déploie.
Contrôles de sécurité
Chaque déploiement audite les dépendances Composer et npm de la nouvelle version avant sa mise en ligne. Choisissez par site si une vulnérabilité connue avertit ou arrête le déploiement.
Ce qui n’a pas marché
Un déploiement échoué est expliqué en langage clair à partir de son journal, avec des corrections suggérées, la plus probable d’abord.
Questions sur les déploiements
Dois-je garder la page de déploiement ouverte ?
Non. Les déploiements tournent sur le serveur en tâches d’arrière-plan. Fermez la page : la personne qui a lancé le déploiement reçoit un message à la fin, et chaque déploiement figure sur la page d’activité et dans le journal d’audit.
Combien de versions sont conservées ?
Cinq : les plus récentes, dont toujours celle en ligne. Les plus anciennes sont supprimées après chaque déploiement réussi.
Depuis quels hébergeurs Git puis-je déployer ?
GitHub, GitLab (y compris GitLab auto-hébergé) et Bitbucket, avec déploiement à chaque push. Tout autre serveur Git fonctionne via une URL Git personnalisée avec la deploy key du site ; lancez alors les déploiements avec l’URL de déploiement.
Puis-je déployer sans le mode sans interruption ?
Oui. Avec les déploiements sans interruption désactivés, chaque déploiement met à jour une seule version sur place, ce qui conserve vendor/ et node_modules/ et accélère le build. Vous renoncez au rollback, et les visiteurs peuvent voir le site pendant le build.
Pages associées
- Sites et domainesDes sites à partir de préréglages, DNS automatique, SSL gratuit, fonctionnalités du site et Nginx modifiable.
- AutomatisationUne API REST, un CLI pour la CI, des URL de déploiement, des recettes pour vos scripts récurrents et des hooks de déploiement.
- LaravelDes déploiements Laravel sans interruption, avec Horizon, Reverb, Pulse, les queues et le planificateur à portée d’interrupteur.
Votre prochain déploiement pourrait être en ligne avant que votre café ne refroidisse.
Créez une organisation, connectez un serveur et poussez. C'est tout.