Builds¶
Übersicht¶
In Odoo.sh wird ein Build als eine Datenbank betrachtet, die von einem Odoo-Server (odoo/odoo & odoo/enterprise) geladen wird, der auf einer bestimmten Revision Ihres Projekt-Repositorys in einer containerisierten Umgebung läuft. Ihr Zweck ist es, das gute Verhalten des Servers, der Datenbank und der Funktionen mit dieser Revision zu testen.
In dieser Ansicht steht eine Zeile für einen Zweig und eine Zelle einer Zeile für ein Build dieses Zweigs.
In den meisten Fällen werden Builds nach einem Push auf die Zweige Ihres Github-Repositorys erstellt. Sie können auch erstellt werden, wenn Sie andere Vorgänge durchführen, z. B. eine Datenbank in Odoo.sh importieren oder einen Rebuild für einen Zweig in Ihrem Projekt anfordern.
Ein Build gilt als erfolgreich, wenn bei seiner Erstellung keine Fehler oder Warnungen auftreten. Ein erfolgreicher Build wird grün hervorgehoben.
Ein Build gilt als fehlgeschlagen, wenn bei seiner Erstellung Fehler auftreten. Ein fehlgeschlagener Build wird in rot hervorgehoben.
Wenn während der Erstellung Warnungen, aber keine Fehler auftreten, wird der Build als fast erfolgreich betrachtet. Er wird gelb hervorgehoben, um den Entwickler darauf hinzuweisen, dass Warnungen aufgetreten sind.
Builds erstellen nicht immer eine Datenbank von Grund auf. Wenn Sie z. B. eine Änderung in den Produktionszweig übertragen, startet der erstellte Build nur den Server mit Ihrer neuen Revision und versucht, die aktuelle Produktionsdatenbank darauf zu laden. Wenn keine Fehler auftreten, gilt der Build als erfolgreich, andernfalls als fehlgeschlagen.
Phasen¶
Produktion¶
Der erste Build eines Produktionszweigs erstellt eine Datenbank von Grund auf neu erstellt. Wenn dieser Build erfolgreich ist, wird diese Datenbank als Produktionsdatenbank Ihres Projekts betrachtet.
Von da an werden bei Pushs auf dem Produktionszweig neue Builds erstellt, die versuchen, die Datenbank mit einem Server zu laden, der mit der neuen Revision läuft.
Wenn der Build erfolgreich ist oder Warnungen, aber keine Fehler aufweist, wird die Produktionsdatenbank nun mit diesem Build und der zugehörigen Revision ausgeführt.
Wenn der Build beim Laden oder Aktualisieren der Datenbank fehlschlägt, wird der vorherige erfolgreiche Build erneut zum Laden der Datenbank verwendet, sodass die Datenbank auf einem Server mit der vorherigen erfolgreichen Revision läuft.
Der Build, mit dem die Produktionsdatenbank ausgeführt wird, steht immer an erster Stelle in der Liste der Builds. Wenn ein Build fehlschlägt, wird er nach dem Build, mit dem die Produktionsdatenbank ausgeführt wird, eingefügt.
Staging¶
Staging-Builds duplizieren die Produktionsdatenbank und versuchen, dieses Duplikat mit den Revisionen der Staging-Zweige zu laden.
Jedes Mal, wenn Sie eine neue Revision in einen Staging-Zweig verschieben, verwendet der erstellte Build eine neue Kopie der Produktionsdatenbank. Die Datenbanken werden nicht zwischen Builds desselben Zweigs wiederverwendet. Dies stellt sicher:
dass Staging-Builds Datenbanken verwenden, die dem Aussehen der Produktion sehr nahe kommen, damit Sie Ihre Tests nicht mit veralteten Daten durchführen müssen,
dass Sie in derselben Staging-Datenbank so viel herumspielen können, wie Sie wollen, und Sie können dann einen Rebuild anfordern, wenn Sie mit einer neuen Kopie der Produktion neu starten möchten.
Das bedeutet jedoch, dass Konfigurationsänderungen, die Sie in den Staging-Datenbanken vornehmen und nicht in der Produktion anwenden, nicht an den nächsten Build desselben Staging-Zweigs weitergegeben werden.
Entwicklung¶
Entwicklungs-Builds erstellen neue Datenbanken, laden die Demodaten und führen die Einheitstests aus.
Ein Build gilt als fehlgeschlagen und wird rot hervorgehoben, wenn die Tests während der Installation fehlschlagen, da sie Fehler auslösen sollen, wenn etwas falsch läuft.
Wenn alle Tests erfolgreich sind und kein Fehler auftritt, wird der Build als erfolgreich betrachtet.
Je nach der Liste der zu installierenden und zu testenden Module kann es bis zu 1 Stunde dauern, bis ein Entwicklungs-Build fertig ist. Das liegt an der großen Anzahl von Tests, die in der standardmäßigen Odoo Modul-Suite enthalten sind.
Funktionen¶
Der Produktionszweig erscheint immer zuerst, und die anderen Zweige sind nach dem zuletzt erstellten Build geordnet. Sie können die Zweige herausfiltern.
Für jeden Zweig können Sie über den Link Connect (Verbinden) auf die Datenbank des letzten Builds zugreifen und über den Link Github zum Code des Zweigs springen. Für andere Zweige als den Produktionszweig können Sie über den Link Rebuild einen neuen Build erstellen, der die letzte Revision des Zweigs verwendet. Dieser letzte Link ist nicht verfügbar, wenn bereits ein Build für den Zweig in Arbeit ist.
Für jeden Build können Sie über die Schaltfläche mit dem Github-Symbol auf die Revisionsänderungen zugreifen. Über die Schaltfläche Verbinden können Sie als Administrator auf die Datenbank des Builds zugreifen. Sie können auch mit einem anderen Benutzer auf die Datenbank zugreifen, indem Sie die Schaltfläche Verbinden als im Drop-down-Menü der Schaltfläche Verbinden verwenden.
