DÉPLOYER

Déploiements planifiés et cron

Redéployez selon un calendrier, et lancez des commandes ponctuelles ou récurrentes dans une application.

Deux choses différentes tournent à l’horloge, et il vaut mieux ne pas les confondre : un déploiement planifié reconstruit et remplace l’application, tandis qu’une tâche cron exécute une commande dans le conteneur déjà en place.

	Déploiement planifié	Tâche cron
Fait	Reconstruit l’image et recrée les conteneurs.	Exécute une commande dans le conteneur en marche.
Usage typique	Récupérer une image de base reconstruite chaque nuit ; rafraîchir un site statique.	Envoyer un email récapitulatif, purger une table, générer un rapport.
Permission	`apps:deploy`	`apps:exec`
Interruption	Un vrai déploiement — avec le remplacement de conteneur habituel.	Aucune. Rien ne redémarre.

Les permissions diffèrent à dessein. Un déploiement planifié, c’est le bouton Déployer sur minuterie, pas une commande dans un shell — il relève donc de l’autorité de déploiement, pas de celle d’exécution.

Déploiements planifiés

Deux formes, dans l’onglet Planification de l’application :

Récurrent: Une expression cron — 0 3 * * * pour chaque nuit à trois heures. S’exécute jusqu’à désactivation.
Ponctuel: Un instant unique. Il se désactive lui-même au moment où il se déclenche — une ligne qui a l’air armée alors qu’elle ne repartira jamais est un mensonge que l’interface répéterait.

Les occurrences manquées sont ignorées, pas rattrapées. Si le panneau est resté hors service trois nuits, il ne se réveille pas avec trois redéploiements en file — il fait le suivant. Se réveiller avec une file de rattrapage est pire que la seule exécution demandée.

Tâches cron

Une tâche cron, c’est une commande, une planification, et rien d’autre. Elle s’exécute dans le conteneur de l’application : elle voit donc le même système de fichiers, les mêmes variables d’environnement et le même réseau de projet que votre application :

TEXT

0 3 * * *      php artisan queue:prune
*/15 * * * *   node scripts/sync.js
0 0 * * 0      npm run weekly-report

La résolution est d’une minute — une planification plus fine n’est pas exprimable, et ne serait pas honorée si elle l’était. Chaque exécution consigne sa sortie : une tâche qui échoue en silence depuis une semaine est visible, et pas seulement absente.

Même règle « on saute, on ne rattrape pas » que ci-dessus, et même garde-fou : une commande encore en cours à l’arrivée du tick suivant n’est pas relancée une seconde fois.

Les tâches cron s’attachent à une application mono-conteneur. Une stack Compose comporte plusieurs conteneurs et aucun endroit évident où lancer la commande : elle n’en accepte donc pas — utilisez plutôt une application worker dédiée.

Les previews les prennent désactivées

Un environnement de préview clone la configuration de son application source — mais il est créé avec les tâches cron désactivées. Un preview partage la base de sa source : une planification copiée exécuterait la migration ou la purge d’une branche non relue sur les vraies données, une fois par pull request ouverte.

On peut les réactiver à la main sur un preview, si c’est bien ce que vous voulez.

Sur plusieurs répliques du panneau

Les deux planificateurs élisent un unique leader. Chaque réplique porte la minuterie, mais une seule se déclenche — sinon le même redéploiement nocturne s’exécuterait une fois par réplique, à la même minute.