Déploiements et rollback
Déploiements et rollback
L'onglet Déploiements d'un service est son historique complet : chaque build y est listé avec son commit, son statut, sa durée et ses logs.
Cycle de vie d'un déploiement
| Statut | Signification |
|---|---|
| En cours | Le build tourne, logs en direct |
| Succès | Image construite et déployée |
| Échec | Le build ou un check a échoué. Rien n'a été déployé |
| Annulé | Build interrompu manuellement |
Un déploiement réussi remplace l'ancien sans coupure : la nouvelle version démarre, et le trafic ne bascule que lorsqu'elle est prête.
Revenir en arrière (rollback)
Chaque déploiement réussi conserve son image dans le registre interne. Pour revenir à une version précédente :
- Ouvrez l'onglet Déploiements du service.
- Repérez le déploiement cible dans l'historique.
- Cliquez sur Rollback. L'image de l'époque est redéployée telle quelle, sans rebuild.
Le rollback est quasi instantané puisqu'aucun build n'est nécessaire. Les variables d'environnement actuelles s'appliquent (elles ne sont pas restaurées à leur état de l'époque).
Annuler un build en cours
Un build lancé par erreur (ou bloqué) s'annule depuis la ligne du déploiement, avec le bouton Annuler. Le service continue de tourner sur sa version précédente.
Logs de build
Les logs de chaque build sont persistés : vous pouvez rouvrir un déploiement vieux de plusieurs semaines et relire l'intégralité de sa sortie. Utile pour comparer un build qui passait avec celui qui casse.
Déploiement automatique : si le service suit une branche GitHub, chaque push déclenche un build (déploiement continu). Les checks kx712.yml permettent de bloquer le déploiement si vos tests échouent.