あなたの質問は、それが対象としているプラットフォーム/ OSについて何の仮定もしていないようです。これが、メインフレーム環境でこれが通常どのように行われ、対処されるかについての答えを追加することが理にかなっている理由です。関与した。私の答えは、私が最も精通しているSCM製品の使用に基づいています（製品名を開示する必要があるかどうかはわかりません）。
1.アーキテクチャ
以下は、私があなたの質問に答える方法のハイライトです。
- すべてのコード（および実行可能ファイルなどの関連するアーティファクト）はファイルに格納されます。これらはすべてライブラリ構造と呼ばれます。
- 各（おそらくリモートの）ターゲットシステム上の各環境には、ライブラリ構造内のすべての更新（すべて：繰り返し）を処理するサーバー（メインフレームの「開始タスク」）があります。いくつかの例外（セキュリティ担当者やスペース管理チームなど）がありますが、それ以外は誰も（繰り返し：誰も）そのライブラリ構造内のファイルに更新を適用する権限を持ちません。つまり、サーバーはライブラリ構造全体に対する排他的な更新権限を取得します。注意：OPSの人々は、アクセスを制限するために立ち入ると（最初は抵抗しようとします...）
- 実際のソフトウェアの変更は、単一のコンポーネント（深夜の小さなコード修正...）で構成されている場合もあれば、数百または数千のソース、実行可能ファイル、またはその他のアーティファクト（週末のリリース中）である場合もあります。それらを管理しやすくするために、（多かれ少なかれ）一緒に移動する必要があるものを、同時にソフトウェア変更パッケージと呼ばれるものにまとめます。
上記により、サーバーによってライブラリ構造に適用されるすべての種類の更新は、ソフトウェア変更パッケージ（必要に応じてSDLC）のライフサイクルと呼ばれる明確に定義されたワークフローを介してのみ可能になります。そのワークフローのさまざまなステップを実際に実行するには、これを実現するために必要なものです。
- サーバーのみが必要な（および事前構成された）ステップを実行します。
- サーバーは、特定のステップ（=ライブラリ構造内のどこかで何かを更新する）のみを実行します。そのようなステップを実行するために必要な承認（人間から）が収集された後です。
- 承認は、そのような承認を発行することを許可するロール（=許可）を持つユーザーのみが行うことができます。
2.役割と権限
サーバーは、ユーザーの許可が適切な場合に、何かを実行しようとするユーザー（「何かを承認する」など）のみが実行できるようにします。その部分は簡単です。ただし、SCMシステムを使用して、関係するすべてのユーザーのすべてのアクセス許可を管理する必要はありません。これはセキュリティシステム（SCMシステムではありません！）に属しているため、ワークフローを（SCMシステムで）調整できます必要に応じてこれらの権限を確認してください。以下の手順は、その詳細を提供します。
ステップ1：アクセス許可を構成する（セキュリティシステムで）
定義セキュリティエンティティをこれらのエンティティのために明確に定義された名前で、セキュリティシステムに。いくつかのサンプル（ご自身のニーズに合わせて同様のサンプルを追加してください）：
PrmUnit、プロモートにユニットテストを要求する許可を取得するために使用されます。PrmQA、プロモートにQaテストを要求する許可を取得するために使用されます（これが最高レベルのテストであると仮定しましょう）。PrdEnduser、あるレベルのテストに関与するエンドユーザーが使用し、ある種のテストによって生成された結果に満足していることを示します。そして、そのため、それらのエンドユーザーは、ライブラリ構造の変化が進むことに同意します。PrdRelmgnt、実稼働環境でのアクティベーション（=ライブラリ構造の最後/最高レベル）を承認するためにリリースマネージャーによって使用されます。
セキュリティシステムでユーザーのグループを定義します。いくつかのサンプル（ご自身のニーズに合わせて同様のサンプルを追加してください）：
GrpDevs、これは（たとえば）開発者に対応します（おそらく1つ以上）。GrpEnduser、（たとえば）エンドユーザーに対応します（少なくとも1人、できればより類似したユーザー）。GrpRelMgnt、（たとえば）リリースマネージャー（少なくとも1人、できればさらに数人のユーザー）に対応します。
また、セキュリティシステムを使用して、選択した「ユーザーグループ」の選択した「セキュリティエンティティ」へのアクセスを許可する権限を付与します。上記の例を続けるために、適切と思われるものを以下に示します（自分のニーズに合わせて調整します）
- グループ
GrpDevsは、セキュリティエンティティ（のみ）にアクセスできますPrmUnit。
- グループ
GrpEnduserは、セキュリティエンティティ（のみ）にアクセスできますPrdEnduser。
- グループ
GrpRelMgntは（両方！）セキュリティエンティティPrmQAとにアクセスします PrdRelmgnt。
ステップ2：ワークフローを構成する（SCMシステムで）
セキュリティシステムでアクセス許可を構成した後（ステップ1）、SCMシステムで行うべきことは、ライフサイクルのさまざまなステップがセキュリティシステムの関連するセキュリティエンティティとどのように一致するかを構成することだけです。つまり、必要なセキュリティエンティティへの適切なアクセス権を持つユーザーのみが、ワークフローの対応するステップを実行するようにサーバーに要求できます。
以下に、SCMシステムを構成していくつかの魔法を実現する方法の例を示します。
- ユーザーがアクセス権を持っている場合は
PrmUnit、そのようなユーザーが要求するために許可されている推進にユニットが -testingを。明らかに、グループGrpDevs内のユーザーはこれに対して許可されているユーザーです（注：たとえば、グループ内のユーザーではありませんGrpRelMgnt）。
- ユーザーがにアクセスできる場合
PrmQA、そのようなユーザーはQAテストへの昇格をリクエストできます。明らかに、グループ内のユーザーは、これに対して許可されているユーザーです（注：たとえば、group 、group内のユーザーではありません）。GrpRelMgntGrpDevsGrpEnduser
- ユーザーがへのアクセス権を持っている場合
PrdEnduser、そのようなユーザーは、ライブラリ構造内で前進する変更を承認することができます（通常、グループ内のユーザーがGrpRelMgnt変更をレビューするための前提条件です）。明らかに、グループGrpEnduser内のユーザーは、これを許可された（唯一の）ユーザーです。
- ユーザーがへのアクセス権を持っている場合
PrdRelmgnt、そのようなユーザーは実稼働環境でのアクティベーション（=ライブラリ構造の最後/最高レベル）を承認できます。
3.予期しないことを予期し、それに備えてください
上記は単なる青写真であり、最終的には職務分掌を処理するのがサーバーであるかを理解するのに役立ちます。
上記で説明したように全体像を完成させるために、サーバーはシステムで発生しているすべての監査証跡（ログ）を作成します。そのため、いつでも次のような質問に答えることができます。
いつ、なぜ、そしてどの許可ユーザーが実際にそれを承認したのか...前もって？
しかし、おそらく最も難しいのは、適切なレポートツールを利用可能にすることです（そして、それらの使用方法を知っていることです）。少なくとも（簡単に）IT監査員からの要求を満たすため（質問は非常に難しい場合があります）。しかし、SCMシステムの関連するログレコードを参照して、あらゆる種類の「何が起こったのか」（生産の一部）がダウンしている危機的な状況での質問に答えることもできます。
PS：私の答えがDevOpsに準拠しているかどうかは、誰でも判断できます。