Travail en équipe : de la branche à la prod
Ce que vous allez construire
Un flux de release complet à deux rôles (une développeuse et un
release manager) sur un projet société : copie de travail, commit
semver, push et pull request, revue et merge, déploiement en dev,
promotion vers prod avec revue exigée, puis automatisation par un flux
CI/CD déclenché à chaque release. À chaque étape, les droits RBAC
nécessaires sont précisés.
- Un projet société avec du contenu (par exemple celui du tutoriel Du CSV à PostgreSQL) ;
- Deux comptes utilisateurs de la même organisation : « Dev » et « RM » (release manager) ;
- Un runner connecté pour les environnements ;
- Les notions de Studio : copies de travail et d'Environnements et déploiement.
Étape 1 : préparer l'équipe du projet
Sur le projet société, ouvrez l'onglet Accès (vous êtes propriétaire du projet : vous avez tous les droits) et ajoutez :
- Dev avec le niveau Éditeur : elle développe (pipelines, variables, connexions), déploie et exécute ;
- RM avec le niveau Admin : il édite, déploie et approuve les revues.
Un rôle attribué sur un projet n'accorde ses permissions que sur ce projet ; les administrateurs de société conservent leurs droits partout (voir Rôles et permissions).
Étape 2 : la chaîne d'environnements
Toujours sur le projet société, onglet Environnements, créez la chaîne
(action protégée par project:write, niveau Admin) :
dev: type Développement, ordre 1, votre runner comme cible d'exécution ;prod: type Production, ordre 2, Environnement de production coché et surtout Exiger une revue activé : tout déploiement versproddevra être approuvé.
L'ordre définit la chaîne de promotion : une release entre par dev et ne
peut être promue vers prod que si elle y est déjà déployée.
Étape 3 (Dev) : checkout, modification, commit
- Depuis la liste des projets, Dev clique sur Travailler dessus : sa copie de travail privée s'ouvre dans le Studio ;
- elle modifie un pipeline dans l'éditeur (chaque enregistrement crée une autosave) ;
- dans l'onglet Versions, elle compare son working tree au dernier commit : les composants modifiés (M), non suivis (U) ou supprimés (D) sont listés.
Chaque composant modifié peut être mis en scène (staging) avant le commit,
avec son intention semver.
Le commit :
- sélectionnez les composants à inclure (ou Tout stager) ;
- choisissez l'intention semver par composant, ici Mineur (une évolution compatible) ;
- écrivez un message de commit obligatoire, puis Commit : c'est le nouveau HEAD de la copie.
Étape 4 (Dev) : push et pull request
La copie est en avance sur l'origine : la barre de branche propose Ouvrir une PR. Le push crée, sous le capot, une release des commits et ouvre une pull request vers le projet société.
La PR liste les commits proposés ; le projet exigeant une revue, elle attend
une approbation dans l'onglet À valider.
L'origine a avancé pendant le travail : un Pull est requis avant de pouvoir ouvrir la PR, avec résolution visuelle des écarts (voir Pull et résolution de merge).
Étape 5 (RM) : revue et merge
La PR arrive dans l'onglet À valider du projet société. RM (niveau Admin : c'est lui qui approuve les revues) examine les changements proposés, puis approuve et merge : les commits deviennent la nouvelle version du projet société, et la release est prête à être déployée.
Étape 6 (RM) : déployer en dev
Onglet Environnements du projet société : sur la carte dev, RM
clique sur Déployer, choisit la release et valide (permission
deployment:execute).
Chaque environnement affiche sa release déployée, son état et ses actions.
Le déploiement pose un pointeur vers la release : aucune copie de
contenu. L'environnement dev sert la nouvelle version avec ses propres
valeurs de variables et connexions ; l'équipe peut la valider
fonctionnellement (Lancer maintenant sur les pipelines de
l'environnement).
Étape 7 : promotion vers prod, avec approbation
Une fois la release validée en dev, RM la promeut : Déployer sur la
carte prod (possible uniquement parce qu'elle est déjà déployée en
dev : la promotion est chain-aware, sauter une étape est refusé).
prod exigeant une revue, la promotion ne s'applique pas tout de suite :
- elle passe en attente de revue et le pointeur n'est pas encore posé : la carte affiche un bandeau En attente de revue avec Approuver / Rejeter ;
- un utilisateur disposant de
deployment:approve(ici RM, niveau Admin) clique sur Approuver : le quorum atteint (une approbation par défaut), la release est déployée enprod; - Rejeter aurait clos la promotion sans déploiement. Une même personne ne compte qu'une fois dans le quorum.
Étape 8 : automatiser avec un flux CI/CD
Pour ne plus dérouler ces promotions à la main, RM ouvre l'onglet
CI/CD du projet et clique sur Nouveau flux (édition protégée par
project:write) :
- un nœud Promotion
dev → prod, l'unité de travail du flux ; - un nœud Approbation relié en amont, une porte manuelle : le flux se bloque jusqu'à validation humaine ;
- l'option Auto sur release : le flux démarre dès qu'une nouvelle release est publiée sur le projet.
Un flux de promotion avec sa porte d'approbation ; les nœuds reliés en
séquence s'exécutent l'un après l'autre.
Au prochain push mergé de Dev, la release entre seule dans le flux : la
promotion vers prod attend la porte d'approbation, puis la revue de
l'environnement s'applique comme à l'étape 7 : chaque promotion du flux
respecte le déploiement par pointeur, la contrainte de chaîne et la revue.
Récapitulatif des droits
| Étape | Action | Droit nécessaire |
|---|---|---|
| 1–2 | Gérer l'équipe et les environnements | Propriétaire ou project:write (Admin) |
| 3–4 | Checkout, édition, commit, push, PR | Niveau Éditeur sur le projet |
| 5 | Approuver et merger la PR | Niveau Admin (approuve les revues) ou propriétaire |
| 6–7 | Déployer / promouvoir | deployment:execute |
| 7 | Approuver / rejeter une revue | deployment:approve |
| 8 | Éditer un flux CI/CD | project:write |
Pour aller plus loin
- Studio : copies de travail : checkout, commit, push et pull request en détail.
- Environnements et déploiement : chaîne, revues et configuration par environnement.
- Flux CI/CD : nœuds, séquences, parallélisme et environnements libres.
- Rôles et permissions (RBAC) : rôles société, portées globale et scopée projet.