Builds¶
Dans Odoo.sh, un build est une base de données chargée par un serveur Odoo (odoo/odoo et odoo/enterprise) fonctionnant sur une révision spécifique du dépôt du projet dans un environnement conteneurisé. Son objectif est de tester le bon comportement du serveur, de la base de données et des fonctionnalités associées à cette révision.
Aperçu¶
Dans la vue Builds, une ligne représente une branche et une cellule au sein de cette ligne représente un build de cette branche.
La plupart des builds sont créés après des pushs vers les branches de votre dépôt GitHub. Ils peuvent également être créés par d’autres opérations, comme l’importation d’une base de données sur Odoo.sh ou la demande de reconstruction d’une branche dans votre projet.
Les builds peuvent avoir trois statuts possibles :
Un build est considéré comme réussi si aucune erreur ou avertissement ne survient lors de sa création. Les builds réussis sont surlignés en vert.
Un build est considéré comme presque réussi si des avertissements surviennent, mais qu’il n’y a pas d’erreurs. Les builds presque réussis sont surlignés en jaune.
Un build est considéré comme échoué si des erreurs surviennent lors de sa création. Les builds échoués sont surlignés en rouge.
Note
Les builds ne créent pas toujours une base de données à partir de zéro. Par exemple, lors du push d’une modification sur la branche de production, le build créé démarre le serveur avec votre nouvelle révision et tente d’y charger la base de données de production actuelle.
Étapes¶
Production¶
Le premier build d’une branche de production crée une base de données à partir de zéro. Si ce build réussit, cette base de données deviendra la base de données de production de votre projet.
À partir de ce moment, les pushs vers la branche de production créeront de nouveaux builds qui tenteront de charger la base de données en utilisant un serveur exécutant la nouvelle révision.
Si le build réussit ou est presque réussi, la base de données de production s’exécutera avec ce build et sa révision associée.
Si le build échoue à charger ou mettre à jour la base de données, le build réussi précédent est réutilisé pour charger la base de données. Dans ce cas, la base de données continue de s’exécuter en utilisant la révision réussie précédente.
Note
Le build utilisé pour exécuter la base de données de production est toujours le premier dans la liste des builds. Si un build échoue, il est placé après le build exécutant actuellement la base de données de production.
Simulation¶
Les builds de staging dupliquent la base de données de production et tentent de charger cette copie en utilisant les révisions des branches de staging.
Chaque fois que vous pushez une nouvelle révision vers une branche de staging, le build résultant utilise une copie fraîche de la base de données de production. Les bases de données ne sont pas réutilisées entre les builds d’une même branche. Cela garantit que :
Les builds de staging utilisent des bases de données qui correspondent étroitement à l’état actuel de la production, de sorte que vos tests ne sont pas effectués sur des données obsolètes.
Vous pouvez expérimenter librement dans une base de données de staging. Lorsque vous voulez recommencer avec une nouvelle copie de la base de données de production, vous pouvez demander une reconstruction.
Cependant, cela signifie également que si vous effectuez des modifications de configuration dans une base de données de staging et ne les appliquez pas en production, ces modifications ne seront pas présentes dans le prochain build de la même branche de staging.
Développement¶
Les builds de développement créent de nouvelles bases de données, chargent les données de démonstration et exécutent les tests unitaires.
Un build sera considéré comme échoué si des tests échouent lors de l’installation, car ils sont conçus pour lever des erreurs lorsque quelque chose ne va pas.
Si tous les tests réussissent et qu’aucune erreur ne survient, le build est considéré comme réussi.
Note
Selon la liste des modules à installer et tester, un build de développement peut prendre jusqu’à une heure pour être prêt. Cela est dû au grand nombre de tests inclus dans la suite de modules Odoo par défaut.
Fonctionnalités¶
La branche de production apparaît toujours en premier. Les autres branches sont classées selon l’heure de leur dernier build créé. L’étape surlignée en violet correspond à l’étape sélectionnée dans le menu Branches.
Astuce
Vous pouvez filtrer les branches à l’aide de la barre de recherche.
Pour chaque branche, vous pouvez :
Accéder à la base de données du dernier build en cliquant sur Connect.
Accéder au code de la branche en cliquant sur Github.
Créer un nouveau build en cliquant sur Rebuild. Cela utilise la dernière révision de la branche (non disponible si un build est déjà en cours pour cette branche).
Pour chaque build, vous pouvez :
Voir les modifications de la révision en cliquant sur l’icône (GitHub).
Accéder à la base de données du build en tant qu’administrateur en cliquant sur Connect ou en tant qu’autre utilisateur en cliquant sur le bouton (More Actions) à côté de Connect et en sélectionnant Connect as.
Accéder aux mêmes outils que dans la vue des branches en cliquant sur le bouton (More Actions) à côté de Connect et en sélectionnant Logs, Web Shell, Editor, Outgoing e-mails (pour les étapes de staging et de développement), Monitoring, et Download DB dump (pour les étapes de production et de staging).
