Branches et environnements
Un projet Karizma One est un dépôt Git hébergé sur GitLab. Chaque branche de ce dépôt a un type qui détermine si elle dispose d'un environnement Odoo en service. Cette page explique comment faire circuler votre code d'une branche de développement jusqu'à la production, en glissant les branches d'une section à l'autre dans la colonne de gauche de la page projet.
Page projet, colonne de gauche. Créer, déployer, détruire ou supprimer une branche est réservé aux rôles Super Admin, Admin et Developer. Créer une merge request et gérer les sous-modules est réservé aux Super Admin et Admin. Un Tester consulte les branches sans les modifier.
Les types de branches
| Section | Type | Environnement | Rôle |
|---|---|---|---|
| PRODUCTION | Production | Oui | Votre instance Odoo réelle, utilisée par vos équipes. Une seule par projet, créée avec le projet et nommée d'après la version d'Odoo (par exemple 17.0). |
| STAGING | Staging | Oui | Un environnement de test complet, déployé à partir d'une branche, pour valider les développements avant la production. Leur nombre est limité. |
| MIGRATION | Migration | Non | Une branche créée lors d'une montée de version d'Odoo. La section n'apparaît que s'il existe au moins une branche de migration. |
| DEVELOPMENT (n) | Développement | Non | Une branche Git uniquement, pour coder. Le compteur indique le nombre de branches. |
Les branches de développement et de migration n'ont pas d'environnement Odoo : elles n'affichent que les onglets HISTORY et CONFIG.
Le schéma ci-dessous résume les déplacements possibles entre sections.
Seuls ces déplacements sont acceptés. Tout autre glisser-déposer est refusé avec le message Cannot move a … branch to …. Vous pouvez aussi glisser une branche à l'intérieur de sa section pour changer l'ordre d'affichage ; l'ordre est conservé.
Créer une branche de développement
Une branche de développement peut partir de n'importe quelle branche du projet.
- Dans l'en-tête DEVELOPMENT, cliquez sur +.
- Dans Source branch, choisissez la branche de départ.
- Dans Target branch, saisissez le nom de la nouvelle branche (lettres, chiffres,
_,.et-). - Appuyez sur Entrée.
La branche est créée dans GitLab et dans Karizma One, puis son onglet HISTORY s'ouvre. Si le nom existe déjà, le message A branch with this name already exists s'affiche.
Au-delà de 20 branches de développement, une icône d'avertissement jaune apparaît dans l'en-tête de la section (There are too many branches, consider cleaning unused branches). Pensez à supprimer les branches qui ne servent plus.
Déployer une staging
Déployer une staging crée un environnement Odoo complet à partir du code d'une branche existante. Vous pouvez le faire de deux façons :
- Par glisser-déposer : glissez une branche de la section DEVELOPMENT sur la section STAGING, puis confirmez avec Deploy dans la fenêtre Deploy to staging.
- Par son nom : cliquez sur + dans l'en-tête STAGING, saisissez le nom de la branche (Enter staging branch name) et appuyez sur Entrée. Le déploiement démarre sans confirmation et l'onglet HISTORY de la branche s'ouvre.
Le déploiement s'exécute en arrière-plan :
- Karizma One vérifie que la branche a un pipeline GitLab réussi. Sinon, le déploiement est refusé (par exemple No successful pipeline found for branch '…'). Voir Déploiements et pipelines.
- L'environnement est préparé. La ligne de la branche affiche une roue qui tourne et les onglets indiquent Deployment in Progress. Comptez quelques minutes.
- Le point de la branche passe au vert : la staging est prête. Le bouton Connect de la page projet ouvre son instance Odoo.
Si le déploiement échoue, la branche revient dans la section DEVELOPMENT.
Limites et messages de refus
| Message | Cause |
|---|---|
| Staging environments are disabled for this project. | Le projet n'a droit à aucune staging. Contactez votre interlocuteur Karizma. |
| Maximum number of staging environments reached for this project. | Le nombre de stagings autorisé est atteint. Détruisez une staging inutilisée, achetez-en davantage avec la ressource Stagings ou contactez votre interlocuteur Karizma. |
| This branch is already in a staging environment. | La branche est déjà déployée en staging. |
| Another deployment is in progress. Please wait. / A branch is already deploying… | Un autre déploiement est en cours sur le projet ; attendez qu'il se termine. |
| Invalid branch name | Le nom de la branche doit commencer par une lettre ou un chiffre. |
| Cannot deploy to staging | La branche est sur une version d'Odoo plus ancienne que celle du projet. |
Détruire une staging
Détruire une staging supprime son environnement Odoo mais conserve la branche Git, qui retourne dans la section DEVELOPMENT.
- Glissez la branche de la section STAGING sur la section DEVELOPMENT.
- Dans la fenêtre Destroy staging environment, confirmez avec Destroy.
Une staging marquée d'un cadenas est verrouillée : elle ne peut pas être détruite (Locked staging environments cannot be destroyed). Pour la déverrouiller, contactez votre interlocuteur Karizma.
Livrer une staging en production
Glisser une staging sur la section PRODUCTION ne modifie pas directement la production : cela crée une merge request de la staging vers la branche de production.
- Glissez la branche de la section STAGING sur la section PRODUCTION.
- Dans la fenêtre Merge to production, saisissez éventuellement un titre (Enter a merge request title).
- Cliquez sur Create merge request. Le message Merge request created successfully! confirme la création.
La merge request doit ensuite être validée. Une fois fusionnée, le pipeline de la branche de production déploie le code en production. Voir Merge requests et Déploiements et pipelines.
Promouvoir une branche de migration en staging
Une branche de migration, créée depuis l'onglet UPGRADE de la production, doit être déployée en staging pour être testée.
- Glissez la branche de la section MIGRATION sur la section STAGING.
- Dans la fenêtre Promote to staging, confirmez avec Promote.
La staging obtenue tourne sur la nouvelle version d'Odoo et porte l'icône cyan correspondante. La suite de la montée de version (récupération de la base migrée, passage en production) se fait dans son onglet UPGRADE.
Supprimer une branche de développement
- Ouvrez la branche de développement.
- Dans la barre d'actions, cliquez sur Delete.
- Confirmez avec Delete Branch.
La branche est supprimée aussi dans GitLab ; l'action est définitive. Vous êtes ensuite redirigé vers la branche de production.
Une branche déployée en staging ne peut pas être supprimée. Détruisez d'abord sa staging (la branche revient dans DEVELOPMENT), attendez la fin de l'opération, puis supprimez-la. La branche de production ne peut pas être supprimée.
Gérer les sous-modules
Le bouton Submodules de la barre d'actions ajoute ou retire des sous-modules Git sur une branche de production ou de staging. La fenêtre Add/Update Submodule propose deux sources :
| Onglet | Source |
|---|---|
| Karizma Submodules | Les modules fournis par Karizma. Saisissez le nom du sous-module (par exemple kzm_odoo). |
| Custom Submodules | Vos propres dépôts, depuis le compte GitHub, GitLab ou Bitbucket relié à votre profil. Choisissez le dépôt puis la branche, ou saisissez l'URL du dépôt. Le jeton doit avoir la portée repo (GitHub) ou read_api (GitLab). |
Pendant l'ajout, la barre d'actions affiche Adding Submodule.
Demandes soumises à approbation
Certaines opérations sur les sous-modules doivent être approuvées par le chef de projet :
- l'ajout d'un sous-module Karizma : si vous n'êtes pas chef de projet, saisissez un Motif (raison de la demande). Le message Submodule request sent to project manager. confirme l'envoi ;
- le retrait d'un sous-module : le chef de projet voit Delete submodule ; les autres collaborateurs voient Request Deletion et doivent saisir un motif.
Le chef de projet reçoit une notification de la demande ; pour la faire traiter, contactez votre interlocuteur Karizma. Une fois la demande approuvée, un pipeline s'exécute sur la branche.