Branches

Vue d’ensemble

La vue Branches vous donne une vue d’ensemble des différentes branches de votre dépôt.

Étapes

Odoo.sh propose trois phases différentes pour vos branches : production, simulation et développement.

Vous pouvez changer la phase d’une branche en la glissant et déposant dans le titre de section de la phase.

Production

Il s’agit de la branche contenant le code sur lequel tourne votre base de données de production. Il ne peut y avoir qu’une seule branche de production.

Lorsque vous poussez un nouveau commit vers cette branche, votre serveur de production est mis à jour avec le code de la nouvelle révision et est ensuite redémarré.

Si vos modifications nécessitent la mise à jour d’un module, comme une modification d’une vue de formulaire et si vous voulez qu’elle soit effectuée automatiquement, augmentez le numéro de version du module dans son manifeste (__manifest__.py). La plateforme se chargera alors d’effectuer la mise à jour pendant laquelle l’instance sera temporairement indisponible pour des raisons de maintenance.

Cette méthode est similaire à la mise à niveau du module via le menu Applications ou via le commutateur -u de la ligne de commande.

Si les modifications dans le commit empêchent le serveur de redémarrer ou si la mise à jour du module échoue, le serveur est automatiquement ramené à la révision précédente du code et la base de données est rétablie telle qu’elle était avant la mise à jour. Vous avez toujours accès au journal de l’échec de la mise à jour, ce qui vous permet de résoudre les problèmes.

Les données de démonstration ne sont pas chargées, car elles ne sont pas destinées à être utilisées dans une base de données de production. Les tests unitaires ne sont pas effectués, car cela augmenterait le temps d’indisponibilité de la base de données de production pendant les mises à jour.

Les partenaires qui utilisent des projets d’essai doivent savoir que leur branche de production, ainsi que toutes les branches de simulation, seront automatiquement rétablies à la phase de développement après 30 jours.

Simulation

Les branches de simulation sont destinées à tester vos nouvelles fonctionnalités avec les données de production sans compromettre la base de données de production réelle avec des enregistrements de test. Elles créent des bases de données qui sont des doublons neutralisés de la base de données de production.

La neutralisation comprend :

• La désactivation des actions planifiées. Si vous voulez les tester, vous pouvez déclencher leur action manuellement ou les réactiver. Attention : la plateforme les déclenchera moins souvent si personne n’utilise la base de données afin d’économiser des ressources.

• La désactivation des emails sortants en les interceptant avec un mailcatcher. Une interface permettant de visualiser les emails envoyés par votre base de données est fournie. Ainsi, vous n’avez pas à vous soucier d’envoyer des emails de test à vos clients.

• La configuration des fournisseurs de paiement et des transporteurs en mode test.

• La désactivation des services IAP.

La dernière base de données sera maintenue en vie indéfiniment, les plus anciennes de la même branche peuvent être mises au rebut pour faire de la place aux nouvelles. Elle sera valide pendant 3 mois, après quoi vous devrez reconstruire la branche. Si vous effectuez des modifications de configuration ou de vue dans ces bases de données, assurez-vous de les documenter ou de les écrire directement dans les modules de la branche, en utilisant des fichiers de données XML qui remplacent la configuration ou les vues par défaut.

Les tests unitaires ne sont pas effectués, car, dans Odoo, ils reposent actuellement sur les données de démonstration, qui ne sont pas chargées dans la base de données de production. À l’avenir, si Odoo prend en charge l’exécution des tests unitaires sans les données de démonstration, Odoo.sh envisagera d’exécuter les tests sur les bases de données de simulation.

Développement

Les branches de développement créent de nouvelles bases de données en utilisant les données de démonstration pour exécuter les tests unitaires. Les modules installés sont ceux compris dans vos branches. Vous pouvez modifier la liste des modules à installer dans les paramètres de votre projet.

Lorsque vous poussez un nouveau commit vers une de ces branches, un nouveau serveur est démarré, avec une base de données créée à partir de zéro et la nouvelle révision de la branche. Les données de démonstration sont chargées et les tests unitaires sont effectués par défaut. Ceux-ci permettent de vérifier si vos modifications ne cassent aucune fonctionnalité testée. Si vous le souhaitez, vous pouvez désactiver les tests ou autoriser des tests spécifiques à exécuter grâce aux étiquettes personnalisées dans les paramètres de la branche.

