Zweige

Die Ansicht Zweige bietet einen Überblick über die verschiedenen Zweige in Ihrem Repository.

Phasen

Odoo.sh bietet drei verschiedene Verzweigungsstufen an:

• Produktion

• Staging

• Entwicklung

Sie können den Status eines Zweigs ändern, indem Sie ihn per Drag & Drop in die gewünschte Phase ziehen.

Bemerkung

• Entwicklungszweige können unter Staging verschoben werden. Wenn Sie versuchen, einen Entwicklungszweig unter Produktion zu verschieben, wird eine Warnmeldung angezeigt, die darauf hinweist, dass Sie pro Projekt nur einen Produktionszweig haben können.

• Staging-Zweige können unter Entwicklung verschoben werden, aber nicht unter Produktion.

• Der Produktionszweig kann nur unter Entwicklung verschoben werden. Wenn Sie versuchen, ihn unter Staging zu verschieben, können Sie nur eine Zusammenführung durchführen. Eine detaillierte Erläuterung dieses Vorgangs finden Sie im Abschnitt über Zusammenführungen.

Produktion

Der Produktionszweig enthält den Code, der zur Ausführung der Produktionsdatenbank verwendet wird. Es kann nur einen Produktionszweig geben.

Wenn Sie einen neuen Commit in diesen Zweig pushen, wird der Produktionsserver mit dem überarbeiteten Code aktualisiert und neu gestartet.

Wenn die Änderungen ein Modul-Update erfordern, z. B. die Änderung einer Formularansicht, und Sie möchten, dass das Update automatisch durchgeführt wird, können Sie die Versionsnummer des Moduls in seiner Manifestdatei (__manifest__.py) erhöhen. Die Plattform führt das Update durch, wobei die Instanz aus Gründen der Wartung vorübergehend nicht verfügbar ist.

Diese Methode entspricht dem Upgrade des Moduls über das Menü Apps oder mit -u in der Befehlszeile.

Bemerkung

• Wenn die Änderungen den Neustart des Servers verhindern oder die Modulaktualisierung fehlschlägt, wird der Server automatisch auf die vorherige erfolgreiche Code-Revision zurückgesetzt und die Datenbank auf ihren vorherigen Zustand. Greifen Sie auf das Protokoll der fehlgeschlagenen Aktualisierung zu, um das Problem zu beheben.

• Die Demodaten werden nicht geladen, da sie nicht für die Verwendung in einer Produktionsdatenbank vorgesehen sind. Die Unit-Tests werden nicht durchgeführt, da dies die Nichtverfügbarkeitszeit der Produktionsdatenbank während der Aktualisierung verlängern würde.

Odoo.sh sichert automatisch die Produktionsdatenbank. Es werden sieben tägliche, vier wöchentliche und drei monatliche Back-ups gespeichert. Jedes Back-up umfasst den Datenbank-Dump, den Dateispeicher (Anhänge und Binärfelder), Protokolle und Sitzungen.

Warnung

Bei Verwendung von Testprojekten werden der Produktionszweig und alle Staging-Zweige nach 30 Tagen automatisch wieder in die Entwicklungsphase zurückgesetzt.

Staging

Staging-Zweige dienen dazu, neue Funktionen anhand von Produktionsdaten zu testen, ohne die eigentliche Produktionsdatenbank durch Testdatensätze zu beeinträchtigen. Sie erstellen neutralisierte Duplikate aus der Produktionsdatenbank.

Die Neutralisierung deaktiviert:

• Geplante Aktionen

  Bemerkung

  Um sie zu testen, lösen Sie sie manuell aus oder aktivieren Sie sie erneut. Beachten Sie, dass die Plattform sie seltener auslöst, wenn niemand die Datenbank nutzt, um Ressourcen zu sparen.

• Ausgehende E-Mails

  Bemerkung

  Stattdessen werden sie mithilfe eines Mail-Catchers abgefangen. Eine Schnittstelle zum Anzeigen der von der Datenbank gesendeten E-Mails ist in Ihrem Odoo.sh-Projekt verfügbar. Auf diese Weise werden keine E-Mails an Ihre Kontakte gesendet.

• IAP-Dienste

