リリースサイクルが停滞する理由

当社では、毎月アップデートを行う10個のアプリを運用しています。「リリース開発者」または「リリースエンジニア」の役割は、リリースごとにチーム内でローテーションされます。

最小権限の原則（PoLP）を遵守するため、リリース開発者には必要な場合にのみデプロイ権限を付与します。そのため、リリース前に適切な担当者に本番環境へのデプロイ権限を付与し、リリース後に権限を取り消す必要があります。

プロジェクトの役割の割り当て Mendix

In Mendix 開発者にプロジェクトへのアクセス権を与えるには、 特定の役割2025年XNUMX月現在、いくつかの更新が行われました。

• 役割を定義できるのは会社の管理者だけです。
• ロールにパブリック クラウド環境の権限を含めることができるようになりました。
• 使用することもできます プロジェクトAPI 特定の役割を持つチームメンバーをプロジェクトに割り当てます。

このリリース サイクルの例では、通常の開発者用と、本番環境にデプロイする権限を持つリリース開発者用の 2 つのロールを設定する必要があります。

通常の開発者ロールの作成

まずは通常の開発者ロールを作成しましょう。 コントロールセンター をクリックしてください のワークプ メニューのセクションを開いて 役割と権限 のセクションから無料でダウンロードできます。

1 – プロジェクトロールの詳細セクションを編集する

すでに定期的に Developer ロールを選択するには、まずそのロールを編集することから始めます。最初のステップでは、このロールにどのような権限を与えるかを指定します（下のスクリーンショットを参照）。

2 – プロジェクト権限の編集

説明が終わったらクリックします 次へ この開発者ロールのプロジェクト権限を設定するには、以下の点を考慮する必要があります。

• プロジェクト管理者権限: この権限は、（システム）スクラムマスターロールにのみ割り当てることをお勧めします。この権限により、ユーザーはチームメンバーの権限管理やプロジェクト設定の変更といった強力なアクションを実行できますが、厳密に管理する必要があります。
• チーム サーバーの権限: この権限により、開発者はチームサーバーにアクセスして作業をコミットできるようになります。これは、あらゆる開発者ロールにとって必須の権限です。
• 計画とフィードバック: 開発者は、自分に割り当てられたユーザー ストーリーを表示して作業するためにこの権限が必要になります。
• メンバーを招待: この権限は（システム）スクラムマスターロールに限定することをお勧めします。この権限により、ユーザーはプロジェクトに新しいメンバーを招待し、役割を割り当てることができるため、最小限に抑えることをお勧めします。

3 – 非本番環境の権限を設定する

アクセス権

まず、このロールに非本番環境へのアクセス権を与えるかどうかを選択します。

• 開発者ロールの場合、ある程度のアクセスレベルが必要です。
• 他の役割の場合は、これを次のように設定できます。 アクセスなしつまり、ユーザーは非本番環境では権限を一切受け取りません。そのため、そのロールについてはこのセクションの残りの部分をスキップできます。

権限管理: 固定 vs カスタム

この設定は、非本番環境の権限の適用および管理方法を制御します。

一定

ロールが固定権限を使用する場合、ロール定義にリストされている権限が自動的に適用されます。このロールを割り当てられたユーザーには、ここで定義された権限が正確に付与され、プロジェクト内で クラウド権限の管理 この役割を持つメンバーの権限を手動で変更することはできません。

つまり、会社の管理者は、プロジェクト内でこの役割を持つメンバーが、ここにリストされている権限とまったく同じ権限を持っていることを確認できるということです。

カスタム額装

カスタム権限では、役割自体がアクセスを決定するわけではありません。権限は手動で割り当てる必要があります。 Mendix 開発者ポータルは、適切な権限を持つユーザーによって、または API 経由で設定されます。

重要：ユーザーが既に権限を持っている場合（例：スクラムマスター）、カスタム権限を持つロールを割り当てても、それらの権限は自動的に取り消されません。既存の権限は、手動またはAPI経由で変更されるまで保持されます。

可能な限り固定権限を使用することをお勧めします。これにより、完全な集中管理が可能になり、予期しない権限のギャップを回避できます。カスタム権限は、デプロイメントに以下の権限を許可するなど、異なる非本番環境間で区別する必要がある場合にのみ使用してください。 開発 の三脚と ホイール試乗ではない 受け入れ.

開発者ロールの場合、開発者に、権限自体を管理する権限とは別に、非本番環境に対する完全な権限を付与します。

4 – 本番環境の権限を設定する

プロジェクトロール編集の最後のステップでは、本番環境の権限を設定します。本番環境への変更には2要素認証が必要となるため、作業を進める前に会社の管理者がアカウントを認証する必要があります。

