Skip to main content

Le modèle projet-centric

Dans Fluhoms, le projet est l'unité centrale. Un projet regroupe des pipelines, des workflows, une configuration (variables et connexions) et ses propres environnements de déploiement. Tout part du projet : plus besoin de choisir un environnement avant de commencer.

Le modèle s'inspire de git :

  • les projets société sont les origines partagées : la référence de l'entreprise, en lecture seule ;
  • pour modifier un projet, on en prend une copie de travail (un checkout) dans le Studio : c'est là qu'on développe ;
  • on commit ses changements, puis on les pousse vers l'origine sous forme de release et de pull request.

La page Projets​

/projets liste les projets société : les origines partagées, visibles par l'entreprise et non éditables directement.

La liste des projets société Chaque carte montre le nom du projet, ses statistiques (pipelines, workflows, exécutions sur 24 h, taux de succès) et les actions disponibles.

Depuis une carte, vous pouvez :

  • Ouvrir le projet (vue en lecture seule) ;
  • Travailler dessus : crée une copie de travail dans le Studio (checkout) ;
  • Importer un projet depuis un fichier .fluhoms, ou Checkout un projet existant depuis la barre d'actions ;
  • Créer un nouveau projet via l'assistant en trois étapes (identité, équipe, revue).

La vue d'un projet​

Ouvrir un projet affiche son shell avec une vue d'ensemble et des onglets.

Vue d'ensemble d'un projet La vue d'ensemble résume les pipelines, la chaîne de déploiement et les dernières versions.

Les onglets d'un projet société :

OngletContenu
Vue d'ensembleRésumé : pipelines, chaîne de déploiement, versions récentes
EnvironnementsLa chaîne dev → recette → prod et l'état déployé (voir Environnements et déploiement)
CI/CDLes flux de promotion automatisés (voir Flux CI/CD)
VersionsL'historique git : commits, working tree, divergence
À validerLes pull requests entrantes issues des copies de travail
AccèsLa gestion de l'équipe et des droits du projet
ParamètresLes réglages du projet

Un bandeau « Projet société · lecture seule » rappelle qu'un projet société ne s'édite pas directement : le bouton Checkout pour éditer ouvre une copie de travail dans le Studio.

Visibilité : organisation ou privé​

Chaque projet a une visibilité :

  • Organisation : accessible à tous les membres de l'entreprise (le RBAC décide ensuite qui peut éditer, déployer, etc.) ;
  • Privé : visible du seul propriétaire et des personnes explicitement invitées.

Accès et droits​

Les droits sont scopés au projet. Le propriétaire (le créateur, par défaut) dispose de tous les droits techniques sans rôle particulier. Les collaborateurs sont ajoutés depuis l'onglet Accès avec un niveau :

  • Admin : édite, déploie et approuve les revues ;
  • Éditeur : développe (pipelines, variables, connexions), déploie et exécute ;
  • Lecteur : accès en lecture seule.

Un rôle attribué sur un projet n'accorde ses permissions que sur ce projet. Les administrateurs de société conservent leurs droits partout.

Rejoindre une branche : un droit à part​

Ouvrir la branche d'un collègue relève d'une permission distincte, branch:join, accordée par défaut aux Éditeurs et aux administrateurs.

Elle est séparée du droit de développer parce que les deux questions le sont : « cette personne peut-elle travailler ici ? » et « peut-elle ouvrir le travail en cours de quelqu'un d'autre ? ». Une équipe peut vouloir répondre oui à la première et non à la seconde — un prestataire cantonné à son périmètre, par exemple.

Ce qui appartient au projet, et pas à votre copie​

Les environnements, les chaînes CI/CD et les pull requests appartiennent au projet lui-même. Vous les voyez depuis votre copie de travail, mais les modifier demande le droit correspondant sur le projet — être propriétaire de votre copie ne suffit pas.

C'est voulu : un environnement n'est pas du code, c'est l'endroit où le code tourne. Il ne se duplique pas avec une branche, et il ne se règle pas depuis l'espace privé d'une personne.

Et ensuite ?​