• Zahlungsanbieter und Versandkonnektoren

  Bemerkung

  Sie werden in den Testmodus gesetzt.

Wenn Sie Änderungen in einer Staging-Datenbank konfigurieren oder anzeigen, stellen Sie sicher, dass Sie diese aufzeichnen (schrittweise notieren, in der Produktion reproduzieren usw.) oder direkt in die Module des Zweigs schreiben, wobei Sie XML-Datendateien verwenden, um die Standardkonfiguration oder -ansichten zu überschreiben. Beispiele finden Sie in der Dokumentation zum ersten Modul.

Bemerkung

Unit-Tests werden nicht durchgeführt. Sie basieren auf Demodaten, die nicht in die Produktions- und Staging-Datenbanken geladen werden. Wenn Odoo die Ausführung der Units ohne Demodaten unterstützt, wird Odoo.sh die Ausführung der Tests auf Staging-Datenbanken in Betracht ziehen.

Staging-Datenbanken werden nicht automatisch gesichert. Sie können jedoch eine Sicherung der Produktionsdatenbank in einem Staging-Zweig zu Testzwecken wiederherstellen oder versehentlich aus der Produktionsdatenbank gelöschte Daten manuell wiederherstellen. Es ist möglich, manuelle Sicherungen von Staging-Datenbanken zu erstellen.

Warnung

Datenbanken, die für Staging-Zweige erstellt wurden, sind für bis zu drei Monate vorgesehen. Danach können sie ohne vorherige Ankündigung automatisch gesperrt werden. Nur durch eine Neuerstellung des Zweigs können Sie ihn wieder verwenden.

Entwicklung

Entwicklungszweige erstellen neue Datenbanken mit Demodaten, um die Unit-Tests auszuführen. Die installierten Module sind diejenigen, die im Zweig enthalten sind. Sie können diese Liste der zu installierenden Module in den Projekteinstellungen ändern.

Wenn Sie einen Commit in einen Entwicklungszweig übertragen, wird ein neuer Server gestartet, eine Datenbank von Grund auf neu erstellt und der Zweig aktualisiert. Die Demodaten werden geladen und standardmäßig werden Unit-Tests durchgeführt, um sicherzustellen, dass die Änderungen keine der getesteten Funktionen beeinträchtigen. Sie können die Tests deaktivieren oder bestimmte Tests mit benutzerdefinierten Tags ausführen lassen, indem Sie zu den Zweigeinstellungen gehen.

Ähnlich wie bei Staging-Zweigen werden E-Mails nicht versendet, sondern von einem Mail-Catcher abgefangen, und geplante Aktionen werden nicht ausgelöst, solange die Datenbank nicht verwendet wird.

Entwicklungsdatenbanken werden nicht automatisch gesichert, und manuelle Back-ups sind nicht möglich.

Warnung

Für Entwicklungszweige erstellte Datenbanken sind für etwa drei Tage vorgesehen. Danach können sie ohne vorherige Ankündigung automatisch gelöscht werden, um Platz für neue Datenbanken zu schaffen.

Zweige zusammenführen

Sie können Ihre Zweige zusammenführen, indem Sie sie per Drag and Drop ineinander ziehen.

Um die Änderungen der Entwicklungszweige mit den Produktionsdaten zu testen, haben Sie folgende Möglichkeiten:

• Führen Sie eine Zusammenführung des Entwicklungszweigs in einen Staging-Zweig durch, indem Sie ihn per Drag and Drop auf den gewünschten Zweig ziehen.

  

• Ziehen Sie den Entwicklungszweig per Drag and Drop in den Abschnitt Staging, um ihn zu einem Staging-Zweig zu machen.

  

Wenn die Änderungen für die Produktion bereit sind, ziehen Sie den Staging-Zweig per Drag and Drop in den Produktionszweig, um sie zusammenzuführen und bereitzustellen.

Bemerkung

• Sie können Entwicklungszweige direkt in den Produktionszweig zusammenführen. Allerdings werden die Änderungen nicht über einen Staging-Zweig anhand der Produktionsdaten validiert, sodass ein höheres Risiko besteht, dass Probleme in der Produktionsdatenbank auftreten.

