Pourquoi le cycle de publication reste bloqué

Dans notre entreprise, nous avons dix applications en production que nous mettons à jour chaque mois. Le rôle de « développeur de versions » ou « ingénieur de versions » est alterné au sein de notre équipe à chaque version.

Pour respecter le principe du moindre privilège (PoLP), nous souhaitons accorder des autorisations de déploiement au développeur de la version uniquement lorsqu'il en a besoin. Ainsi, avant chaque version, nous devons pouvoir accorder à la personne concernée l'accès au déploiement en production et révoquer son accès après la version.

Attribution des rôles de projet dans Mendix

In Mendix vous pouvez donner aux développeurs l'accès à votre projet en leur attribuant un rôle spécifique. Depuis janvier 2025, nous avons effectué quelques mises à jour :

• Seuls les administrateurs de l'entreprise peuvent définir des rôles.
• Les rôles peuvent désormais inclure des autorisations d’environnement de cloud public.
• Vous pouvez également utiliser la Projet API pour affecter un membre de l'équipe à un projet avec un rôle spécifique.

Pour cet exemple de cycle de publication, nous devrons configurer deux rôles : un pour un développeur régulier et un autre pour un développeur de publication qui aura l'autorisation de déployer en production.

Créer un rôle de développeur régulier

Commençons par créer un rôle de développeur classique. Dans le Control Center cliquez sur le Personnes section du menu et ouvrez le Rôles et autorisations .

1 – Modifier la section Détails du rôle du projet

Puisqu'il existe déjà un système régulier Développeur Pour choisir un rôle, nous allons commencer par le modifier. La première étape consiste à décrire les autorisations dont il disposera (voir la capture d'écran ci-dessous pour un exemple).

2 – Modifier les autorisations du projet

Lorsque vous avez terminé votre description, cliquez sur Suivant Pour définir les autorisations du projet pour ce rôle de développeur. Voici quelques pistes de réflexion :

• Autorisation d'administrateur de projet : Nous recommandons d'attribuer cette autorisation uniquement au rôle Scrum Master (système). Elle permet à l'utilisateur de gérer les autorisations des membres de l'équipe et de modifier les paramètres du projet : des actions importantes qui doivent être étroitement contrôlées.
• Autorisation du serveur d'équipe : Cette autorisation donne accès au serveur d'équipe afin que les développeurs puissent valider leur travail. Elle est essentielle pour tout rôle de développeur.
• Planification et rétroaction : Les développeurs auront besoin de cette autorisation pour afficher et travailler sur les user stories qui leur sont attribuées.
• Inviter des membres: Nous suggérons de limiter cette autorisation au rôle Scrum Master (système). Elle permet aux utilisateurs d'inviter de nouveaux membres au projet et de leur attribuer des rôles ; il est donc préférable de la limiter au minimum.

3 – Définir les autorisations de l’environnement de non-production

Des droits d'accès

Commencez par choisir si ce rôle doit avoir accès aux environnements hors production.

• Pour les rôles de développeur, un certain niveau d'accès est requis.
• Pour les autres rôles, vous pouvez définir ceci sur Pas d'accès, ce qui signifie que l'utilisateur ne recevra aucune autorisation sur les environnements hors production, et vous pouvez ignorer le reste de cette section pour ce rôle.

Gestion des autorisations : fixes ou personnalisées

Ce paramètre contrôle la manière dont les autorisations d’environnement hors production sont appliquées et gérées.

Parfaitement fixé

Lorsqu'un rôle utilise des autorisations fixes, les autorisations listées dans la définition du rôle sont appliquées automatiquement. Les utilisateurs affectés à ce rôle recevront les autorisations définies ici, et les personnes du projet disposant de ces autorisations recevront les autorisations définies ici. Gérer les autorisations du cloud ne pourra pas modifier manuellement les autorisations des membres qui ont ce rôle.

En bref, cela signifie qu’un administrateur d’entreprise peut être sûr qu’un membre avec ce rôle dans un projet dispose exactement des autorisations répertoriées ici.

Encadrement Sur Mesure

Avec les autorisations personnalisées, le rôle lui-même ne détermine pas l'accès. Les autorisations doivent être attribuées manuellement dans le Mendix Portail des développeurs par une personne disposant des droits appropriés ou défini via l'API.

Important : Si un utilisateur dispose déjà d'autorisations (par exemple, en tant que Scrum Master), l'attribution d'un rôle avec des autorisations personnalisées ne le révoquera pas automatiquement. Ces autorisations existantes seront conservées jusqu'à leur modification manuelle ou via une API.

Nous vous recommandons d'utiliser les autorisations fixes autant que possible, car elles vous offrent un contrôle centralisé total et évitent les interruptions d'autorisations inattendues. N'utilisez les autorisations personnalisées que si vous devez distinguer différents environnements hors production, par exemple pour autoriser les déploiements. Développement et Test, Mais pas Acceptation.

Dans le cas de notre rôle de développeur, nous accorderons au développeur des autorisations complètes sur les environnements hors production, en plus de la possibilité de gérer les autorisations lui-même.

4 – Définir les autorisations des environnements de production

Lors de cette dernière étape de modification du rôle du projet, nous allons configurer les autorisations de l'environnement de production. Toute modification de l'environnement de production nécessitant une authentification à deux facteurs, l'administrateur de l'entreprise devra authentifier le compte avant de poursuivre.