Comme pour les branches de simulation, les emails ne sont pas envoyés, mais interceptés par un mailcatcher et les actions planifiées ne sont pas déclenchées tant que la base de données n’est pas utilisée.

Les bases de données créées pour les branches de développement ont une durée de vie de trois jours. Passé ce délai, elles peuvent être automatiquement vidées pour faire de la place à de nouvelles bases de données sans notification préalable.

Fusionner vos branches

Vous pouvez facilement fusionner vos branches en les glissant et déposant l’une sur l’autre.

Si vous voulez tester les modifications de vos branches de développement avec les données de production, vous pouvez :

• fusionner la branche de développement avec votre branche de simulation, en la glissant et déposant sur la branche de simulation souhaitée,

• glisser et déposer la branche de développement sur le titre de la section de simulation, pour qu’elle devienne une branche de simulation.

Lorsque vos dernières modifications sont prêtes pour la production, vous pouvez glisser et déposer votre branche de simulation sur votre branche de production pour fusionner et déployer vos nouvelles fonctionnalités en production.

Si vous êtes audacieux, vous pouvez également vos branches de développement avec votre branche de production. Cela signifie que vous sautez l’étape de validation de vos modification avec les données de production par le biais d’une branche de simulation.

Vous pouvez fusionner vos branches de développement l’une avec l’autre et vos branches de simulation l’une avec l’autre.

Bien évidemment, vous pouvez également utiliser directement git merge sur votre poste de travail pour fusionner vos branches. Odoo.sh sera notifié lorsque les nouvelles révisions ont été poussées vers vos branches.

La fusion d’une branche de simulation dans la branche de production

Si vous testez des modifications de configuration dans les branches de simulation et vous voulez qu’elles soient appliquées en production, vous devez :

• soit les modifications de configuration dans des fichiers de données XML remplaçant la configuration ou les vues par défaut dans vos branches et ensuite augmenter la version de votre module dans son manifeste (__manifest__.py) afin de déclencher la mise à jour du module lorsque vous fusionnez votre branche de simulation dans votre branche de production. C’est la meilleure pratique permettant une meilleure scalabilité de vos développements, puisque vous utiliserez les fonctionnalités de versioning de Git pour toutes les modifications de configuration et vous aurez ainsi une traçabilité de vos modifications.

• soit les passer manuellement de votre base de données de simulation à votre base de données de production en les copiant/collant.

Onglets

Historique

Une vue d’ensemble de l’historique de votre branche :

• Les messages des commits et de leurs auteurs,

• Les différents événements liés à la plateforme, tels que les changements de phase, les importations de base de données, les restaurations de sauvegardes.

Pour chaque événement, un statut s’affiche dans le coin supérieur droit. Il fournit des informations sur l’opération en cours sur la base de données (installation, mise à jour, importation de la sauvegarde…) et sur ses résultats (retour sur les tests, importation de la sauvegarde réussie…). Lorsqu’une opération est réussie, vous pouvez accéder à la base de données en cliquant sur le bouton connect.

Emails

Cet onglet contient le mailcatcher. Il affiche un aperçu des emails envoyés par votre base de données. Le mailcatcher est disponible pour vos branches de développement et de simulation, puisque les emails de votre base de données de production sont réellement envoyés et non interceptés.

Shell

Un accès shell à votre conteneur. Vous pouvez exécuter des commandes linux de base (ls, top) et ouvrir un shell sur votre base de données en tapant psql.

Vous pouvez ouvrir plusieurs onglets et les glisser-déposer pour organiser la présentation comme vous le souhaitez, par exemple côte à côte.

Note

Les instances de shell qui fonctionnent longtemps ne sont pas garanties. Les shells inactifs peuvent être déconnectés à tout moment afin de libérer des ressources.

Éditeur

Un environnement de développement intégré (IDE) en ligne pour éditer le code source. Vous pouvez également ouvrir des terminaux, des consoles de python et même des consoles de shll Odoo.

Vous pouvez ouvrir plusieurs onglets et les glisser-déposer pour organiser la présentation comme vous le souhaitez, par exemple côte à côte.

Monitoring

Ce lien contient diverses mesures de monitoring du build actuel.

Vous pouvez zoomer, modifier l’intervalle de temps ou sélectionner une mesure spécifique sur chaque graphique. Sur les graphiques, des annotations vous aident à faire le lien avec les changements sur le build (importation de la base de données, git push, etc.).