• Sie können Entwicklungszweige miteinander und Staging-Zweige miteinander zusammenführen.

• Sie können auch direkt auf Ihrer Workstation mit git merge Ihre Zwiege zusammenführen. Odoo.sh wird benachrichtigt, wenn neue Revisionen in Ihre Zweige gepusht werden.

Beim Zusammenführen eines Staging-Zweigs in den Produktionszweig wird lediglich der Quellcode übernommen. Alle Änderungen, die an der Staging-Datenbank vorgenommen wurden, werden nicht an die Produktionsdatenbank übertragen. Wenn Sie jedoch den Code im Repository ändern, wird er beim Zusammenführen an den Produktionszweig weitergegeben.

Wenn Sie Konfigurationsänderungen in Staging-Zweigen testen und diese auf den Produktionszweig anwenden möchten, müssen Sie entweder:

• Schreiben Sie die Konfigurationsänderungen in XML-Datendateien, um die Standardkonfiguration oder Ansichten im Zweig zu überschreiben, und erhöhen Sie anschließend die Version des Moduls in seinem Manifest (__manifest__.py), um die Modulaktualisierung beim Zusammenführen des Staging-Zweigs in den Produktionszweig auszulösen.

  Bemerkung

  Diese Methode wird für eine bessere Skalierbarkeit Ihrer Entwicklungen empfohlen, da Sie die Git-Versionsverwaltungsfunktionen für alle Konfigurationsänderungen verwenden und so die Rückverfolgbarkeit Ihrer Änderungen sicherstellen.

• Übertragen Sie sie manuell von der Staging-Datenbank in die Produktionsdatenbank, indem Sie sie kopieren und einfügen.

Tabs

Historie

Der Reiter History (Verlauf) bietet einen Überblick über den Zweig-Verlauf:

• Die Commit-Meldungen und ihre Autoren

• Die verschiedenen Ereignisse im Zusammenhang mit der Plattform, wie z. B. Phasenänderungen, Datenbankimporte und Wiederherstellungen von Sicherungskopien

Ein Status in der oberen rechten Ecke jedes Ereignisses zeigt den aktuellen Vorgang in der Datenbank (z. B. Installation, Aktualisierung, Import der Sicherung) oder dessen Ergebnis (z. B. Testrückmeldung, erfolgreicher Import des Back-ups) an. Wenn ein Vorgang erfolgreich war, wird die Schaltfläche Connect (Verbinden) angezeigt, über die Sie auf die Datenbank zugreifen können.

Mails

Im Reiter Mails enthält den Mail-Catcher, der einen Überblick über die von der Datenbank gesendeten E-Mails bietet.

Bemerkung

Der Mail-Catcher ist für die Entwicklungs- und Staging-Zweige verfügbar. E-Mails aus der Produktionsdatenbank werden tatsächlich versendet und nicht vom Mail-Catcher abgefangen.

Shell

Der Reiter Shell bietet Shell-Zugriff auf den Container.

Durch Klicken auf Shell wird eine neue Browserreiter geöffnet, in der Sie grundlegende Linux-Befehle (ls, top) ausführen können. Sie können eine Shell auf der Datenbank öffnen, indem Sie psql ausführen.

Tipp

Sie können mehrere Shell-Reiter gleichzeitig öffnen und deren Anordnung durch Drag & Drop anpassen.

Bemerkung

• Shells von Produktionsinstanzen werden rot hervorgehoben, um die Gefahr einer direkten Manipulation durch Produktionsinstanzen zu verdeutlichen, während Shells von Staging-/Entwicklungsinstanzen gelb hervorgehoben werden.

• Lang laufende Shell-Instanzen/inaktive Shell-Sitzungen können jederzeit beendet werden, um Ressourcen freizugeben.

Befehle

Hier finden Sie eine Übersicht über nützliche Befehle, die Sie in einem Odoo.sh-Datenbankterminal ausführen können:

• odoo-bin shell: zum Öffnen einer Odoo-Shell

• odoo-update: zum Aktualisieren von Modulen in der Datenbank

• odoosh-restart: zum Neustarten der Odoo.sh-Dienste (http oder cron)

• odoosh-storage: to check the storage usage of your instance’s container filesystem