Une fois authentifiés, nous pouvons définir les autorisations appropriées. Les développeurs doivent pouvoir surveiller l'activité de leur application en production ; il est donc judicieux d'accorder un accès de surveillance.

Le rôle de développeur standard est désormais configuré. Désormais, lorsqu'un développeur se voit attribuer ce rôle dans un projet, il peut immédiatement déployer des applications hors production et consulter les informations de surveillance en production, ce qui nécessitait auparavant une configuration manuelle par un Scrum Master ou un contact technique. Un gain de productivité considérable !

Création du rôle de développeur de versions

Ensuite, nous définirons le rôle de développeur de version, utilisé spécifiquement pour le déploiement en production.

Afin d'encourager l'utilisation de ce rôle uniquement en cas de besoin (et de garantir sa révocation après le déploiement), nous le limiterons au maximum. Cela signifie que le membre de l'équipe qui le possède devra retrouver son rôle de développeur habituel pour poursuivre son travail normal.

Cela signifie...

• Aucune autorisation de projet
• Aucun accès aux environnements hors production

…et uniquement les autorisations d’environnement de production suivantes :

• Déploiement – ​​pour mettre en production
• Sauvegardes – pour créer une sauvegarde avant le déploiement
• Suivi – pour confirmer que tout s'est bien passé

Comment appliquer ces rôles

Il existe plusieurs façons d'attribuer un rôle à un développeur dans un projet :

• Un Scrum Master peut ajouter/inviter un développeur avec un rôle.
• Un administrateur d’entreprise peut ajouter/inviter un développeur avec un rôle.
• L'API du projet est utilisée pour ajouter un développeur à un projet avec un rôle.

Si un seul développeur, comme Gaby Gable, doit publier plusieurs applications, un administrateur d'entreprise peut suivre ces étapes pour attribuer la Développeur de versions rôle dans les projets nécessaires : Dans le Control Center, recherchez Gaby dans le Liste des membres:

Cliquez sur son nom pour voir une liste de toutes les applications dans lesquelles elle est impliquée.

Cliquez sur le nom d'une application pour l'ouvrir App Détails panneau. Accédez au Membres .

Après avoir cliqué Gérer les membres, changez le rôle de Gaby en Développeur de versions.

Répétez ces étapes pour chaque application à publier. Une fois ses rôles mis à jour, Gaby disposera des autorisations nécessaires pour déployer toutes les applications attribuées.

Une fois les versions terminées, l'administrateur de l'entreprise peut utiliser le même processus pour rétablir Gaby dans ses rôles d'origine, garantissant ainsi qu'elle retrouve un accès développeur normal sans autorisations de production inutiles.

Accorder des autorisations temporaires sur un environnement spécifique

Il peut parfois être nécessaire d'accorder à un membre de l'équipe un accès temporaire à un seul environnement, mais pas à tous les environnements de production ou hors production. Les rôles avec des autorisations fixes ne permettent pas ce niveau de granularité ; ils appliquent les autorisations à tous les environnements, qu'ils soient de production ou hors production.

Alors, que se passe-t-il si vous avez plusieurs environnements de production, tels que Production et Production2, et vous souhaitez accorder un accès temporaire à seulement Production?

Pour ce cas d'utilisation, vous pouvez définir un Développeur personnalisé rôle. Mêmes autorisations qu'un développeur standard, mais les autorisations pour la (non)production ne sont pas incluses dans le rôle du projet, bien qu'elles puissent être définies manuellement ou par API.

Voici comment gérer cela :

Définissez les autorisations de production et de non-production sur Encadrement Sur Mesure.

Supposons que Gaby ait actuellement un rôle avec des autorisations fixes. Cela signifie que son accès à l'environnement est verrouillé et ne peut être modifié ni par le Scrum Master ni par le contact technique.

Vous pouvez voir ceci dans Mendix Portail de l'application, dans le Permissions onglet du Production environnement – ​​ses autorisations apparaîtront en lecture seule.

Pour rendre les autorisations de Gaby modifiables, attribuez-lui un rôle de projet différent, dans ce cas, Développeur personnalisé.

Ce nouveau rôle dispose des mêmes autorisations au niveau du projet qu'un développeur standard. Cependant, comme ses autorisations d'environnement sont personnalisées, elles peuvent désormais être mises à jour manuellement par un membre de l'équipe autorisé à gérer l'accès à l'environnement (comme un contact technique) ou via l'API Deploy.

Cela vous donne la flexibilité d'accorder un accès temporaire à un seul environnement, sans compromettre le contrôle sur tous les autres.

Équilibrer la flexibilité et le contrôle

Les rôles personnalisés vous offrent la flexibilité nécessaire pour gérer les exceptions, comme l'octroi d'un accès temporaire à un environnement spécifique, sans compromettre votre modèle de sécurité. Les rôles fixes, quant à eux, sont idéaux pour appliquer des autorisations cohérentes et centralisées à tous les projets et environnements.

En combinant judicieusement ces deux approches, vous soutenez une bonne pratique de sécurité essentielle : le principe du moindre privilège (PoLP). Ainsi, chaque membre de l'équipe dispose uniquement des accès nécessaires à son travail, ni plus, ni moins. L'utilisation de rôles fixes par défaut et la réservation de rôles personnalisés pour les cas extrêmes permettent de minimiser les risques tout en garantissant la fluidité et l'efficacité de votre processus de déploiement.