Builds¶
In Odoo.sh ist ein Build eine Datenbank, die von einem Odoo-Server (odoo/odoo und odoo/enterprise) geladen wird, der auf einer bestimmten Revision Ihres Projekt-Repositorys in einer containerisierten Umgebung läuft. Sein Zweck ist es, das ordnungsgemäße Verhalten des Servers, der Datenbank und der mit dieser Revision verbundenen Funktionen zu testen.
Übersicht¶
In der Ansicht Builds stellt eine Zeile einen Branch dar, und eine Zelle innerhalb dieser Zeile stellt einen Build dieses Branches dar.
Die meisten Builds werden nach Pushes zu Ihren GitHub-Repository-Branches erstellt. Sie können auch durch andere Vorgänge erstellt werden, z. B. durch das Importieren einer Datenbank auf Odoo.sh oder durch das Anfordern eines Rebuilds für einen Branch in Ihrem Projekt.
Builds können drei mögliche Status haben:
Ein Build gilt als erfolgreich, wenn während seiner Erstellung keine Fehler oder Warnungen auftreten. Erfolgreiche Builds sind grün hervorgehoben.
Ein Build gilt als nahezu erfolgreich, wenn Warnungen auftreten, aber keine Fehler vorliegen. Nahezu erfolgreiche Builds sind gelb hervorgehoben.
Ein Build gilt als fehlgeschlagen, wenn während seiner Erstellung Fehler auftreten. Fehlgeschlagene Builds sind rot hervorgehoben.
Bemerkung
Builds erstellen nicht immer eine Datenbank von Grund auf. Wenn Sie beispielsweise eine Änderung am Produktions-Branch pushen, startet der erstellte Build den Server mit Ihrer neuen Revision und versucht, die aktuelle Produktionsdatenbank darauf zu laden.
Phasen¶
Produktion¶
Der erste Build eines Produktions-Branches erstellt eine Datenbank von Grund auf. Wenn dieser Build erfolgreich ist, wird diese Datenbank zur Produktionsdatenbank Ihres Projekts.
Von da an erstellen Pushes zum Produktions-Branch neue Builds, die versuchen, die Datenbank mit einem Server zu laden, der die neue Revision ausführt.
Wenn der Build erfolgreich oder nahezu erfolgreich ist, läuft die Produktionsdatenbank mit diesem Build und der zugehörigen Revision.
Wenn der Build die Datenbank nicht laden oder aktualisieren kann, wird der vorherige erfolgreiche Build wiederverwendet, um die Datenbank zu laden. In diesem Fall läuft die Datenbank weiterhin mit der vorherigen erfolgreichen Revision.
Bemerkung
Der Build, der zum Ausführen der Produktionsdatenbank verwendet wird, steht immer an erster Stelle in der Build-Liste. Wenn ein Build fehlschlägt, wird er nach dem Build platziert, der die Produktionsdatenbank aktuell ausführt.
Staging¶
Staging-Builds duplizieren die Produktionsdatenbank und versuchen, diese Kopie mit den Revisionen der Staging-Branches zu laden.
Jedes Mal, wenn Sie eine neue Revision zu einem Staging-Branch pushen, verwendet der resultierende Build eine neue Kopie der Produktionsdatenbank. Datenbanken werden nicht zwischen Builds desselben Branches wiederverwendet. Dies stellt sicher, dass:
Staging-Builds Datenbanken verwenden, die dem aktuellen Produktionszustand sehr ähnlich sind, sodass Ihre Tests nicht mit veralteten Daten durchgeführt werden.
Sie können innerhalb einer Staging-Datenbank frei experimentieren. Wenn Sie mit einer neuen Kopie der Produktionsdatenbank von vorne beginnen möchten, können Sie einen Rebuild anfordern.
Dies bedeutet jedoch auch, dass wenn Sie Konfigurationsänderungen in einer Staging-Datenbank vornehmen und diese nicht in der Produktion anwenden, diese Änderungen im nächsten Build desselben Staging-Branches nicht vorhanden sind.
Entwicklung¶
Entwicklungs-Builds erstellen neue Datenbanken, laden die Demodaten und führen die Unit-Tests aus.
Ein Build gilt als fehlgeschlagen, wenn Tests während der Installation fehlschlagen, da sie so konzipiert sind, dass sie Fehler auslösen, wenn etwas nicht stimmt.
Wenn alle Tests erfolgreich sind und keine Fehler auftreten, gilt der Build als erfolgreich.
Bemerkung
Abhängig von der Liste der zu installierenden und zu testenden Module kann ein Entwicklungs-Build bis zu einer Stunde dauern, bis er bereit ist. Dies liegt an der großen Anzahl von Tests, die in der Standard-Odoo-Modul-Suite enthalten sind.
Funktionen¶
Der Produktionszweig erscheint immer zuerst. Andere Zweige sind nach dem Zeitpunkt ihres zuletzt erstellten Builds sortiert. Die lila hervorgehobene Stufe entspricht der im Menü Branches ausgewählten Stufe.
Tipp
Sie können Zweige über die Suchleiste filtern.
Für jeden Zweig können Sie:
Auf die Datenbank des letzten Builds zugreifen, indem Sie auf Connect klicken.
Zum Code des Zweigs springen, indem Sie auf Github klicken.
Einen neuen Build erstellen, indem Sie auf Rebuild klicken. Dabei wird die neueste Revision des Zweigs verwendet (nicht verfügbar, wenn bereits ein Build für diesen Zweig läuft).
Für jeden Build können Sie:
Die Änderungen der Revision anzeigen, indem Sie auf das (GitHub)-Symbol klicken.
Auf die Datenbank des Builds als Administrator zugreifen, indem Sie auf Connect klicken, oder als anderer Benutzer, indem Sie auf die -Schaltfläche (More Actions) neben Connect klicken und Connect as auswählen.
Auf dieselben Werkzeuge wie in der Zweige-Ansicht zugreifen, indem Sie auf die -Schaltfläche (More Actions) neben Connect klicken und Logs, Web Shell, Editor, Outgoing e-mails (für die Staging- und Entwicklungsstufen), Monitoring und Download DB dump (für die Produktions- und Stagingstufen) auswählen.