• psql: zum Öffnen einer Datenbank-Shell

• mutt: um zu überprüfen, wie E-Mails in Text-Clients angezeigt werden (Staging- und Entwicklungsinstanzen)

• lnav ~/logs/odoo.log: zum Navigieren in der Datei odoo.log Ihrer Instanz

• ncdu: um den Festplattennutzungsanalysator mit einer interaktiven Benutzeroberfläche zu starten

• grep: zum Filtern und Suchen von Informationen in Protokoll- oder Konfigurationsdateien

Editor

Durch Klicken auf Editor wird ein neuer Browserreiter geöffnet, über den Sie auf eine integrierte Online-Entwicklungsumgebung (IDE) zugreifen können, um den Quellcode zu bearbeiten. Sie können auch Terminals, Python-Konsolen und Odoo-Shell-Konsolen öffnen.

Sie können mehrere Reiter öffnen und diese per Drag & Drop nach Belieben anordnen.

Siehe auch

Online-Editor-Dokumentation.

Überwachung

Der Reiter Überwachung zeigt verschiedene Leistungsüberwachungsmetriken des aktuellen Builds an.

Vergrößern Sie den Zeitbereich mit dem Cursor oder wählen Sie ihn manuell aus dem Zeitbereichsauswahlfeld. Es ist auch möglich, die Zeitzone zu ändern.

Bemerkung

• Technische Protokolle verwenden immer UTC. Um diese Protokolle zusammen mit Ihren Überwachungsmetriken zu analysieren, stellen Sie sicher, dass im Überwachungstool UTC ausgewählt ist.

• Ebenso sollten Sie beim Senden eines Supporttickets sicherstellen, dass die von Ihnen angegebenen Informationen auf UTC basieren, da Odoo diese Zeitzone zur Untersuchung von Leistungsproblemen verwendet.

Die Informationen werden regelmäßig aggregiert. In diesem Fall wird eine blau gepunktete Linie zusammen mit dem Stcihwort Aggregate Date (Daten aggregieren) angezeigt. Das bedeutet, dass die Daten vor diesem Datum im Vergleich zu den nach diesem Datum abgeflacht dargestellt werden. Bei der Verwendung des Überwachungstools wird daher empfohlen, sich auf aktuelle Ereignisse zu konzentrieren, um möglichst detaillierte Informationen zu erhalten.

Bemerkung

Punktierte Linien in anderen Farben helfen Ihnen, andere Änderungen am Build (Datenbankimport, Git-Push usw.) zuzuordnen.

Tipp

In jedem Diagramm wird oben links ein Symbol 𝕚 (information) angezeigt. Bewegen Sie den Mauszeiger darüber, um weitere Details zur Darstellung des Diagramms zu erhalten.

Kennzahlen

System

Das Diagramm Memory (Speicherverbrauch) zeigt Informationen zum Speicherverbrauch an:

• Memory container (Speichercontainer) stellt Odoo-Worker und Containerprozesse dar.

• Memory postgresql (PostgreSQL des Speichers) stellt die Datenbank dar.

Das CPU-Diagramm zeigt Informationen zum CPU-Verbrauch an:

• CPU http vertritt die Mitarbeiter von Odoo.

• CPU cron/mail stellt geplante Aktionen und eingehende E-Mails dar.

• CPU postgresql (Datenbankprozesse)

• CPU other steht für Webshells, den Editor usw.

Das Diagramm Storage (Speicherauslastung) zeigt Informationen zum verwendeten Speicher an:

• Container stellt den Dateispeicher, die Protokolldateien und die Benutzerdateien dar.

• Postgresql stellt die Datenbank und die Indizes dar.

HTTP

Das Diagramm Requests (Anfragen) zeigt Informationen zur Anzahl der HTTP-Anfragen pro Sekunde an:

• HTTP successes (HTTP-Erfolge) stellt erfolgreiche Anfragen dar.

• HTTP errors (HTTP-Fehler) steht für fehlgeschlagene Anfragen (siehe odoo.log).

• HTTP rate limited (HTTP-Quote limiert) stellt abgelehnte Anfragen dar, möglicherweise aufgrund von Personalmangel.

