Warum der Release-Zyklus immer wieder ins Stocken gerät

In unserem Unternehmen sind zehn Apps in Produktion, die wir monatlich aktualisieren. Die Rolle des „Release-Entwicklers“ bzw. „Release-Ingenieurs“ wechselt bei jedem Release innerhalb unseres Teams.

Um dem Prinzip der geringsten Privilegien (PoLP) gerecht zu werden, möchten wir dem Release-Entwickler nur dann Bereitstellungsberechtigungen erteilen, wenn er sie benötigt. Daher müssen wir vor jedem Release der richtigen Person Zugriff für die Bereitstellung in der Produktion gewähren und diesen nach dem Release wieder entziehen können.

Zuweisen von Projektrollen in Mendix

In Mendix Sie können Entwicklern Zugriff auf Ihr Projekt gewähren, indem Sie ihnen eine spezifische RolleAb Januar 2025 haben wir einige Aktualisierungen vorgenommen:

• Nur Unternehmensadministratoren können Rollen definieren.
• Rollen können jetzt Berechtigungen für öffentliche Cloud-Umgebungen umfassen.
• Sie können auch die Tasten Projekt-API um einem Projekt ein Teammitglied mit einer bestimmten Rolle zuzuweisen.

Für dieses Beispiel eines Release-Zyklus müssen wir zwei Rollen einrichten: eine für einen normalen Entwickler und eine weitere für einen Release-Entwickler, der die Berechtigung zur Bereitstellung in der Produktion hat.

Erstellen einer regulären Entwicklerrolle

Beginnen wir mit der Erstellung einer normalen Entwicklerrolle. Im Control Center Klicken Sie auf die Personen Abschnitt des Menüs und öffnen Sie die Funktionen & Berechtigungen .

1 – Bearbeiten Sie den Abschnitt „Projektrollendetails“

Da es bereits eine regelmäßige Entwickler:in / Unternehmen Wir beginnen mit der Bearbeitung der Rolle. Im ersten Schritt beschreiben wir, welche Berechtigungen diese Rolle hat (siehe Beispiel im Screenshot unten).

2 – Projektberechtigungen bearbeiten

Wenn Sie mit Ihrer Beschreibung fertig sind, klicken Sie auf Nächster um die Projektberechtigungen für diese Entwicklerrolle festzulegen. Hier sind einige Überlegungen:

• Projektadministratorberechtigung: Wir empfehlen, diese Berechtigung nur der (System-)Scrum-Master-Rolle zuzuweisen. Sie ermöglicht dem Benutzer, die Berechtigungen von Teammitgliedern zu verwalten und Projekteinstellungen zu ändern – wichtige Aktionen, die streng kontrolliert werden sollten.
• Teamserverberechtigung: Diese Berechtigung ermöglicht den Zugriff auf den Teamserver, damit Entwickler ihre Arbeit committen können. Sie ist für jede Entwicklerrolle unerlässlich.
• Planung und Feedback: Entwickler benötigen diese Berechtigung, um die ihnen zugewiesenen User Stories anzuzeigen und daran zu arbeiten.
• Mitglieder einladen: Wir empfehlen, diese Berechtigung auf die (System-)Scrum-Master-Rolle zu beschränken. Sie ermöglicht es Benutzern, neue Mitglieder zum Projekt einzuladen und ihnen Rollen zuzuweisen. Daher sollte sie auf ein Minimum beschränkt werden.

3 – Legen Sie die Berechtigungen für die Nicht-Produktionsumgebung fest

Zugangsrechte

Wählen Sie zunächst aus, ob diese Rolle Zugriff auf Nicht-Produktionsumgebungen haben soll.

• Für Entwicklerrollen ist ein bestimmtes Zugriffsniveau erforderlich.
• Für andere Rollen können Sie dies auf Kein Zugriff, was bedeutet, dass der Benutzer keine Berechtigungen für Nicht-Produktionsumgebungen erhält – und Sie können den Rest dieses Abschnitts für diese Rolle überspringen.

Berechtigungsverwaltung: Fest oder benutzerdefiniert

Diese Einstellung steuert, wie Berechtigungen für Nicht-Produktionsumgebungen angewendet und verwaltet werden.

Behoben

Wenn eine Rolle feste Berechtigungen verwendet, werden die in der Rollendefinition aufgeführten Berechtigungen automatisch erzwungen. Benutzer, denen diese Rolle zugewiesen ist, erhalten genau die hier definierten Berechtigungen. Personen im Projekt mit Cloud-Berechtigungen verwalten kann die Berechtigungen von Mitgliedern mit dieser Rolle nicht manuell ändern.

