Environnements et déploiement

Dans le modèle projet-centric, les environnements vivent à l'intérieur du projet. Un environnement (dev, recette, prod…) est un contexte qui porte deux choses :

• une configuration propre (les valeurs des variables et connexions) ;
• un pointeur vers la release déployée : la version des pipelines qui y tourne.

Tout se gère dans l'onglet Environnements d'un projet (/projets/<projet>/environnements).

La chaîne de déploiement

Les environnements sont ordonnés (dev avant prod). Cet ordre définit la chaîne de promotion : une release progresse d'un environnement au suivant.

Chaque environnement affiche sa release déployée, son état (à jour, en attente de revue…) et ses actions.

Ce sont des branches indépendantes : il n'y a pas de synchronisation automatique entre environnements. Faire évoluer dev ne change rien à prod tant qu'on n'a pas promu la release.

Créer un environnement

Cliquez sur Nouvel environnement et renseignez :

• Nom : dev, recette, prod…
• Type : Développement, Production ou Personnalisé (pilote l'affichage) ;
• Ordre : position dans la chaîne (le plus petit d'abord) ;
• Environnement de production : marque la cible finale ;
• Exiger une revue : tout déploiement vers cet environnement devra être approuvé (voir plus bas) ;
• Cible d'exécution : le runner (ou cluster) qui exécutera les jobs.

Configuration par environnement

Les variables et connexions sont définies au niveau du projet (leur identité : la clé API_URL, la connexion pg-main et ses paramètres). Leurs valeurs, elles, sont propres à chaque environnement.

Pour chaque clé : la valeur de l'environnement courant et, à côté, la valeur par défaut du projet. Une valeur vide utilise le défaut du projet.

Même principe pour les connexions : chaque environnement porte ses propres identifiants, et les paramètres secrets sont masqués :

La connexion pg-main existe partout ; son mot de passe diffère entre dev et prod. Les secrets restent chiffrés.

C'est le point clé du modèle : créer une variable ou une connexion dans le projet la fait apparaître dans chaque environnement, où l'on renseigne sa valeur.

Déployer : un pointeur, pas une copie

Déployer, c'est promouvoir une release vers un environnement. Sur une carte d'environnement, cliquez sur Déployer (ou Redéployer), choisissez la release, puis validez.

Le déploiement pose un pointeur (deployed_release_uuid) : il n'y a aucune copie de contenu. L'environnement sert la release pointée, avec ses propres valeurs de variables et de connexions. Le runner de l'environnement récupère le delta et applique.

La promotion est chain-aware : on ne peut promouvoir vers un environnement que si la release est déjà déployée dans l'environnement précédent. Le premier environnement de la chaîne est le point d'entrée ; sauter une étape est refusé.

Revue et approbations

Si l'environnement cible a Exiger une revue activé, la promotion ne s'applique pas tout de suite : elle passe en attente de revue (awaiting_review) et le pointeur n'est pas encore posé. La carte affiche un bandeau En attente de revue avec Approuver / Rejeter.

• Approuver : une fois le quorum atteint (une approbation par défaut), la release est déployée et la promotion passe complétée ;
• Rejeter : la promotion est close sans déploiement.

Une même personne ne compte qu'une fois dans le quorum. Pour automatiser ces promotions le long de la chaîne, voir Flux CI/CD.

Exploiter un environnement

Le shell d'un environnement (sous-onglets Aperçu, Pipelines, Exécutions, Workflows, Connexions, Variables, Runner & réglages) offre la vue opérationnelle.

Les pipelines de la release déployée, avec leur version figée. « Lancer maintenant » les exécute sur le runner de l'environnement.

Les pipelines y sont en lecture seule (la version figée de la release) ; l'édition se fait dans le Studio. Lancer maintenant exécute un pipeline directement sur le runner de l'environnement.

Qui peut faire quoi

Les actions sont protégées par le RBAC au niveau du projet :

• Gérer les environnements : project:write ;
• Déployer / promouvoir : deployment:execute ;
• Approuver / rejeter une revue : deployment:approve ;
• Lire l'état et la configuration : les permissions *:read correspondantes.

Le propriétaire du projet et les administrateurs de société disposent de tous les droits.