Doku / Deployments

Deployments (Git → Instanz)

Dein Code aus Git auf die Odoo-Instanz: Repo verbinden, Deploy auslösen und gezielt nur die Module aktualisieren, die zum Repo gehören.

Kurz gesagt: Du verbindest ein oder mehrere Git-Repos mit deiner Instanz und pro Instanz-Typ (Prod/Staging/Dev) einen Branch. Ein Deploy holt den Code und aktualisiert in Odoo nur die Module aus genau diesem Repo - kein pauschales Update über alles.

Schritt 1: Repo verbinden

Im Portal unter Instanz → Git Repositories verbindest du dein Repo. Zwei Wege, je nachdem, ob dein Repo öffentlich erreichbar ist:

Zugriff	So funktioniert es
Öffentliches Repo	https-URL angeben (z.B. https://github.com/OCA/server-tools.git) - kein Key nötig
Privates Repo	Read-Only-Deploy-Key, ein Key pro Repo: erpdock erzeugt ihn beim Verbinden, du hinterlegst ihn in deinem Repo. Anleitungen für GitHub, GitLab, Bitbucket und Gitea/Forgejo (self-hosted) stehen direkt im Dialog

URL-Form: Öffentliche Repos verbindest du über die https://-Form - ein Deploy-Key hilft dort nicht weiter, er beweist nur, wer du bist, nicht dass es das Repository gibt. Private Repos laufen über die ssh-Form (git@github.com:owner/repo.git) mit Deploy-Key.

Eine Git-Provider-App (Anbindung per Klick, kurzlebige Tokens statt Keys) ist geplant, aber noch nicht verfügbar.

Pro Repo und Instanz-Typ legst du fest, welcher Branch ausgerollt wird - z.B. main auf Produktion, develop auf Staging.

Schritt 2: Deploy auslösen

Trigger	Verhalten
Webhook	Automatisch bei Push: das Portal zeigt dir Webhook-URL und Secret, beides trägst du bei deinem Git-Host als Push-Webhook ein (GitHub, GitLab, Gitea/Forgejo und Bitbucket werden automatisch erkannt)
Polling	Regelmäßige Abfrage (~5 Min) als Fallback für selbst gehostete Server
Manuell	Deploy-Button im Portal, Branch bzw. Commit wählbar

Standard: Automatisches Deployen ist für Staging und Dev aktiv, für Produktion bewusst aus. Auf Produktion löst du den Deploy gezielt aus.

Update-Scope: nur die Module des Repos

Der Update-Button eines Repos aktualisiert ausschließlich die Module dieses Repos - und davon nur die, die auf der Instanz auch installiert sind. Es gibt kein implizites Update über alle Module.

So läuft die Abgrenzung:

Der Agent liest die Module (__manifest__.py) im Repo-Checkout.
Er schneidet sie mit den auf der Instanz installierten Modulen. Nur diese Schnittmenge wird per -u aktualisiert.
Lässt sich das nicht sauber ermitteln, bricht der Vorgang ab, statt vorsichtshalber zu viel anzufassen.

Voll-Update, wenn du es wirklich brauchst: Ein Update über alle Module (-u all) gibt es als eigenen Button mit Warndialog - bewusst getrennt, weil ein pauschales Update auf einer produktiven Instanz weitreichende Folgen hat.

Was beim Deploy passiert

Der Agent auf deiner VM arbeitet den Deploy in dieser Reihenfolge ab:

Code holen (git fetch/checkout, inkl. Submodule)
Python-Abhängigkeiten installieren
Pre-Deploy-Checks (Syntax, Abhängigkeiten, Speicherplatz)
Optional: Odoo-Tests, optional: DB-Backup vor dem Deploy
Module aktualisieren (odoo-bin -u <module> --stop-after-init)
Neustart, Health-Check, Log ans Portal

Das Build-Log läuft in Echtzeit ins Portal, und pro Instanz gibt es eine Build-Historie.

Rollback

Geht bei einem Deploy etwas schief, kannst du per Rollback-Button auf einen vorhandenen Sicherungsstand zurück.

Voraussetzung: Ein Rollback braucht ein Backup von vor dem Deploy. Aktivier für Produktions-Deployments die Option DB-Backup vor dem Deploy - sie ist standardmäßig aus. Ohne dieses Backup gibt es keinen Deploy-Rollback.

Staging statt Experiment auf Produktion

Bevor du auf Produktion deployst, testest du auf Staging. Beim Klonen von Produktion auf Staging oder Dev werden Datenbank, alle Repos und der Filestore mitgezogen und die Kopie neutralisiert - Cronjobs, echter Mailversand und automatische Aktionen sind dann aus, damit eine Staging-Instanz nicht versehentlich nach außen wirkt.

Häufige Fragen

Aktualisiert ein Deploy alle Module meiner Instanz?

Nein. Der Update-Button eines Repos fasst nur die installierten Module dieses Repos an. Ein Update über alle Module ist ein separater Button mit Warndialog.

Werden Git-Submodule mitgezogen?

Ja - Submodule (z.B. OCA-Repos) werden automatisch erkannt und rekursiv mitgeklont, mit dem Zugriff des Haupt-Repos. Öffentliche Submodule funktionieren damit direkt; private Submodule müssen über denselben Zugriff erreichbar sein.

Deployt Produktion automatisch bei jedem Push?

Nein - für Produktion ist Auto-Deploy standardmäßig aus. Staging und Dev deployen automatisch, Produktion löst du gezielt aus.

Zurück zur Doku-Übersicht. Umzug einer bestehenden Instanz mit Git-Setup? Migration ansehen oder Erstgespräch buchen.