Historiques

Une page qui vous permet de jeter un coup d’œil aux journaux de votre serveur.

Plusieurs journaux sont disponibles :

• install.log : Les journaux de l’installation de votre base de données. Dans une branche de développement, les journaux des tests sont inclus.

• pip.log : Les journaux de l’installation des dépendances Python.

• odoo.log : Les journaux du serveur en cours d’exécution.

• update.log : Les journaux des mises à jour de la base de données.

• pg_long_queries.log : Les journaux des requêtes psql qui prennent un temps inhabituel à s’exécuter.

Si de nouvelles lignes sont ajoutées aux journaux, elles seront affichées automatiquement. Si vous faites défiler la page jusqu’en bas, le navigateur défilera automatiquement chaque fois qu’une nouvelle ligne est ajoutée.

Vous pouvez interrompre l’extraction des journaux en cliquant sur le bouton correspondant dans le coin supérieur droit de la page. L’extraction est automatiquement interrompue après 5 minutes. Vous pouvez la relancer en cliquant sur le bouton Play.

Sauvegardes

Une liste des sauvegardes disponibles pour le téléchargement et la restauration, la possibilité d’effectuer une sauvegarde manuelle et d’importer une base de données.

Odoo.sh effectue des sauvegardes quotidiennes de la base de données de production. Il conserve 7 sauvegardes quotidiennes, 4 hebdomadaires et 3 mensuelles. Chaque sauvegarde inclut le dump de la base de données, le filestore (pièces jointes, champs binaires), les journaux et les sessions.

Les bases de données de simulation et de développement ne sont pas sauvegardées. Cependant, vous avez la possibilité de restaurer une sauvegarde de la base de données de production dans vos branches de simulation, à des fins de test, ou pour récupérer manuellement des données qui ont été supprimées accidentellement de la base de données de production.

La liste contient les sauvegardes conservées sur le serveur sur lequel votre base de données de production est hébergée. Ce serveur ne conserve qu’un mois de sauvegardes : 7 sauvegardes quotidiennes et 4 hebdomadaires.

Les serveurs de sauvegarde dédiés conservent les mêmes sauvegardes, ainsi que 3 sauvegardes mensuelles supplémentaires. Afin de restaurer ou télécharger une de ces sauvegardes mensuelles, veuillez nous contacter.

Si vous fusionnez un commit mettant à jour la version d’un ou plusieurs modules (dans __manifest__.py), ou leurs dépendances Python liées (dans requirements.txt), Odoo.sh effectue une sauvegarde automatiquement (signalée avec le type Mise à jour dans la liste), car soit le conteneur sera modifié par l’installation de nouveaux paquets pip, soit la base de données elle-même sera modifiée avec la mise à jour du module déclenchée par la suite. Dans ces deux cas, nous effectuons une sauvegarde, car cela peut potentiellement casser des choses.

Si vous fusionnez un commit qui ne change que du code sans les modifications susmentionnées, alors aucune sauvegarde n’est faite par Odoo.sh, car ni le conteneur ni la base de données ne sont modifiés et la plateforme considère que c’est suffisamment sûr. Bien sûr, comme précaution supplémentaire, vous pouvez faire une sauvegarde manuelle avant de faire des changements importants dans vos sources de production au cas où quelque chose se passerait mal (ces sauvegardes manuelles sont disponibles pendant environ une semaine). Pour éviter les abus, nous limitons les sauvegardes manuelle à 5 par jour.

La fonctionnalité d”importation de la base de données accepte les archives de base de données dans le format fourni par :

• le gestionnaire de bases de données Odoo standard (disponible pour les serveurs Odoo On Premise dans /web/database/manager)

• le gestionnaire de bases de données Odoo Online,

• le bouton de téléchargement des sauvegardes Odoo.sh de l’onglet Backups,

• le bouton de téléchargement du dump Odoo.sh sans la vue Builds.

Mettre à jour

Disponible pour les branches de production et de simulation des projets valides.

Pour plus d'infos

Upgrade documentation

Paramètres

Vous trouverez ici certains paramètres qui ne s’appliquent qu’à la branche actuellement sélectionnée.

Comportement lors d’un nouveau commit