Kurz gesagt bedeutet dies, dass ein Unternehmensadministrator sicher sein kann, dass ein Mitglied mit dieser Rolle in einem Projekt genau die hier aufgeführten Berechtigungen hat.

Maßgeschneidert

Bei benutzerdefinierten Berechtigungen bestimmt die Rolle selbst nicht den Zugriff. Berechtigungen müssen manuell im Mendix Entwicklerportal durch jemanden mit den entsprechenden Rechten oder über die API festgelegt.

Wichtig: Wenn ein Benutzer bereits über Berechtigungen verfügt (z. B. als Scrum Master), führt die Zuweisung einer Rolle mit benutzerdefinierten Berechtigungen nicht automatisch zu deren Widerruf. Die bestehenden Berechtigungen bleiben bestehen, bis sie manuell oder über eine API geändert werden.

Wir empfehlen, nach Möglichkeit feste Berechtigungen zu verwenden, da Sie dadurch die vollständige zentrale Kontrolle haben und unerwartete Berechtigungslücken vermeiden. Verwenden Sie benutzerdefinierte Berechtigungen nur, wenn Sie zwischen verschiedenen Nicht-Produktionsumgebungen unterscheiden müssen, z. B. Bereitstellungen für Entwicklung und Test, Aber nicht Annahme.

Im Falle unserer Entwicklerrolle erteilen wir dem Entwickler neben der Möglichkeit, die Berechtigungen selbst zu verwalten, auch alle Berechtigungen für Nicht-Produktionsumgebungen.

4 – Legen Sie die Berechtigungen für die Produktionsumgebung fest

Im letzten Schritt der Bearbeitung der Projektrolle konfigurieren wir die Berechtigungen für die Produktionsumgebung. Da für alle Änderungen in der Produktion eine Zwei-Faktor-Authentifizierung erforderlich ist, muss der Unternehmensadministrator das Konto vor dem Fortfahren authentifizieren.

Nach der Authentifizierung können wir die entsprechenden Berechtigungen festlegen. Entwickler sollten in der Lage sein, den Betrieb ihrer App in der Produktion zu überwachen. Daher empfiehlt es sich, Überwachungszugriff zu gewähren.

Damit ist die reguläre Entwicklerrolle eingerichtet. Sobald einem Entwickler diese Rolle in einem Projekt zugewiesen wird, kann er sofort in Nicht-Produktionsumgebungen bereitstellen und Überwachungsinformationen in der Produktion einsehen – etwas, das früher manuell durch einen Scrum Master oder einen technischen Ansprechpartner konfiguriert werden musste. Ein großer Produktivitätsgewinn!

Erstellen der Release-Entwicklerrolle

Als Nächstes definieren wir die Rolle des Release-Entwicklers, die speziell für die Bereitstellung in der Produktion verwendet wird.

Um die Nutzung dieser Rolle nur bei Bedarf zu fördern (und sicherzustellen, dass sie nach der Bereitstellung widerrufen wird), halten wir sie äußerst eingeschränkt. Das bedeutet, dass das Teammitglied mit dieser Rolle seine reguläre Entwicklerrolle zurückerhalten muss, um seine normale Arbeit fortsetzen zu können.

Das bedeutet...

• Keine Projektberechtigungen
• Kein Zugriff auf Nicht-Produktionsumgebungen

…und nur die folgenden Berechtigungen für die Produktionsumgebung:

• Bereitstellung – zur Freigabe für die Produktion
• Backups – um vor der Bereitstellung ein Backup zu erstellen
• Überwachung – um sicherzustellen, dass alles reibungslos verlief

So wenden Sie diese Rollen an

Es gibt mehrere Möglichkeiten, einem Entwickler eine Rolle in einem Projekt zuzuweisen:

• Ein Scrum Master kann einen Entwickler mit einer Rolle hinzufügen/einladen.
• Ein Unternehmensadministrator kann einen Entwickler mit einer Rolle hinzufügen/einladen.
• Die API des Projekts wird verwendet, um einem Projekt einen Entwickler mit einer Rolle hinzuzufügen.

Wenn ein einzelner Entwickler – wie Gaby Gable – mehrere Apps veröffentlichen muss, kann ein Unternehmensadministrator diese Schritte befolgen, um die Release-Entwickler Rolle in den notwendigen Projekten: In der Control Center, suchen Sie nach Gaby im Benutzerliste:

