Wer Odoo.sh einsetzt, arbeitet automatisch mit GitHub. Odoo.sh ist keine klassische Hosting-Oberfläche, in der man Module per Upload einspielt, sondern eine Plattform, die den kompletten Code aus einem Git-Repository zieht. Jede Branch entspricht einer Datenbank, jeder Commit löst einen Build aus. Das Repository ist damit die einzige Quelle der Wahrheit für Ihr Projekt.
Deshalb lohnt es sich, das Repository sauber anzulegen, bevor das erste Mal auf "Deploy" geklickt wird. Der folgende Ablauf dauert wenige Minuten und erspart später einiges an Aufräumarbeit.
Voraussetzungen
- ein GitHub-Konto (kostenlos ausreichend, für Teams empfiehlt sich eine Organisation)
- ein Odoo.sh-Abo oder ein laufender Testzeitraum
- Klarheit darüber, wem das Repository gehören soll: Ihnen persönlich, Ihrem Unternehmen oder dem Kunden
Gerade der letzte Punkt wird gerne übersehen. Ein Repository, das im privaten Konto einer einzelnen Person liegt, wird beim nächsten Personalwechsel zum Problem. Legen Sie Projekte für Kunden daher konsequent unter einer Organisation an.
Schritt 1: Bei GitHub anmelden oder registrieren
Öffnen Sie github.com. Rechts oben in der Navigationsleiste finden Sie Sign in für bestehende Konten und Sign up für die Neuanmeldung.
Bildunterschrift: Anmeldung und Registrierung finden Sie rechts oben in der Navigationsleiste.
Alt-Text: Startseite von github.com. Rot markiert und mit einem Pfeil hervorgehoben sind die Schaltflächen "Sign in" und "Sign up" rechts oben in der Navigationsleiste.
Verwenden Sie für ein neues Konto eine Adresse, auf die auch Kolleginnen und Kollegen im Notfall zugreifen können, also eher eine Funktionsadresse als ein persönliches Postfach. Zwei-Faktor-Authentifizierung ist bei GitHub ohnehin verpflichtend. Richten Sie sie gleich mit einer Authenticator-App ein und legen Sie die Recovery-Codes an einem sicheren Ort ab.
Schritt 2: Neues Repository starten
Nach der Anmeldung landen Sie auf dem Dashboard. Links oben neben Top repositories liegt die grüne Schaltfläche New.
Bildunterschrift: Über die Schaltfläche New starten Sie ein neues Repository.
Alt-Text: GitHub-Dashboard nach der Anmeldung. Ein Pfeil zeigt auf die rot markierte grüne Schaltfläche "New" links oben über der Repository-Liste.
Alternativ funktioniert auch das Plus-Symbol rechts oben in der Kopfzeile.
Schritt 3: Repository konfigurieren
Jetzt kommt der Teil, bei dem die meisten Fehler passieren. Das Formular ist kurz, aber jede Einstellung hat für Odoo.sh eine Konsequenz.
Bildunterschrift: Sprechender Name und Sichtbarkeit Private, der Rest bleibt bewusst leer.
Alt-Text: GitHub-Formular "Create a new repository". Zwei Pfeile zeigen auf rot markierte Bereiche: das Feld "Repository name" mit dem Eintrag "odoo-XYZ" und die Auswahl "Private" bei "Choose visibility". Darunter sind README ausgeschaltet, keine .gitignore und keine Lizenz eingestellt.
Owner: Wählen Sie hier die Organisation, nicht das persönliche Konto, sobald mehr als eine Person beteiligt ist.
Repository name: Bewährt hat sich ein sprechendes Schema wie odoo-kundenname oder odoo-XYZ. Wer mehrere Odoo-Projekte betreut, findet so in der Repository-Liste sofort das richtige.
Visibility: Private. Für Kundenprojekte ist das gesetzt. In der Regel landen in diesem Repository Konfigurationen, Datenstrukturen und mitunter auch Zugangslogik. Odoo.sh kommt mit privaten Repositories problemlos zurecht, da Sie der Plattform beim Deployment ohnehin explizit Zugriff erteilen.
Add README: aus. Add .gitignore: No .gitignore. Add license: No license.
Das ist der entscheidende Punkt. Das Repository soll komplett leer bleiben. Odoo.sh legt beim Deployment die eigene Branch-Struktur an und übernimmt den Bestand des Repositories. Ein bereits initialisierter main-Branch mit README führt dazu, dass Sie anschließend Branches umbenennen, zusammenführen oder löschen, bevor die Produktionsumgebung sauber steht. README, Lizenz und .gitignore können Sie jederzeit später ergänzen, dann aber in der Branch-Logik von Odoo.sh.
Mit Create repository ist der Schritt abgeschlossen.
Schritt 4: Die Repository-URL notieren
GitHub zeigt nun die Quick-Setup-Ansicht eines leeren Repositories. Interessant ist davon genau eine Zeile: die Klon-URL nach dem Muster https://github.com/organisation/odoo-XYZ.git.
Bildunterschrift: Für Odoo.sh brauchen Sie nur die Klon-URL, nicht die darunter vorgeschlagenen Git-Befehle.
Alt-Text: Ansicht des leeren Repositories "odoo-XYZ" mit dem Bereich "Quick setup". Ein rot markierter Rahmen hebt die HTTPS-Klon-URL hervor. Darunter stehen die von GitHub vorgeschlagenen Git-Befehle für einen ersten Commit.
Wichtig: Führen Sie die angezeigten git init- und git push-Befehle jetzt nicht aus. Diese Vorschläge sind der Standardweg für ein gewöhnliches Projekt, nicht für Odoo.sh. Notieren Sie sich nur die URL, den Rest übernimmt die Plattform.
Schritt 5: Das Repository mit Odoo.sh verbinden
Wie es jetzt weitergeht, hängt davon ab, ob Sie Odoo.sh neu einrichten oder ein bestehendes Projekt auf ein neues Repository umziehen.
5a: Neues Odoo.sh-Projekt
Wechseln Sie auf odoo.sh und klicken Sie auf Deploy your platform. Die Anmeldung erfolgt mit dem GitHub-Konto, anschließend erteilen Sie Odoo.sh über Authorize die benötigten Zugriffsrechte.
Im Formular "Deploy your platform" wählen Sie bei Github repository die Option Existing repository und darin das eben angelegte Repository. Unter Odoo Version legen Sie die Hauptversion fest, mit der Sie arbeiten möchten. Die Version ergibt sich also aus dem Formular und nicht aus dem Branch-Namen.
Nach dem Deployment stehen Produktions-, Staging- und Entwicklungsbranches zur Verfügung, und jeder Push löst den passenden Build aus.
Wer muss diesen Schritt ausführen? Ein gewöhnlicher Collaborator-Zugang genügt hier nicht. Odoo.sh legt beim Verbinden automatisch einen Deploy Key und einen Webhook im Repository an, dafür sind administrative Rechte am Repository nötig. Liegt das Repository in einer GitHub-Organisation, können Sie Ihrem Entwicklungspartner dort die Rolle Admin geben, dann übernimmt er den Deploy für Sie. Liegt es in Ihrem persönlichen Konto, führen Sie den Schritt selbst aus, gemeinsam per Bildschirmfreigabe ist das eine Sache von wenigen Minuten.
Im Odoo.sh-Projekt selbst vergeben Sie die Rollen anschließend unter Settings. Eingeladene Personen erhalten standardmäßig die Rolle Developer, per Dropdown stehen außerdem Tester und Admin zur Verfügung.
5b: Bestehendes Projekt, altes Repository nicht mehr zugänglich
Ein häufiger Fall aus der Praxis: Das ursprüngliche Repository wurde von einer Person angelegt, die nicht mehr im Unternehmen ist, und niemand hat mehr Zugriff darauf. Odoo.sh läuft weiter, aber neuer Code kann nicht mehr eingespielt werden.
Wichtig vorweg: Klicken Sie in diesem Fall nicht auf "Deploy your platform". Das würde ein zweites, leeres Projekt erzeugen. Odoo.sh bietet in den Projekteinstellungen keine Möglichkeit, das verknüpfte Repository selbst zu wechseln. Der Umzug läuft über den Odoo-Support und in dieser Reihenfolge:
1. Neues Repository anlegen. Wie in den Schritten 1 bis 4 beschrieben, leer und idealerweise in einer GitHub-Organisation Ihres Unternehmens. So hängt der Zugriff künftig nicht mehr an einer einzelnen Person.
2. Den bestehenden Code in das neue Repository übertragen. Falls kein aktueller lokaler Klon mehr existiert, ist der Odoo.sh-Container die Quelle: Dort liegt der Projektcode unter ~/src/user als Git-Arbeitsverzeichnis. Prüfen Sie über die Shell zuerst mit git branch -a und git log, welche Branches und welche Historie tatsächlich vorhanden sind, bevor Sie den Code in das neue Repository pushen.
Achten Sie dabei darauf, alle Branchnamen exakt zu übernehmen. Odoo.sh ordnet jeder Branch eine Umgebung zu. Heißt der Produktionsbranch im alten Repository etwa 17.0, muss er im neuen genauso heißen. Ein Umbenennen auf main bei dieser Gelegenheit führt dazu, dass das Projekt seine Produktion nach dem Umzug nicht wiederfindet.
3. Den Umzug bei Odoo beantragen. Erst wenn der vollständige Code im neuen Repository liegt, eröffnen Sie unter odoo.com/help ein Ticket. Nennen Sie darin das Odoo.sh-Projekt, die URL des neuen Repositories und den Grund für den Wechsel. Der Support hängt das Projekt anschließend auf das neue Repository um. Das Ticket sollte vom Inhaber des Odoo-Abos kommen oder zumindest von ihm bestätigt werden.
4. Erst prüfen, dann aufräumen. Kontrollieren Sie nach dem Umzug, ob ein Test-Commit einen Build auslöst und ob Deploy Key und Webhook im neuen Repository angelegt wurden. Die Schaltflächen Verify Deploy Key und Verify Webhook in den Projekteinstellungen helfen dabei. Das alte Repository archivieren oder löschen Sie, sofern überhaupt möglich, erst danach.
Tipp: Bevor Sie den Umzug starten, lohnt sich eine Rückfrage, wem das alte Repository eigentlich gehört. Liegt es in einer GitHub-Organisation Ihres Unternehmens und fehlen nur die Adminrechte, kann ein Organisations-Owner den Zugang einfach wiederherstellen. Dann ist kein Umzug nötig.
Was danach in das Repository gehört
Eigene und Community-Module legen Sie einfach als Ordner im Repository ab. Odoo.sh erkennt Verzeichnisse, die Odoo-Module enthalten, automatisch. Die Struktur können Sie frei wählen, entweder direkt im Wurzelverzeichnis oder nach Kategorien gruppiert.
Zwei Hinweise aus der Praxis:
- Community-Module als Submodule. Module aus öffentlichen Repositories, etwa von der OCA, binden Sie besser als Git-Submodul ein als per Copy-and-paste. Updates bleiben dadurch nachvollziehbar. Bei privaten Repositories als Submodul müssen Sie zusätzlich einen Deploy Key in den Odoo.sh-Projekteinstellungen und im Repository hinterlegen, sonst darf Odoo.sh den Code nicht laden.
- Keine Enterprise-Quellen im Repository. Der Enterprise-Code wird von Odoo.sh bereitgestellt und hat im Kunden-Repository nichts verloren.
Der nächste Schritt: Zugriff für Ihren Entwicklungspartner
Ist Ihnen im vierten Screenshot die Kachel Add collaborators to this repository aufgefallen? Genau dort geht es weiter. Solange das Repository nur Ihnen gehört, kann niemand sonst Code einspielen. Für die Zusammenarbeit an Ihrem Odoo-Projekt laden Sie Ihren Entwicklungspartner als Collaborator ein.
Wie das in sechs Schritten funktioniert, welche Berechtigungsstufe die richtige ist und warum GitHub-Zugriff und Odoo.sh-Zugriff zwei verschiedene Paar Schuhe sind, lesen Sie hier: Odoo.sh / GitHub: Collaborator zu einem Repository hinzufügen
Fazit
Der eigentliche Aufwand liegt nicht im Anlegen des Repositories, sondern in den drei Entscheidungen davor: Wem gehört es, wie heißt es, und bleibt es leer. Wer diese drei Punkte sauber klärt, hat eine Odoo.sh-Umgebung, die auch nach zwei Jahren und mehreren Entwicklerwechseln noch nachvollziehbar ist.
Sie kommen an einer Stelle nicht weiter? Schreiben Sie uns über das Kontaktformular, wir sehen uns die Einrichtung gemeinsam mit Ihnen an.
Photo by Randall Meng on Unsplash