Pour les branches de développement et de simulation, vous pouvez modifier le comportement de la branche lors de l’arrivée d’un nouveau commit. Par défaut, une branche de développement créera un nouveau build et une branche de simulation mettra à jour le build précédent (voir la Phase de production). Ceci est particulièrement utile si vous nécessitez une configuration particulière pour éviter d’avoir à la reconfigurer manuellement à chaque nouveau commit. Si vous choisissez un nouveau build pour une branche de simulation, elle fera une nouvelle copie du build de production chaque fois qu’un commit est poussé. Une branche qui est renvoyée de simulation à développement sera automatiquement configurée sur “Do nothing”.

Installation de modules

Choisissez les modules à installer automatiquement pour vos builds de développement.

• Installer uniquement mes modules installera uniquement les modules de la branche. C’est l’option sélectionnée par défaut. Les sous-modules sont exclus.

• Installation complète (tous les modules) installera les modules de la branche, les modules compris dans les sous-modules et tous les modules standards d’Odoo. Lors de l’installation complète, la suite de tests est désactivée.

• Installer une liste de modules installera les modules précisés dans la case juste en-dessous de cette option. Les noms sont le nom technique des modules et ils doivent être séparés par des virgules.

Si les tests sont désactivés, la suite de modules standards d’Odoo peut prendre jusqu’à une heure. Ce paramètre s’applique uniquement aux builds de développement. Les builds de simulation duplique le build de production et le build de production n’installe que la base.

Suite de tests

Pour les branches de développement, vous pouvez choisir d’activer ou de désactiver la suite de tests. Elle est désactivée par défaut. Lorsque la suite de tests est activée, vous pouvez la limiter en définissant des étiquettes de test.

Version d’Odoo

Uniquement pour les branches de développement, vous pouvez modifier la version d’Odoo, si vous souhaitez tester un code mis à niveau ou développer des fonctionnalités, tandis que votre base de données de production est en cours de mise à niveau vers une version plus récente.

De plus, pour chaque version, vous disposez de deux options concernant la mise à jour du code :

• Vous pouvez choisir de bénéficier automatiquement des derniers correctifs de bugs, de sécurité et de performance. Les sources de votre serveur Odoo seront mises à jour chaque semaine. Il s’agit de l’option “Latest”.

• Vous pouvez choisir d’épingler les sources d’Odoo à une révision spécifique en les sélectionnant dans une liste de dates. Les révisions expirent après 3 mois. Vous serez notifié par email lorsque la date d’expiration approche et si vous ne prenez aucune action, vous sera automatiquement remis à la dernière révision.

Domaines personnalisés

Ici, vous pouvez configurer des domaines additionnels pour la branche sélectionnée. Il est possible d’ajouter d’autres domaines <name>.odoo.com ou vos propres domaines personnalisés. Pour la dernière option, vous devez :

• posséder ou acheter le nom de domaine,

• ajouter le nom de domaine dans cette liste,

• dans le gestionnaire de noms de domaine de votre bureau d’enregistrement, configurez le nom de domaine avec un enregistrement CNAME défini sur le nom de domaine de votre base de données de production.

Par exemple, pour associer www.mycompany.com à votre base de données mycompany.odoo.com :

• dans Odoo.sh, ajoutez www.mycompany.com aux domaines personnalisés des paramètres de votre projet,

• dans le gestionnaire de votre nom de domaine (par ex. godaddy.com, gandi.net, ovh.com), configurez www.mycompany.com avec un enregistrement CNAME ayant pour valeur mycompany.odoo.com.

Les domaines nus (par ex. mycompany.com) ne sont pas acceptés :

• ils ne peuvent être configurés qu’à l’aide d’enregistrements A,

• Les enregistrements A n’acceptent que les adresses IP comme valeur,

• l’adresse IP de votre base de données peut changer, à la suite d’une mise à niveau, d’une panne matérielle ou de votre souhait d’héberger votre base de données dans un autre pays ou sur un autre continent.

Par conséquent, les domaines nus pourraient soudainement ne plus fonctionner en raison de ce changement d’adresse IP.

De plus, si vous voulez que mycompany.com et www.mycompany.com fonctionnent avec votre base de données, le fait que le premier redirige vers le second fait partie des meilleures pratiques en matière de référencement (consultez Fournir une version d’une URL pour atteindre un document) afin d’avoir une URL dominante. Vous pouvez donc simplement configurer mycompany.com pour qu’il redirige vers www.mycompany.com. La plupart des gestionnaires de domaines ont la possibilité de configurer cette redirection. C’est ce qu’on appelle communément une redirection web.

