openpaas esn
1.0.0
OpenPaaS est votre prochaine plateforme de collaboration, pour les entreprises et les organisations.
Découvrez la plateforme OpenPaaS sur votre machine en 5 minutes en consultant la recette de démonstration docker-compose.
Consultez le guide d'installation pour installer OpenPaaS sur un serveur Linux et commencez à l'utiliser maintenant ! Si vous êtes un développeur à la recherche d'une configuration de développement, rendez-vous à la section suivante :
Les développeurs sont plus que bienvenus pour aider à créer OpenPaaS ! Pour que votre environnement de développement soit opérationnel, consultez notre documentation d'installation pour les développeurs.
Une fois que vous êtes prêt à partir, vous pouvez explorer le site de documentation du projet et la documentation de ce référentiel. Si vous avez des questions, n'hésitez pas à venir les poser sur le forum !
Nous utilisons actuellement Gitlab CI.
Par conséquent, vous pouvez consulter le fichier .gitlab-ci.yml à la racine de ce référentiel pour plus d'informations.
Cependant, certaines tâches sont plus compliquées que prévu, car elles dépendent d'outils externes.
J'espère que pour vous, ces tâches seront les dernières en cours d'exécution ; Les travaux de linters, de construction et de tests sont simples.
Les jobs "complexes" sont ceux dédiés au CD (Continuous Delivery) dont la raison principale est que nous livrons les images Docker à deux registres différents.
La principale complexité concerne les branches git et leur livraison associée, la matrice suivante pourrait vous aider :
| Nom de la succursale | Registre interne | DockerHub |
|---|---|---|
master | openpaas-snapshots/openpaas-esn:branch-master | linagora/esn:branch-master |
release-* (1) | openpaas-snapshots/openpaas-esn :* | linagora/esn:branche-* |
feature-* (2) | openpaas-snapshots/openpaas-esn :* | linagora/français :* |
(1) Le but des branches de release est de pouvoir maintenir la release (backport de correctifs de bugs, correctifs CVE...), puis produire des versions mineures basées sur cette version majeure.
Ils doivent être préfixés par release- . par exemple, la version git branch name release-1.6.x fournira :
(2) Les branches de fonctionnalités ne sont pas publiées. Ils sont utilisés pour publier et valider des fonctionnalités (peut-être plusieurs MR et commits). Ils doivent être préfixés par feature- . eb git branch name feature-friday-delivery build fournira :
Affero GPL v3
BrowserStack pour prendre en charge les projets open source.
