Zweige

The Branches view provides an overview of the different branches in your repository.

Phasen

Odoo.sh bietet drei verschiedene Verzweigungsstufen an:

• Produktion

• Staging

• Entwicklung

You can change the stage of a branch by dragging and dropping it under the desired stage.

Bemerkung

• Development branches can be moved under Staging. If you try to move a development branch under Production, a warning message will be displayed explaining that you can only have one production branch per project.

• 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-Services

• 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

Verlauf

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

The Mails tab contains the mail catcher, which provides an overview of emails sent by the database.

Bemerkung

The mail catcher is available for development and staging branches. Emails from the production database are actually sent and are not intercepted by the mail catcher.

Shell

The Shell tab provides shell access to the container.

Clicking Shell opens a new browser tab where you can run basic Linux commands (ls, top). You can open a shell on the database by running psql.

Tipp

You can open multiple shell tabs at once and arrange their layout by dragging and dropping them.

Bemerkung

• Production instance shells are highlighted in red to emphasize the danger of manipulating production instances directly, while staging/development instance shells are highlighted in yellow.

• Long-running shell instances/idle shell sessions can be terminated at any time to free up resources.

Befehle

Here is an overview of useful commands that you can run an Odoo.sh database terminal:

• odoo-bin shell: to open an Odoo shell

• odoo-update: to update modules in the database

• odoosh-restart: to restart Odoo.sh services (http or cron)

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

• psql: to open a database shell

• mutt: to check how emails appear on text clients (staging and development instances)

• lnav ~/logs/odoo.log: to navigate in your instance’s odoo.log file

• ncdu: to launch the disk usage analyzer with an interactive interface

• grep: to filter and find information in log or configuration files

Editor

Clicking Editor opens a new browser tab to access an online integrated development environment (IDE) to edit the source code. You can also open terminals, Python consoles, and Odoo shell consoles.

You can open multiple tabs and drag and drop them to arrange the layout as you wish.

Siehe auch

Online editor documentation.

Monitor

The Monitor tab displays various performance monitoring metrics of the current build.

Zoom in with your cursor to adjust the time range or select it manually from the time range selector. It is also possible to change the time zone.

Bemerkung

• Technical logs always use the UTC. To analyze these logs together with your monitoring metrics, ensure UTC is selected in the monitoring tool.

• Similarly, when sending a support ticket, ensure the information you share is based on UTC, as Odoo uses this time zone to investigate performance issues.

The information is aggregated periodically. When this is the case, a blue dotted line is displayed, along with the tag Aggregate Date. This means that the data before this date will appear flattened when compared to the data after this date. Therefore, when using the monitoring tool, it is recommended to focus on recent events to get the most detailed information possible.

Bemerkung

Dotted Lines of other colors help you relate to other changes on the build (database import, git push, etc.).

Tipp

On each graph, an 𝕚 (information) icon is displayed in the top-left corner. Hover your mouse over it to get more details about what the graph represents.

Kennzahlen

System

The Memory graph displays information about memory consumption:

• Memory container represents Odoo workers and container processes.

• Memory postgresql represents the database.

The CPU graph displays information about CPU consumption:

• CPU http represents Odoo workers.

• CPU cron/mail represents scheduled actions and incoming emails.

• CPU postgresql (database processes)

• CPU other represents webshells, the editor, etc.

The Storage graph displays information about the storage used:

• Container represents the filestore, log files, and user files.

• Postgresql represents the database and indexes.

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.

The Concurrent requests (max) graph displays the maximum number of concurrent HTTP requests per second.

Bemerkung

Database workers determine the number of concurrent requests that can be managed simultaneously. It is essential to have enough workers to handle all incoming requests as they arrive. However, having additional workers beyond this does not improve the speed at which requests are processed.

The Average Response time displays the average response time to HTTP requests (in milliseconds).

Mails

The Incoming graph displays data about the daily number of incoming emails:

• Received Emails represents emails successfuly received.

• Received Emails bounced represents emails unsuccessfully received.

The Outgoing graph displays data about the daily number of outgoing emails:

• Sent Emails represents emails successfully sent.

• Sent Emails bounced represents emails unsuccessfully sent.

Protokolle

The Logs tab offers a real-time view of your server’s logs.

Verschiedene Protokolle sind verfügbar:

• pip.log: the Python dependencies installation

• install.log: the database installation (for development branches, tests are included)

• odoosh-import-database.log: the last imported dump process

• odoo.log: the running server

• update.log: the database updates

• pg_slow_queries.log: psql queries that take an unusual amount of time

• sh_webshell.log: the actions taken in the webshell

• sh_editor.log: the actions taken in the editor

• neutralize.log: the neutralization of the database (only staging)

When new lines are added to the logs, they are displayed automatically. If you scroll to the bottom, the browser scrolls automatically each time a new line is added.

You can pause the logs fetching process by clicking the (pause) button in the upper right corner. Otherwise, the process stops after five minutes. You can restart it by clicking the (play) button.

Back-ups

The Backups tab lists the available backups to download and restore, lets you perform a manual backup and import a database.

The production database is automatically backed up daily. Seven daily, four weekly, and three monthly backups are kept. Each backup includes the database dump, the filestore (attachments and binary fields), logs, and sessions.

Bemerkung

You can refer to the estimated scheduling of automatic backups to gain a better understanding of how the system works. This file is updated daily, taking the current day as the departure point.

Staging and development databases are not automatically backed up. However, you can restore a backup of the production database in your staging branches, for testing purposes, or manually recover data that has been accidentally deleted from the production database.

The list contains the backups kept on the server of your production database. This server only keeps one month of backups: seven daily and four weekly backups.

Dedicated backup servers keep the same backups, as well as three additional monthly backups. To restore or download one of these monthly backups, contact Odoo Support.

When merging a commit updating the version of one or several modules (in __manifest__.py), or their linked Python dependencies (in requirements.txt), then Odoo.sh performs an automatic backup (flagged with type Update in the list), as either the container will be changed by the installation of new pip packages, either the database itself will be changed with the module update triggered afterwards. In these two cases, a backup is triggered as it may break something.

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.

Phase	Automatic backup	Manual backup
Produktion	Yes (up to 3 months)	Yes (3 days)
Staging	Nein	Yes (3 days)
Entwicklung	Nein	Nein

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.

Werkzeuge

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.

Modulinstallation

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.