Déployer depuis votre dépôt Git

Connecter un dépôt, déployer une branche, et comprendre ce qui se passe entre un push et un environnement qui tourne.

Vérifié le 12 août 2026

Déployer ici, ce n'est pas redémarrer un serveur avec de nouveaux fichiers dessus. Chaque déploiement construit une image à partir d'un commit précis, puis fait tourner cette image. Ce seul point explique presque tout ce que vous verrez : pourquoi un déploiement prend des minutes et non des secondes, pourquoi la version en service peut toujours être nommée, et pourquoi revenir en arrière est instantané.

Ce qu'il vous faut

Une instance avec au moins un environnement.
La permission git.manage pour connecter un dépôt, et environments.deploy pour en déployer un.
Un dépôt contenant des modules Odoo. Les dépôts privés exigent en plus l'autorisation du fournisseur décrite plus bas.

Connecter le dépôt

Ouvrez votre instance, allez dans l'onglet Intégration Git et choisissez Connecter un dépôt. Vous pouvez connecter un dépôt existant ou en créer un.

L'onglet Intégration Git d'une instance, sans dépôt connecté : le bouton « Connecter un dépôt » et les trois sections repliées expliquant la détection des modules, les dépendances Python et les limites de taille. — L'onglet Intégration Git avant toute connexion.

Connecter un dépôt public en lecture seule fonctionne immédiatement. Tout le reste — dépôt privé, webhooks, déploiement auto, création de branches — exige d'abord l'Autorisation du fournisseur, via Connecter le fournisseur. Si le client OAuth n'est pas encore configuré pour votre fournisseur, l'interface le dit au lieu d'échouer à mi-parcours.

Le dialogue de connexion : choix du fournisseur, onglets « Connecter un dépôt existant » et « Créer un dépôt », encadré « Autorisation du fournisseur », champs dépôt et branche initiale, et l'interrupteur « Dépôt public en lecture seule ». — L'encadré d'autorisation est ce qui sépare un dépôt public d'un dépôt privé.

L'identifiant stocké pour le dépôt est chiffré au repos et ne sert qu'à lire la branche construite, et à y écrire uniquement lorsque vous demandez explicitement un commit.

Ce qu'un déploiement fait réellement

Quand vous déployez une branche, quatre choses se produisent dans cet ordre :

Le commit en tête de branche est résolu et figé. À partir de là, le déploiement se réfère à ce commit, plus à la branche.
Un job de build produit une image contenant vos modules par-dessus l'image de base de l'environnement.
L'image est poussée au registre sous une étiquette dérivée du commit.
L'environnement bascule sur cette image, et la base Odoo est migrée si nécessaire.

Les quatre étapes d'un déploiement : commit figé, build de l'image, poussée au registre, bascule de l'environnement puis migration. — La branche sert à choisir le commit ; ensuite, c'est l'image qui compte.

La conséquence à retenir : ce qui tourne est toujours une version nommée. Pas « le dernier état de la branche » — une image précise, construite depuis un commit précis, redéployable telle quelle.

Le déploiement auto au push

Activez Déploiement auto au push et chaque push sur la branche connectée déclenche la même séquence.

La carte d'un dépôt connecté : nom complet, branche, état du webhook, dernier commit avec ses boutons Synchroniser et Déployer, et l'interrupteur « Déploiement auto au push » activé. — L'état du webhook, sur la troisième ligne, est ce qu'il faut regarder quand un push ne déclenche rien.

Cela passe par un webhook, et ce webhook est vérifié avec un secret propre à ce dépôt, pas un secret global. Si le secret ne correspond pas, le push est rejeté silencieusement à la porte — pas de build, pas de déploiement, aucune erreur sur votre écran, puisque du point de vue de la plateforme rien n'a été poussé.

Cette même porte commande la synchronisation des modules. Donc si vous poussez et qu'il ne se passe absolument rien — ni déploiement, ni liste de modules à jour — vérifiez le secret du webhook avant toute autre chose. C'est de loin la cause la plus probable, et elle ne produit aucune erreur visible.

D'où viennent les addons

L'arborescence de votre dépôt n'est pas aplatie. Chaque répertoire contenant des modules Odoo devient sa propre entrée dans addons_path. Un dépôt organisé ainsi :

repo/
  addons/          -> une racine d'addons
  enterprise_ext/  -> une autre racine d'addons
  tools/           -> pas un répertoire de modules, ignoré

donne à Odoo deux racines d'addons plutôt qu'un dossier fusionné. Deux modules de même nom dans deux racines restent distincts, et l'ordre est conservé.

Si votre environnement tourne sur une image de base sans build, Odoo n'a aucun /mnt/extra-addons à lire et vos modules n'apparaîtront pas. La page de l'environnement propose alors une action Construire et déployer : c'est elle qui transforme le dépôt en image.

Quand un build expire

Deux limites distinctes s'appliquent, et savoir laquelle vous avez atteinte fait gagner du temps :

Limite	Ce qu'elle couvre
`BUILD_JOB_TIMEOUT`	Le job de build lui-même — clone, assemblage, push de l'image
`BUILD_TIMEOUT_SECONDS`	La patience de la plateforme pour que le build rende compte

L'onglet Builds d'un environnement : un build au statut TIMEOUT en rouge, avec son commit, sa durée de 3600 s et le message « Build exceeded BUILD_JOB_TIMEOUT », suivi d'un build SUCCESS de 480 s. — La durée à côté du statut est ce qui distingue un build expiré d'un build en échec.

Un build long n'est pas forcément bloqué. L'installation des modules dans une base neuve est la partie lente, et elle croît avec le nombre de modules — un module va vite, une douzaine non. Si un build expire de façon reproductible avec beaucoup de modules, c'est la limite qu'il faut relever, pas le code qu'il faut changer.

Revenir à une version précédente

Déployer une ancienne version remet un build antérieur en service. Elle redéploie l'image exacte, telle qu'elle a été construite — rien n'est reconstruit, donc c'est rapide et il n'y a aucun risque d'obtenir un résultat différent.

La confirmation avant redéploiement : « Déployer cette version ? », suivi de « Ceci met main · a1c93f4 en ligne sur cet environnement, à la place de ce qui tourne aujourd'hui », avec les boutons Annuler et Déployer cette version. — La confirmation nomme la version exacte qui va prendre la place de celle en service.

Une chose qu'elle ne fait pas : elle ne migre pas les bases en arrière. Le code revient à la version antérieure ; la base reste là où la dernière migration l'a laissée. Pour un changement de schéma, c'est généralement acceptable sur un retour arrière court, et ce n'est pas un moyen d'annuler une migration. Si vous avez besoin des données telles qu'elles étaient, restaurez plutôt une sauvegarde — c'est une autre opération, et elle existe en deux formes : Restaurer écrase cet environnement (une sauvegarde de sécurité est prise avant, et l'environnement redémarre), Cloner vers un nouvel environnement laisse celui-ci intact. Le guide Dupliquer la production pour tester détaille les deux.