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
Nun wechseln Sie auf odoo.sh und starten das Deployment. Die Anmeldung erfolgt über das GitHub-Konto, anschließend erteilen Sie Odoo.sh die benötigten Zugriffsrechte über die Schaltfläche Authorize.
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, auch wenn sich in vielen Projekten eingebürgert hat, den Produktionsbranch trotzdem nach der Version zu benennen.
Nach dem Deployment stehen Produktions-, Staging- und Entwicklungsbranches zur Verfügung, und jeder Push löst den passenden Build aus.
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