Das Diagramm Concurrent requests (max) (Gleichzeitige Anfragen (maximal)) zeigt die maximale Anzahl gleichzeitiger HTTP-Anfragen pro Sekunde an.

Bemerkung

Datenbank-Worker bestimmen die Anzahl der gleichzeitigen Anfragen, die gleichzeitig bearbeitet werden können. Es ist wichtig, über genügend Worker zu verfügen, um alle eingehenden Anfragen sofort zu bearbeiten. Eine übermäßige Anzahl von Workern verbessert jedoch nicht die Geschwindigkeit, mit der Anfragen verarbeitet werden.

Die Average Response time (durchschnittliche Antwortzeit) zeigt die durchschnittliche Antwortzeit auf HTTP-Anfragen (in Millisekunden) an.

Mails

Das Diagramm Incoming (Eingehend) zeigt Daten zur täglichen Anzahl eingehender E-Mails an:

• Received Emails (erhaltene E-Mails) stellt erfolgreich empfangene E-Mails dar.

• Received Emails bounced (Nicht zugestellte E-Mails) steht für E-Mails, die nicht erfolgreich empfangen wurden.

Das Diagramm :guilabel:`Outgoing`(Ausgehend) zeigt Daten zur täglichen Anzahl ausgehender E-Mails an:

• Sent Emails (Gesendete E-Mails) steht für erfolgreich versendete E-Mails.

• Sent Emails bounced (Gesendete, nicht zugestellte E-Mails) stellt nicht erfolgreich versendete E-Mails dar.

Protokolle

Der Reiter Logs (Protokolle) bietet eine Echtzeitansicht der Protokolle Ihres Servers.

Verschiedene Protokolle sind verfügbar:

• pip.log: Installation der Python-Abhängigkeiten

• install.log: die Datenbankinstallation (für Entwicklungszweige sind Tests enthalten)

• odoosh-import-database.log: der zuletzt importierte Dump-Prozess

• odoo.log: der laufende Server

• update.log: die Datenbankaktualisierungen

• pg_slow_queries.log: psql-Abfragen, die ungewöhnlich viel Zeit in Anspruch nehmen

• sh_webshell.log: die in der Webshell durchgeführten Aktionen

• sh_editor.log: die im Editor durchgeführten Aktionen

• neutralize.log: Neutralisierung der Datenbank (nur Staging)

Wenn neue Zeilen zu den Protokollen hinzugefügt werden, werden diese automatisch angezeigt. Wenn Sie zum Ende scrollen, scrollt der Browser jedes Mal automatisch, wenn eine neue Zeile hinzugefügt wird.

Sie können den Prozess zum Abrufen der Protokolle anhalten, indem Sie auf die Schaltfläche (pausieren) in der oberen rechten Ecke klicken. Andernfalls wird der Prozess nach fünf Minuten beendet. Sie können ihn neu starten, indem Sie auf die Schaltfläche (abspielen) klicken.

Back-ups

Im Reiter Backups (Sicherungskopien) werden die verfügbaren Back-ups zum Herunterladen und Wiederherstellen aufgelistet. Hier können Sie ein manuelles Backup durchführen und eine Datenbank importieren.

Die Produktionsdatenbank wird täglich automatisch gesichert. Es werden sieben tägliche, vier wöchentliche und drei monatliche Sicherungen aufbewahrt. Jede Sicherung umfasst den Datenbank-Dump, den Dateispeicher (Anhänge und Binärfelder), Protokolle und Sitzungen.

Bemerkung

Sehen Sie sich den voraussichtlichen Zeitplan für automatische Back-ups an, um ein besseres Verständnis der Funktionsweise des Systems zu erhalten. Diese Datei wird täglich aktualisiert, wobei der aktuelle Tag als Ausgangspunkt dient.

Staging- und Entwicklungsdatenbanken werden nicht automatisch gesichert. Sie können jedoch eine Sicherung der Produktionsdatenbank in Ihren Staging-Zweigen zu Testzwecken wiederherstellen oder versehentlich aus der Produktionsdatenbank gelöschte Daten manuell wiederherstellen.