認証が完了したら、適切な権限を設定できます。開発者は本番環境でアプリの状況を監視できる必要があるため、監視権限を付与することをお勧めします。

これで、通常の開発者ロールが設定されました。プロジェクトでこのロールを割り当てられた開発者は、すぐに非本番環境へのデプロイや本番環境の監視情報の確認ができるようになります。これまでは、スクラムマスターや技術担当者による手動設定が必要でした。生産性が大幅に向上します！

リリース開発者ロールの作成

次に、本番環境へのデプロイに特化して使用されるリリース開発者ロールを定義します。

このロールは必要な場合にのみ使用し（また、デプロイ後に確実に取り消されるように）、極めて限定的に利用していただきます。つまり、このロールを持つチームメンバーは、通常の業務を継続するために、通常の開発者ロールを再度取得する必要があります。

つまり..

• プロジェクト権限がありません
• 非本番環境へのアクセスは不可

…そして、次の本番環境の権限のみ:

• デプロイメント – 本番環境へのリリース
• バックアップ – 展開前にバックアップを作成する
• モニタリング – すべてがスムーズに進んだことを確認する

これらの役割を適用する方法

開発者にプロジェクト内の役割を割り当てる方法はいくつかあります。

• スクラム マスターは、役割を持つ開発者を追加/招待できます。
• 会社の管理者は、役割を持つ開発者を追加/招待できます。
• プロジェクトの API は、ロールを持つ開発者をプロジェクトに追加するために使用されます。

Gaby Gableのような一人の開発者が複数のアプリをリリースする必要がある場合、会社の管理者は次の手順に従って割り当てることができます。 リリース開発者 必要なプロジェクト全体にわたる役割： コントロールセンター、Gabyを検索 メンバーのリスト:

彼女の名前をクリックすると、彼女が関与しているすべてのアプリのリストが表示されます。

アプリ名をクリックすると、 アプリの詳細 パネルに移動します 加盟国 ページで見やすくするために変数を解析したりすることができます。

クリックした後 メンバーを管理する、ギャビーの役割を次のように変更します リリース開発者。

リリースが必要なアプリごとに、これらの手順を繰り返します。ロールが更新されると、Gaby は割り当てられたすべてのアプリにデプロイするための適切な権限を持つようになります。

リリースが完了したら、会社の管理者は同じプロセスを使用して Gaby を元の役割に戻すことができ、不要な本番環境の権限なしで通常の開発者アクセスに戻ることができます。

特定の環境への一時的な権限の付与

チームメンバーに、本番環境または非本番環境のすべてではなく、1つの環境のみへの一時的なアクセス権を付与する必要がある場合もあります。固定権限を持つロールでは、そのような細分性はサポートされておらず、本番環境または非本番環境のカテゴリを問わず、すべての環境に権限が適用されます。

では、複数の本番環境がある場合、例えば 生産 の三脚と プロダクション2、一時的なアクセスを許可したい場合 生産?

このユースケースでは、 開発者カスタム ロール。通常の開発者と同じ権限ですが、本番環境（非本番環境）の権限はプロジェクトロールには含まれません。ただし、手動またはAPIで設定できます。

対処方法は次のとおりです。

非本番環境と本番環境の両方の権限を設定する カスタム額装.

例えば、Gaby が現在、固定権限を持つロールを所有しているとします。これは、Gaby の環境へのアクセスがロックされており、スクラムマスターや技術担当者が変更できないことを意味します。

これを見ることができます Mendix ポータル アプリの 権限 タブ 生産 環境 – 彼女の権限は読み取り専用として表示されます。

Gabyの権限を編集可能にするには、別のプロジェクトロールを割り当てます。この場合は、 開発者カスタム.

この新しいロールには、通常の開発者と同じプロジェクトレベルの権限が付与されます。ただし、環境権限はカスタムであるため、環境アクセスを管理する権限を持つチームメンバー（技術担当者など）が手動で更新するか、Deploy APIを使用して更新できます。

これにより、他のすべての環境の制御を損なうことなく、単一の環境への一時的なアクセスを許可する柔軟性が得られます。

柔軟性と制御のバランス

カスタムロールを使用すると、セキュリティモデルを損なうことなく、特定の環境への一時的なアクセスを許可するといった例外を柔軟に処理できます。一方、固定ロールは、すべてのプロジェクトと環境にわたって一貫性のある一元的な権限を適用したい場合に最適です。

両方のアプローチを慎重に組み合わせることで、セキュリティの重要なベストプラクティスである最小権限の原則（PoLP）を遵守できます。これは、チームメンバー全員が業務に必要なアクセス権のみを付与することを意味します。過不足はありません。固定ロールをデフォルトとして使用し、カスタムロールはエッジケース用に確保することで、リスクを最小限に抑えながら、リリースプロセスをスムーズかつ効率的に維持できます。