HTTPS/SSL

Si la redirection est correctement configurée, la plateforme générera automatiquement un certificat SSL avec Let’s Encrypt dans l’heure et votre domaine sera accessible via HTTPS.

Alors qu’il n’est actuellement plus possible de configurer vos propres certificats SSL sur la plateforme Odoo.sh, nous envisageons de le faire si la demande est suffisante.

Conformité SPF et DKIM

Si le domaine des adresses email de vos utilisateurs utilisent SPF (Sender Policy Framework) ou DKIM (DomainKeys Identified Mail), n’oubliez pas d’autoriser Odoo en tant qu’hôte d’envoi dans les paramètres de votre nom de domaine pour augmenter la délivrabilité de vos emails sortants. Les étapes de configuration sont expliquées dans la documentation sur SPF et DKIM.

Avertissement

Oublier de configurer votre SPF ou DKIM pour autoriser Odoo en tant qu’hôte d’envoi peut conduire à la livraison de vos emails en tant que spam dans la boîte de réception de vos contacts.

Commandes shell

Dans le coin supérieur droit de la vue, différentes commandes shell sont disponibles.

Chaque commande peut être copiée dans le presse-papier pour l’utiliser dans un terminal et certaines commandes peuvent être utilisées directement à partir de Odoo.sh en cliquant sur le bouton run. Dans ce cas, une fenêtre contextuelle invitera l’utilisateur à définir d’éventuels placeholders, tels que <URL>, <PATH>, …

Clone

Téléchargez le dépôt Git.

$ git clone --recurse-submodules --branch master git@github.com:odoo/odoo.git

Clone le dépôt odoo/odoo.

• --recurse-submodules : Télécharge les sous-modules de votre dépôt. Les sous-modules contenus dans les sous-modules sont également téléchargés.

• --branch : vérifie une branche spécifique du dépôt, dans ce cas master.

Le bouton run n’est pas disponible pour cette commande, car elle est destinée à être utilisée sur vos appareils.

Fork

Créez une nouvelle branche basée sur la branche actuelle.

$ git checkout -b feature-1 master

Crée une nouvelle branche intitulée feature-1 basée sur la branche master et procède au checkout.

$ git push -u origin feature-1

Charge la nouvelle branche feature-1 sur votre dépôt à distance.

Fusionner

Fusionnez la branche actuelle dans une autre branche.

$ git merge staging-1

Fusionne la branche staging-1 dans la nouvelle branche.

$ git push -u origin master

Charge les modifications que vous venez d’ajouter dans la branche master sur votre dépôt à distance.

SSH

Configuration

Afin d’utiliser SSH, vous devez configurer la clé publique SSH de votre profil (si ce n’est pas déjà fait). Pour ce faire, suivez les étapes suivantes :

1. Générez une nouvelle clé SSH

2. Copiez la clé SSH dans votre presse-papiers (n’appliquez que l’étape 1)

3. Collez le contenu copié dans les clés SSH de votre profil et cliquez sur « Add »

   

4. La clé devrait apparaître en-dessous

   

Connexion

Pour vous connecter à vos builds en utilisant ssh, exécutez la commande suivante dans un terminal :

$ ssh <build_id>@<domain>

Vous trouverez un raccourci pour cette commande dans l’onglet SSH dans le coin supérieur droit.

Si vous disposez des bons droits d’accès sur le projet, vous obtiendrez un accès ssh au build.

Note

Les connexions ssh de longue durée ne sont pas garanties. Les connexions inactives seront déconnectées afin de libérer des ressources.

Sous-module

Ajoutez une branche d’un autre dépôt à votre branche actuelle en tant que sous-module.

Les sous-modules vous permettent d’utiliser des modules d’autres dépôts dans votre projet.

La fonctionnalité des sous-modules est détaillée dans le chapitre Sous-modules de cette documentation.

$ git submodule add -b master <URL> <PATH>

Ajoute la branche master du dépôt <URL> en tant que sous-module sous le chemin <PATH> dans votre branche actuelle.

$ git commit -a

Enregistre toutes les modifications en cours.

$ git push -u origin master

Charge les modifications que vous venez d’ajouter dans la branche master sur votre dépôt à distance.

Supprimer

Supprimez une branche de votre dépôt.

$ git push origin :master

Supprime la branche de votre dépôt à distance.

$ git branch -D master

Supprime la branche dans votre copie locale du dépôt.