DÉPLOYER

Déploiements, rollback et historique

Ce qui se passe pendant un build, comment lire les logs, et comment revenir à une version qui marchait.

Un déploiement, c’est une tentative de faire de votre source — un commit, un Dockerfile, un tag d’image — ce qui répond sur votre URL. Chaque tentative est enregistrée, réussie ou non, et on peut revenir à n’importe laquelle.

Ce qui en déclenche un

Le bouton Déployer: Sur la page de l’application. Construit la branche configurée à son HEAD courant.
Un push, via un webhook: Connectez un fournisseur Git et DockBoard enregistre lui-même le hook. Un push sur la branche configurée redéploie ; les push sur d’autres branches sont ignorés.
L’API: POST /api/deployments avec un identifiant d’application. C’est ce qu’appelle un pipeline CI — voir déployer depuis la CI.
Une planification: Redéployer chaque nuit, ou une fois à un instant précis. Voir déploiements planifiés.

Au plus un déploiement en vol par application. C’est garanti par la base de données, pas par un contrôle sujet aux courses : un second déclenchement pendant un build est refusé plutôt que mis en file derrière. Deux builds écrivant le même tag d’image n’est pas un état souhaitable.

Les statuts, dans l’ordre

Statut	Ce qui se passe
`PENDING`	Accepté et en file. La source est en cours de récupération.
`BUILDING`	L’image se construit. C’est la partie longue, et celle dont vous voulez le log.
`DEPLOYING`	Image construite. Les conteneurs sont recréés et le reverse proxy régénéré.
`RUNNING`	Succès. C’est l’état final favorable — il n’existe pas de `SUCCEEDED` distinct.
`FAILED`	Le build ou le démarrage a échoué. La version précédente sert toujours.
`CANCELLED`	Vous l’avez arrêté en cours de route.
`ROLLING_BACK` `ROLLED_BACK`	Un rollback est en cours, puis terminé.

Si vous interrogez ces statuts depuis un script, traitez tous les statuts finaux, pas seulement RUNNING. Une boucle qui ne sort que sur le succès tourne jusqu’au timeout du job CI quand un build échoue — et un timeout se lit comme un problème d’infrastructure, pas comme un commit cassé.

Lire les logs

Un déploiement porte deux logs, et les confondre fait perdre beaucoup de temps :

Log de build: Tout ce qu’a affiché la construction de l’image — installation des dépendances, compilation, étapes du Dockerfile. Un déploiement FAILED qui n’a jamais atteint DEPLOYING a échoué ici.
Log de déploiement: Ce qui s’est passé une fois l’image disponible — création du conteneur, contrôles de santé, rechargement du proxy.

Les deux défilent en direct pendant le déploiement, et les deux sont conservés ensuite. Les logs de conteneur — ce qu’affiche votre application une fois lancée — sont ailleurs : l’onglet Logs de l’application, qui suit le processus en marche et non le déploiement qui l’a lancé.

Le conteneur démarre puis s’arrête aussitôt ? Lisez le log de conteneur, pas celui de déploiement. Le déploiement a réussi — il a créé quelque chose qui a ensuite choisi de se terminer.

Revenir à une version qui marchait

Chaque déploiement de l’historique dispose d’une action Rollback. Elle redéploie exactement ce commit, et c’est la réponse correcte la plus rapide à une mauvaise livraison — plus rapide qu’un revert Git suivi d’un push, car elle évite l’aller-retour par votre fournisseur.

Via l’API, passez commitSha. Il est résolu contre l’historique de déploiement de cette application, donc un SHA jamais déployé donne un 400 plutôt qu’un déploiement silencieux du HEAD.

Un rollback fait reculer votre code. Il ne fait pas reculer vos données — une migration exécutée pendant la mauvaise livraison a bel et bien été exécutée. Si la livraison a changé la forme de la base, faites reculer le schéma délibérément, ou restaurez une sauvegarde antérieure.

Annuler

Un déploiement en cours peut être annulé. La demande est coopérative : elle est enregistrée, et le build s’arrête au prochain point où l’arrêt est sûr, plutôt que d’être tué en pleine écriture. Comptez quelques secondes, pas un effet immédiat.

Ce qui servait avant continue de servir pendant tout ce temps. Un déploiement annulé ne coupe jamais votre site — il ne le remplace simplement pas.

L’historique

Chaque entrée consigne le commit et son message, qui l’a déclenché, ses heures de début et de fin, sa durée, et les deux logs. De quoi répondre aux deux seules questions qu’on pose vraiment après un incident : qu’est-ce qui a changé, et qui l’a livré.

Lire l’historique demande deployments:view ; en déclencher un demande apps:deploy. Les deux sont distincts à dessein — voir rôles.