Die Liste enthält die Back-ups, die auf dem Server Ihrer Produktionsdatenbank gespeichert sind. Dieser Server speichert nur Backups eines Monats: sieben tägliche und vier wöchentliche Back-ups.

Spezielle Back-up-Server speichern dieselben Back-ups sowie drei zusätzliche monatliche Back-ups. Um eines dieser monatlichen Back-ups wiederherzustellen oder herunterzuladen, wenden Sie sich an den Odoo-Support.

Beim Zusammenführen eines Commits, der die Version eines oder mehrerer Module (in __manifest__.py) oder deren verknüpfte Python-Abhängigkeiten (in requirements.txt) aktualisiert, führt Odoo.sh eine automatische Sicherung durch (in der Liste mit dem Typ Update gekennzeichnet), da entweder der Container durch die Installation neuer Pip-Pakete geändert wird oder die Datenbank selbst durch die anschließend ausgelöste Modulaktualisierung geändert wird. In diesen beiden Fällen wird eine Sicherung ausgelöst, da es zu Fehlern kommen kann.

If the merged commit does not update the version of a module or linked dependencies, then no backup is triggered by Odoo.sh, as neither the container nor the database is modified; therefore, the platform considers this safe enough. As an extra precaution, you can make a manual backup before modifiyng production sources.

The purpose of manual backups is to create a specific snapshot of production or staging databases (not available for development). These remain available for seven days. However, there is a limit of five daily manual backups.

Stage	Automatic backup	Manual backup
Produktion	Yes (up to 3 months)	Yes (3 days)
Staging	No	Yes (3 days)
Entwicklung	No	No

The Import Database feature accepts database archives from:

• the standard Odoo database manager (available for on-premise Odoo servers under /web/database/manager)

• the Odoo Online databases manager

• the Odoo.sh Backups tab (using the (Download Options) button)

• the Odoo.sh Builds view (by clicking Download DB dump)

Upgrade

The Upgrade tab can be used to upgrade production and staging branches of valid projects. For more information about the upgrade process, refer to the Upgrade documentation.

Tools

The Tools tab contains the code profiler. It is used to start a profiling session, recording the activities of Odoo workers running in the instance for a maximum of five minutes. You can choose to terminate the session earlier, as running the tool for a shorter duration reduces the amount of noise in the report.

After each session, an interactive flame graph is created to help you visualize how the Odoo workers allocate their time.

Warnung

Running the profiler consumes a lot of server resources, so avoid letting it run for too long. The goal is to record a specific action in your database.

Einstellungen

The Settings tab lists the configuration options available for the currently selected branch. The options vary for each stage.

Behavior upon new commits

You can change the branch’s behavior upon receiving a new commit for development and staging branches.

By default, a development branch creates a new build and a staging branch updates the previous build. This is useful if the feature you are working on requires a specific configuration, as you would not need to manually configure it again after every commit.

If you select New build for a staging branch, a fresh copy of the production build is created every time a commit is pushed.

A branch that is moved from staging to development is set automatically to Do nothing.

Module installation

You can choose which modules should be installed automatically for development branches.

To change the default behavior, untick the Use Default option under Development build behavior and select one of the following options under Module Installation:

• Install only my modules (does not include submodules): only installs the branch’s modules, excluding submodules. This is the default option.

• Full installation (no test suite): installs the branch’s modules, submodules, and all standard Odoo modules. When running the full installation, the test suite is disabled.

• Install a list of modules: installs the specified modules. To do so, enter their technical name, and separate them using commas (e.g., sale_management,website,accountant).

Bemerkung

If the test suite is enabled, installing all standard Odoo modules can take up to one hour.

Test suite

By default, the test suite for development branches is enabled. You can restrict which tests are run by entering test tags and separating them using commas (e.g., custom_tags,at_install,post_install).

To disable the test suite entirely, untick Validate the test suite on new builds.

Odoo version

You can change the version of Odoo for development branches, for example, to test upgraded code or develop features while your production database is in the process of being upgraded to a newer version, by selecting another Version.

By default, Latest is selected as the Revision, and the sources of your Odoo server are updated weekly automatically to benefit from the latest bug, security, and performance fixes.

To choose a specific revision instead, select it using the Revision field.

