Déploiement continu

Déploiement continu

Chaque git push peut déployer automatiquement : la plateforme écoute les webhooks GitHub de vos dépôts connectés et reconstruit le service dès qu'un commit arrive sur la branche suivie.

Comment ça marche

1. Vous poussez un commit sur la branche suivie (par exemple main).
2. GitHub notifie la plateforme via l'application GitHub installée sur le dépôt.
3. Un build démarre (voir le fonctionnement des builds).
4. Si un fichier kx712.yml définit des checks (tests, lint), ils s'exécutent d'abord, et un échec annule le déploiement.
5. Build réussi → la nouvelle version remplace l'ancienne sans coupure.

Le commit, son message et son statut de déploiement sont visibles dans l'onglet Déploiements, et reportés sur GitHub (statut de commit).

Activer / désactiver le déploiement automatique

Le déploiement automatique se règle par service dans ses paramètres. Désactivé, les push n'ont plus d'effet : vous déployez à la main avec Redéployer. C'est utile pour un environnement que vous voulez figer.

Filtrer les déclenchements

Sans configuration, tout push sur la branche suivie déclenche un build. Le fichier kx712.yml permet d'affiner :

• branches : ne réagir qu'à certaines branches ;
• paths : ignorer un push qui ne touche aucun fichier concerné. C'est utile en monorepo : le service backend ne se reconstruit pas quand seul frontend/** change.

En cas d'échec

Un build ou un check qui échoue ne touche pas la version en ligne : le service continue de tourner sur le dernier déploiement réussi. Corrigez, poussez à nouveau, ou revenez à une version antérieure à tout moment.

Sans GitHub ? Les services déployés par image Docker se mettent à jour en redéployant depuis le dashboard, le CLI ou l'extension VS Code.