Klicken Sie auf ihren Namen, um eine Liste aller Apps anzuzeigen, an denen sie beteiligt ist.

Klicken Sie auf einen App-Namen, um die App-Details Gehen Sie zum Mitglieder

Nach einem Klick Mitglieder verwalten, ändern Sie Gabys Rolle in Release-Entwickler.

Wiederholen Sie diese Schritte für jede App, die freigegeben werden soll. Sobald ihre Rollen aktualisiert sind, verfügt Gaby über die erforderlichen Berechtigungen für die Bereitstellung in allen zugewiesenen Apps.

Nach Abschluss der Veröffentlichungen kann der Unternehmensadministrator denselben Prozess verwenden, um Gaby wieder in ihre ursprünglichen Rollen zurückzusetzen. So wird sichergestellt, dass sie wieder den regulären Entwicklerzugriff erhält, ohne unnötige Produktionsberechtigungen.

Erteilen temporärer Berechtigungen für eine bestimmte Umgebung

Manchmal müssen Sie einem Teammitglied vorübergehend Zugriff auf nur eine Umgebung gewähren, nicht jedoch auf alle Produktions- und Nicht-Produktionsumgebungen. Rollen mit festen Berechtigungen unterstützen diese Detailgenauigkeit nicht. Sie wenden Berechtigungen auf alle Umgebungen an, egal ob Produktions- oder Nicht-Produktionsumgebung.

Was passiert, wenn Sie mehrere Produktionsumgebungen haben, wie zum Beispiel Produktion und Produktion2und Sie möchten vorübergehenden Zugriff nur auf Produktion?

Für diesen Anwendungsfall können Sie eine Entwicklerbenutzerdefiniert Rolle. Dieselben Berechtigungen wie ein normaler Entwickler, aber die Berechtigungen für (Nicht-)Produktion sind nicht in der Projektrolle enthalten, können jedoch manuell oder per API festgelegt werden.

So gehen Sie damit um:

Legen Sie sowohl Nicht-Produktions- als auch Produktionsberechtigungen fest auf Maßgeschneidert.

Nehmen wir an, Gaby hat derzeit eine Rolle mit festen Berechtigungen. Das bedeutet, ihr Umgebungszugriff ist gesperrt und kann weder vom Scrum Master noch vom technischen Ansprechpartner geändert werden.

Sie können dies in Mendix Portal der App, in der Berechtigungen Registerkarte der Produktion Umgebung – ihre Berechtigungen werden als schreibgeschützt angezeigt.

Um Gabys Berechtigungen bearbeitbar zu machen, weisen Sie ihr eine andere Projektrolle zu, in diesem Fall Entwicklerbenutzerdefiniert.

Diese neue Rolle verfügt über dieselben Berechtigungen auf Projektebene wie ein normaler Entwickler. Da die Umgebungsberechtigungen jedoch benutzerdefiniert sind, können sie nun manuell von einem Teammitglied mit der Berechtigung zur Verwaltung des Umgebungszugriffs (z. B. einem technischen Ansprechpartner) oder über die Deploy-API aktualisiert werden.

Dies gibt Ihnen die Flexibilität, vorübergehenden Zugriff auf eine einzelne Umgebung zu gewähren, ohne die Kontrolle über alle anderen zu beeinträchtigen.

Flexibilität und Kontrolle in Einklang bringen

Benutzerdefinierte Rollen bieten Ihnen die Flexibilität, Ausnahmen zu handhaben – beispielsweise den temporären Zugriff auf eine einzelne Umgebung – ohne Ihr Sicherheitsmodell zu beeinträchtigen. Feste Rollen hingegen sind ideal, wenn Sie konsistente, zentralisierte Berechtigungen für alle Projekte und Umgebungen erzwingen möchten.

Durch die sinnvolle Kombination beider Ansätze unterstützen Sie eine wichtige Sicherheits-Best-Practice: das Prinzip der geringsten Privilegien (PoLP). Das bedeutet, dass jedes Teammitglied nur den Zugriff erhält, den es für seine Arbeit benötigt – nicht mehr und nicht weniger. Die Verwendung fester Rollen als Standard und die Reservierung benutzerdefinierter Rollen für Sonderfälle trägt dazu bei, das Risiko zu minimieren und gleichzeitig Ihren Release-Prozess reibungslos und effizient zu gestalten.