Warnung

Revisions expire after three months. You will be notified by email when the revision’s expiration date approaches. If you have not taken any action when it expires, the Revision field is automatically set back to Latest.

Benutzerdefinierte Domains

You can configure additional <name>.odoo.com domains or your own custom domains for all branch types.

To use your own custom domain, it is necessary to:

• Own or purchase the domain name.

• Enter the domain name under Custom domains (e.g., www.mycompany.com), then click Add domain.

• Configure the domain name (e.g., www.mycompany.com) using your registrar’s domain name manager with a CNAME record value set to your production database domain name (e.g., mycompany.odoo.com).

Wichtig

Bare domains (e.g., mycompany.com) are not accepted. They can only be configured using A records, which only accept IP addresses as their value. Therefore, a bare domain could suddenly cease to function, as the IP address of a database can change (e.g., following an upgrade, a hardware failure, a change of database hosting location).

To have both your bare domain (e.g., mycompany.com) and www domain (e.g., www.mycompany.com) working, it is necessary to redirect the bare domain to the www domain. .com. Most domain managers provide a way to configure this redirection, commonly referred to as a web redirection.

HTTPS/SSL

If the redirection is correctly set up, an SSL certificate is automatically generated using Let’s Encrypt within the hour, meaning your domain will be accessible through HTTPS.

SPF and DKIM compliance

If the domain of your email addresses uses the SPF or DKIM authentication protocol, it is necessary to authorize Odoo as a sending host in the domain name settings to increase the deliverability of outgoing emails. For more information, refer to the Configure DNS records to send emails in Odoo documentation.

Wichtig

If Odoo is not authorized as a sending host, your outgoing emails may be flagged as spam.

Shell-Befehle

In the top right corner of the view, several shell commands are displayed. The commands can be copied using the clipboard button and then used in a terminal. In addition, some of them can be used directly from Odoo.sh’s interface.

Klonen

The clone command is used to create a local copy of your Git repository.

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git

• --recurse-submodules to download the submodules of your repository

• --branch main to check out to a specific branch of the repository (e.g., development)

Bemerkung

The run button is not available as the command is used to create a local copy on your machine.

Fork

The fork command is used to create a new branch based on the current one.

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main a command to create a new branch (e.g., development-1) based on the current branch (e.g., development)

• git push -u origin development-1 a command to upload the new branch (e.g., development-1) to the remote repository

Zusammenführen

The merge command is used to combine changes on one branch into another branch.

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 a command to merge the changes of the current branch into another branch (e.g., staging-1)

• git push -u origin staging a command to upload the merged changes to the remote repository branch (e.g., staging)

SSH

The SSH command is used to connect to a build using SSH.

To use the SSH command, it is necessary to set up an SSH key first. To do so:

• Generate a new SSH key.

• Copy the SSH key to your clipboard.

• On Odoo.sh, click your GitHub user in the top-right corner and select Profile.

  

• Paste the SSH key under the Add a key manually field and click Add.

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 the build ID

• my-user-my-repository-staging-25004381.dev.odoo.com the domain used to connect to the build

Provided you have the necessary access rights on the project, you will be granted SSH access to the build.

Bemerkung

Long-running SSH connections are not guaranteed. Idle connections can be disconnected to free up resources.

Untermodul

The submodule command is used to add a branch from another repository to your current branch as a submodule.

Siehe auch

Submodules documentation

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> a command to add a specific branch (e.g., master) of a repository (<URL>) as a submodule under the specified path (<PATH>) in your current branch.

• git commit -a a command to commit all current changes

• git push -u origin staging a command to upload the changes of the current branch (e.g., staging) to the remote repository.

Löschen

The delete command is used to delete a branch from your repository.

Bemerkung

Once you delete a branch, there is no way to retrieve it unless a backup exists. Staging branches are not automatically backed up, but can be manually. Development branches cannot be backed up.

Example

git push origin :staging && git branch -D staging

• git push origin :staging a command to delete a specific branch (e.g., staging) on the remote repository

• git branch -D staging a command to delete the specific branch on your local copy of the repository

Warnung

Before deleting a branch, refer to the Backups section to better understand how they work and when you should create a manual backup.