OpenPaaS ist Ihre nächste Kollaborationsplattform für Unternehmen und Organisationen.
Entdecken Sie die OpenPaaS-Plattform auf Ihrem Computer innerhalb von 5 Minuten, indem Sie sich das Demo-Docker-Compose-Rezept ansehen.
Schauen Sie sich die Installationsanleitung an, um OpenPaaS auf einem Linux-Server zu installieren und beginnen Sie jetzt mit der Nutzung! Wenn Sie als Entwickler nach einem Entwicklungs-Setup suchen, fahren Sie mit dem nächsten Abschnitt fort:
Entwickler sind herzlich willkommen, beim Aufbau von OpenPaaS mitzuhelfen! Um Ihre Entwicklungsumgebung zum Laufen zu bringen, lesen Sie die Installationsdokumentation für Entwickler.
Sobald Sie bereit sind, können Sie die Dokumentationsseite des Projekts und die Dokumentation dieses Repositorys erkunden. Wenn Sie Fragen haben, zögern Sie nicht, im Forum nachzufragen!
Wir verwenden derzeit Gitlab CI.
Weitere Informationen finden Sie daher in der Datei .gitlab-ci.yml
im Stammverzeichnis dieses Repositorys.
Einige Aufgaben sind jedoch komplizierter als erwartet, da sie auf externe Tools angewiesen sind.
Für Sie hoffen wir, dass solche Jobs die aktuellsten in der Pipeline-Ausführung sind; Linters, Build- und Testaufgaben sind einfach.
Bei den „komplexen“ Jobs handelt es sich um solche, die CD (Continuous Delivery) gewidmet sind. Der Hauptgrund dafür ist, dass wir Docker-Images an zwei verschiedene Register liefern.
Die Hauptkomplexität betrifft git
Branches und die damit verbundene Bereitstellung. Die folgende Matrix könnte Ihnen helfen:
Filialname | Interne Registrierung | DockerHub |
---|---|---|
master | openpaas-snapshots/openpaas-esn:branch-master | linagora/esn:branch-master |
release-* (1) | openpaas-snapshots/openpaas-esn:* | linagora/esn:branch-* |
feature-* (2) | openpaas-snapshots/openpaas-esn:* | linagora/esn:* |
(1) Das Ziel von Release-Zweigen besteht darin, in der Lage zu sein, Releases aufrechtzuerhalten (Bugfix-Backport, CVE-Fixes usw.) und dann kleinere Releases basierend auf diesem Hauptrelease zu erstellen.
Ihnen sollte release-
vorangestellt werden. Beispielsweise liefert git
Branch Name release-1.6.x
Build:
(2) Feature-Zweige werden nicht veröffentlicht. Sie werden verwendet, um Funktionen zu veröffentlichen und zu validieren (vielleicht mehrere MRs und Commits). Ihnen sollte feature-
vorangestellt werden. eb git
branch name feature-friday-delivery
build wird Folgendes liefern:
Affero GPL v3
BrowserStack zur Unterstützung von Open-Source-Projekten.