エンジニアリング システムの目標を十分に理解したら、より高度な開発者セルフサービス エクスペリエンスを作成できます。 開発者のセルフサービス エクスペリエンスは、概念、パターン、コンポーネントの基礎に基づいて構築されています。
現在、組織でここに記述されているすべてが必要なわけではありませんが、カスタム製品を構築したり、関連製品を評価したりする場合は、これらの概念を念頭に置く必要があります。 開発者のセルフサービス エクスペリエンス モデルは、自社製品、既製製品、オープンソース製品の組み合わせで構成できます。 Backstage.io のような製品やオープンソースのポータル ツールキットでは、ここで説明するモデルの一部の要素に異なる用語が使用される場合がありますが、モデルは引き続きユーザーの方向を変えるのに役立ちます。
ワークフローの自動化、データの集計、単純な開始、段階的な拡張
目標は、制御された管理されたタスクの実行とプロビジョニングを通じてガードレールを使用してセルフサービスを有効にし、一元的な可視性を実現することです。 重点を置くために最も重要な領域は、面倒なものか、複雑さまたはアクセス許可のために開発者が自分でできないことです。 この最後の部分は、手動のサービス デスク プロセスを開発者に強制することなく、最小限の特権の原則に従えるようにするために重要です。
これらのニーズを満たすために DevOps スイートを拡張することもできますが、多くの場合、時間の経過とともに複数の アプリケーション プラットフォーム をサポートする必要があり、それらをサポートする特定のツールとプロセスも変更する必要があります。 主要な問題は、標準が移動するターゲットであるということです。 1つのプラットフォームエンジニアリング実務家が述べたように:
この問題には、標準化が含まれます。 「アバンダンウェア」（開発またはサポートが終了したソフトウェア）を扱っています... 自動化されたプロセスが中断する可能性があり、必要な変更を特定する時間のかかるタスクが原因で、標準化が実現されないことがよくあります。 - 大規模物流会社 DevOps エンジニア、Martin
新しい標準または更新された標準に迅速に切り替えることは、通常は不可能であり、既存のプロセスを破棄するとリスクが生じます。 組織で既に複数の DevOps スイートを使用している場合や、個々のツールと開発者サービスの異なる組み合わせをシナリオ別に使用している可能性があります。 中央チームと標準的なソリューションであっても、セルフサービスのニーズが高まるにつれて、変動は避けられません。 そのため、指定されたチームが新しいテクノロジやデプロイ戦略などを試し、その後に意図的な導入と増分ロールアウトを行う、制御された実験を許可する必要があります。
一般に、セルフサービス エクスペリエンスは、自動化とデータ集計という 2 つの主要なカテゴリに分類されます。
データ集計は優れたユーザー エクスペリエンスを生み出しますが、自動化はより重要です。
自動化は重要であり、すべての人に愛されます。 [データ] 集計はセカンダリです。 – Peter、プラットフォーム エンジニアリング リーダー、多国籍技術会社
プラットフォーム エンジニアリングの過程で、自動化によって解決される可能性のある問題を特定しました。 自動化は、コグニティブな負荷と開発者の作業を減らすだけでなく、運用、セキュリティ、その他の役割に最適なツールとサービスにアプリケーションが接続されるようにするのにも役立ちます。
ただし、自動化を推進するために複数のシステムを使用する場合は、自動化された要求と関連する結果を追跡するのに役立つデータ集計のレベルがあります。 外部システムにリンクして、他のニーズを満たしたり、詳細をドリルインしたりすることから始めることができます。 データの集計と可視性は、監査、ガバナンス、無駄の削減 (使用されていない環境など) にも重要です。
インフラストラクチャのプロビジョニングなどの自動化は、システム統合を使用して行うことができますが、開発者に自動化されたように見える手動ワークフロー プロセスをトリガーして容易にすることもできます。 これは、プラットフォームの初期段階、エコシステムに取り込む新しい製品、またはシステム (ソフトウェア ライセンスの割り当てなど) の使用を自動化していない、または自動化できない領域で役立ちます。 適切な設計を使用すると、時間の経過と共に完全に自動化されたフローに切り替える Power Automate などの手動プロセスから始めることができます。 そのため、最初から自動化を設計します。
まず、エンジニアリング システムや内部ポータルなどの既存の投資を再利用してから、CLI、基本的な Web ページ、 または Power Pages、 Power BI、 または Microsoft Fabric ダッシュボードの作成に進み、必要に応じて拡張します。 UX で使用される一貫性のある API を使用すると、ニーズや設定の変化に応じて、時間の経過と同時に複数のインターフェイスをサポートするのに役立ちます。
開発者向けセルフサービス プラットフォーム コンポーネント: API、グラフ、オーケストレーター、プロバイダー、メタデータ
開発者のセルフサービスの基礎について考えてみましょう。
図に示すように、次のコンポーネントは、開発者のセルフサービス基盤の概念の中核をなしています。
| コンポーネント | Description |
|---|---|
| 開発者プラットフォーム API | ユーザー エクスペリエンスのための単一の連絡先。 これは、実質的にシステムと他のシステムとの契約です。 |
| 開発者プラットフォーム グラフ | さまざまな種類のエンティティとテンプレートを検出、関連付け、使用できる、管理されたセキュリティで保護されたデータ グラフ。 エンティティは、複数のソースからのデータ集計を有効にするオブジェクトであり、テンプレートは自動化を可能にするユーザー入力を駆動します。 |
| 開発者プラットフォーム オーケストレーター | システム内または手動プロセスでアクションを実行するテンプレート ベースの要求をルーティングおよび追跡する機能。 これらの要求は、任意の数の異なるワークフロー システムまたはその他のサービスに統合できる一連の開発者プラットフォーム プロバイダーのいずれかにルーティングされます。 |
| 開発者プラットフォーム プロバイダー | ダウンストリームシステムと統合して、エンティティに対するCRUD操作またはテンプレートベースのアクション要求を満たすためのロジックをカプセル化するコンポーネントのセット。 各プロバイダーは、独自の特定の種類のテンプレートをサポートし、一意または共通の種類のエンティティを出力できます。 |
| ユーザー プロファイルとチーム メタデータ | 開発者プラットフォーム API をグループ化してアクセスするために、概念チームに関連付けられている一連の個人に関する情報を保持する機能。 ユーザーは ID プロバイダー アカウント (Microsoft Entra ID サインインなど) に密接に関連付けられていますが、ユーザーとチームの両方が、関連する任意の数のダウンストリーム システム表現に関連付けることができます。 このインフォメーション ストアの実装の 1 つは、開発者プラットフォーム グラフを再利用することです。 開発者のセルフサービス基盤は、ユーザーとチームの両方に共通のエンティティ型を確立し、その情報をグラフに保持できます。 ただし、ここではわかりやすくするために、このストアを個別に保持します。 |
これらの基本コンポーネントを使用すると、時間の経過に伴ってさまざまな構成要素を使用してスワップアウトできます。
作業を開始するには、このすべてをビルドする必要がありますか?
No. まず、これは概念モデルであり、このような基盤が完了したら何ができるかを考えるのに役立ちます。 2 つ目は、開発者プラットフォーム API が主要なインターフェイスになることを考えると、実装の詳細はあまり重要ではありません。 最初の実装では、記述されたさまざまなレイヤーのためにコード内でインターフェイスやクラスを使用したり、他の製品を組み合わせたりすることがあるかもしれません。 顧客の開発プロセスで単に優先順位が低いことが示されるため、項目を省くこともできます。 自分が持っているものから始めて、成長してください。
開発者プラットフォーム API
システムのコントラクトとして機能する開発者プラットフォーム API を定義する必要があります。 この API は、データ アクセスを有効にしたり、プロビジョニングやその他のアクションを実行したりするために、さまざまなユーザー インターフェイスによって使用されます。
この API は、他のシステムの生の基になる API へのアクセスをより具体的で制御されたデータと操作に制限することで、重要な認証とセキュリティレイヤーとして機能します。 API は、ユーザー プロファイル、プラットフォーム内のユーザーの高度なロール (チーム メンバー、管理者など)、プライマリ ID プロバイダーのシステム識別子の独自の表現へのアクセスを提供します。 詳細については、「 ユーザーとチーム」を参照してください。
開発者プラットフォーム プロバイダー
内部開発者プラットフォームの幅が広い場合は、拡張可能なプロバイダー モデルに従って API に機能を導入するシステムを作成または特定する必要があります。 オートメーションやデータ集計などの主要な機能は、適切に定義されたインターフェイスを持つプラグ可能なコンポーネントと対話することによって提供されるという考え方です。 この疎結合は、必要なものを段階的に結び付けるのに役立ち、基礎の残りの部分から独立して機能をテストできるため、保守性が向上します。
また、プラットフォームのスケーラブルな 内部ソース のメンタリティを有効にする重要な方法でもあります。 通常、プラットフォーム エンジニアリングに関する内部ソーシングの取り組みは、継続的なメンテナンスの課題により牽引力を得るに失敗します。 他のチームは、機能を提供することを望んでいるかもしれませんが、プラットフォームのコア内で何かを維持してテストする可能性は低くなります。 逆に、一元化されたチームは、投稿されたコードを維持したり、プル要求を確認したりする能力が限られています。 開発者プラットフォーム プロバイダーの概念は、開発者のセルフサービス基盤内のコア機能に個別に記述されたコードを プラグインできるようにすることで 、この緊張を軽減します。 使用するプロバイダーを慎重に管理し、プロバイダー コードを確認し、特定のプロバイダーが開発者プラットフォームでアクセスできる領域を制限する必要がありますが、プラグ可能なアプローチは、組織全体のより広範な部分で作業をスケーリングすることで、より多くの作業を行うのに役立ちます。
開発者プラットフォーム プロバイダーの主要な概念
Entities
エンティティの概念は、開発者または内部開発者プラットフォームの他のシステムが追跡、更新、提示、または操作を行う必要があるものです。 エンティティは相互にリレーションシップを持つことができます。このリレーションシップは、一緒に作成すると、内部開発者プラットフォームの一部に関する重要な情報を提供する グラフ を構成します。 その後、開発者プラットフォーム プロバイダーはエンティティを出力して、次のようなコア機能を有効にすることができます。
- 外部にプロビジョニングされたリソース/環境、または検出と使用に使用できる API の表示
- 依存関係分析、影響分析、検出などのリレーションシップを公開する。
- 探索とコラボレーションのためのメンテナンス担当者/所有権情報の表示
- ユーザー エクスペリエンスで使用するために、より多くのデータを表示する
この機能を明確に定義された開発者プラットフォーム プロバイダー インターフェイスにカプセル化することで、統合とテストが簡素化され、独立したデプロイが可能になり、プライマリ内部開発者プラットフォーム チームの外部の開発者がプロバイダーに貢献および管理できるようになります。 これは、すべてのツール、サービス、またはプラットフォームが一元的に管理されているわけではありませんが、より広範な組織がまだ機能を共有することを望んでいる大規模または部門の組織で重要です。 そのため、最初にこの道を進まない場合でも、長期的に考えてみてください。
共通プロパティ
各エンティティには、基盤で管理できるように一連の共通プロパティが必要です。 考慮すべきプロパティには、次のようなものがあります。
- 一意識別子
- 名前
- 送信元プロバイダー
- オプションの関連付け:
- 所有者ユーザー
- 担当チーム
- その他のエンティティ
ユーザーとチームのプロパティは、ロールベースのアクセス制御 (RBAC)、検出、データ集計 (チーム レベルの概要など) の 3 つの理由で重要です。 最初から RBAC を組み込むことは、セキュリティにとって重要であり、時間の経過とともに内部開発者プラットフォームを成長させる上で重要です。 開発はチーム スポーツであり、エンティティについて話すユーザーを見つけ出すことは、再利用、サポート、内部リソース化にとってすぐに重要になります。
一般的なエンティティとプロバイダー固有のエンティティ
また、複数のプロバイダーが出力できる一般的な高レベルの正規化されたエンティティのセットを確立することもできます。 例えば次が挙げられます。
- Environments
- リソース
- API（アプリケーションプログラミングインターフェース）
- リポジトリ
- Components
- Tools
これらは通常、 C4 モデル コンテキスト または最も高レベルの コンポーネント図に配置する場合と同様に、高レベルである必要があります。 たとえば、環境の場合、内部インフラストラクチャの地形の詳細を含める必要はありません。同じ UX 内の複数のプロバイダーから異なる概念環境を一覧表示して関連付けるのに十分な情報が必要です。 エンティティは、すべてを取り込む代わりに、システム外の詳細度の低い情報を指すことができます。 これらは、時間の経過に伴うデータ集計を有効にするための中心的な検出の開始点となります。
他のユーザーは特定のユース ケースまたはプロバイダーに固有であるため、徐々に増加する一連のエンティティ型に対応する方法について検討する必要があります。
テンプレート
このコンテキストでのテンプレートの概念は、アクションを推進することを意図しているエンティティの概念とは異なります。 シナリオの例としては、インフラストラクチャのプロビジョニング、リポジトリの作成、その他の実行時間の長いプロセスなどがあります。 これらのテンプレートは、拡張可能な開発者プラットフォーム プロバイダーでも使用でき、エンティティの関連付けを含むエンティティと同じ共通プロパティをサポートする必要があります。
ただし、アクションを実行するために必要な入力 (システムまたはユーザーが指定したかどうか) を定義することもできます。 これらには、リソースの名前付けやオプションの追加など、さまざまなものがあります。
テンプレートの例を次に示します。
- コードとしてのインフラストラクチャ (IaC) テンプレート
- アプリケーション テンプレート (開始右) またはテンプレート リポジトリ
- ビルド パイプライン/ワークフロー テンプレート
- デプロイ パイプライン/ワークフロー テンプレート
- パラメーター化されたスクリプト
- パラメーター化された Power Automate フロー (HTTP 要求によってトリガーされたクラウド フローなど)
- メール テンプレート
エンティティと同様に、テンプレートにはプロバイダー固有のプロパティを含めることができます。
各テンプレートには、プロバイダーに固有の表現が異なる場合があります。 Terraform または ARM テンプレートから、Helm Chart、パラメーター化された GitHub Actions ワークフロー、Azure Pipelines、単純なスクリプト、またはカスタム形式まで、さまざまな場合があります。
実際の基になるテンプレートの詳細は、必ずしも一元的に格納する必要はありません。 これらは、異なるリポジトリ、レジストリ、またはカタログに存在する可能性があります。 たとえば、アプリケーション テンプレートには GitHub テンプレート リポジトリ を使用できますが、IaC テンプレートは制限付きカタログ リポジトリに存在し、開発者は Azure デプロイ環境などを介してのみ間接的にアクセスできます。 他の IaC テンプレートは、Helm チャートなどの OCI アーティファクト レジストリに格納される場合があります。 それ以外の場合は、テンプレートがパラメーター化された HTTP エンドポイントへの参照である可能性があります。 開発者プラットフォーム プロバイダーは、参照できるように各種類のテンプレートに関する十分な情報と、ユーザー エクスペリエンスで使用するために公開されるオプションを提供する必要があります。 ただし、テンプレート自体は、ユース ケースにとって最も自然な場所に格納できます。
特定の領域に関するプラットフォーム エンジニアまたは専門家がテンプレートを作成し、それらを開発チームと共有して再利用します。 システムを介してこれらのテンプレートの使用を一元化することで、開発者のセルフサービスが可能になり、組織の標準またはポリシーへの準拠を強制するのに役立つガードレールが作成されます。 これについては、開発者プラットフォーム オーケストレーターについて少し説明します。
開発者プラットフォーム グラフ
開発者プラットフォーム グラフは、複数のプロバイダーのエンティティとテンプレートを検索可能なグラフに関連付けることができるものとして考えることができます。 ただし、エンティティの実際のデータをグラフ固有のデータベースに直接永続化する必要はありません。 代わりに、プロバイダーとの対話を、必要なメタデータと共にキャッシュして、すべてが一緒に収まるようにすることができます。
グラフは、複数のプロバイダーが提供できる一般的なエンティティと共に使用する場合に強力です。 たとえば、API の一覧は Azure API Center などの製品から取得される場合がありますが、継続的デプロイ システムからデプロイと環境に自動的にフィードすることもできます。 時間の経過と同時に、異なる展開システムを切り替えたり、複数の展開システムをサポートしたりすることもできます。 各デプロイ システムに開発者プラットフォーム プロバイダーがある限り、関連付けを行うことができます。
このグラフから構築された各ユーザー エクスペリエンスでは、共通の API を利用して、検出、検索、ガバナンスなどを強化できます。 開発者プラットフォーム オーケストレーターは、この同じグラフを利用して、開発者プラットフォーム プロバイダーによって実行されたすべてのアクションが、同じ API で使用できるエンティティを自動的に提供できるようにします。
開発者プラットフォーム オーケストレーター
開発者プラットフォーム オーケストレーターを使用すると、開発者またはシステムはテンプレートを使用してアクションを実行する要求を作成できます。 これらのアクションを自ら実行するのではなく、タスクエンジン、ワークフローエンジン、または他のオーケストレーターと協調して実行を調整します。 これは、セルフサービス基盤の一部であることを確認する重要な要素の 1 つです。 これにより、開発者はテンプレートを使用して要求を作成したり、直接アクセス許可なしでアクションを実行したりできます。 さらに、CI や CD の概念とは異なり、これらのアクションはアプリケーションのソース コードに関連している必要はありません。
オーケストレーターとして、GitHub Actions、Azure Pipelines、または別のワークフロー エンジンを使用できます。 これは適切な開始場所ですが、さまざまな種類のテンプレートで異なる基になるエンジンを使用できるように、少し抽象化することをお勧めします。 これは、いくつかの理由で役立ちます。
- まず、 フラッシュ カットを必要とせずに、時間の経過と同時に異なるワークフローとタスク実行エンジンを選択できるようにする必要があります。 複数のエンジンを許可することで、古いエンジンに影響を与えることなく、時間の経過と同時に、または新しいエンジンの使用を新しいアクションに移行できます。
- 調整を支援する一部のプロセスでは、後で完全に自動化する場合でも、最初は手動の手順が必要になる場合があります。
- その他のアクションでは、買掛金やライセンス管理者など、開発チームの外部のロールを対象とすることがあります。Power Automate のようなローコード エンジンは、多くの場合、これらのロールに適しています。
- その他のアクションは、 GitHub Actions や Azure Pipelines のように機能するものをスピンアップする必要がない、またはスケーリングにコスト効率が高くない単純な HTTP 要求によって処理される場合があります。
幸いなことに、開発者プラットフォーム プロバイダーのアイデアを拡張して、自動化のトリガーと追跡の手順に対応することで、この必要な抽象化を実現できます。 次の図を考えてみましょう。
開発者プラットフォーム API とエンティティ プロバイダーのルーティングと処理を行うプラットフォーム オーケストレーターの図。
一般的な概念を次に示します。
- テンプレートでは、必要に応じて、ユーザーが入力できる入力のセットを指定できます。 開発者は、特定のアクションをトリガーするときに、テンプレートを選択し (そのように記述されていない場合でも)、入力を入力します。
- テンプレート関連の入力への参照は、開発者プラットフォーム API の要求になります。
- 要求が送信されると、オーケストレーター内の要求ルーティングと処理コンポーネントが要求のライフサイクルの追跡を開始します。 要求ルーティングと処理コンポーネントは、要求内のテンプレートを、テンプレートが発生した開発者プラットフォーム プロバイダーにルーティングします。
- その後、開発者プラットフォーム プロバイダーは、実装に適した手順を実行します。
- (省略可能)開発者プラットフォーム プロバイダーは、アクションの実行時に要求の状態を更新します。
- 要求が満たされると、開発者プラットフォーム プロバイダーは、開発者プラットフォーム グラフで追加または更新するエンティティのセットを返すことができます。 プロバイダー固有のエンティティまたは一般的なエンティティを指定できます。
必要に応じて、より高度な対話をサポートするために、開発者プラットフォーム プロバイダーは開発者プラットフォーム API を直接呼び出して、より多くのエンティティを入力として取得するか、別の関連アクションを要求することもできます。
一般的なタスクまたはワークフロー エンジンを使用する開発者プラットフォーム プロバイダーを選択します。 具体的には、 ソフトウェア エンジニアリング システムの適用の一部としてまとめるものを橋渡しするものが必要です。 投資する一般的なワークフローまたはタスク実行エンジンの 1 つは CI/CD システムです。
GitHub Actions または Azure Pipelines の使用例
開発者プラットフォーム プロバイダーとしての GitHub Actions または Azure Pipelines がどのように機能するかを簡単に見てみましょう。
GitHub Actions の場合、この作業を行う鍵は、開発者プラットフォーム プロバイダーが指定された GitHub インスタンスに接続し、 Actions REST API を使用してワークフロー ディスパッチ イベントを発生 させ、ワークフローの実行をトリガーできることです。 各ワークフローは、ワークフロー YAML ファイルに workflow_dispatch 構成を追加することで、一連の入力をサポートできます。 Azure DevOps トリガー は似ていますが、実行に Azure DevOps Pipeline API を使用することもできます。 他の製品でも同じ機能が表示される可能性があります。
これらのワークフローまたはパイプラインは、アプリケーションのソース コード リポジトリに存在する必要はありません。 概念は、この事実を利用して次のようなことをすることです。
- プラットフォーム エンジニアまたは DevOps チーム メンバーは、開発者自身がアクセスできない 1 つ以上の中央リポジトリにワークフロー/パイプラインを維持できますが、開発者プラットフォーム プロバイダーは使用するように設定されています。 この同じリポジトリには、ワークフロー/パイプラインで使用されるスクリプトと IaC スニペットを含めることができます。
- これらのワークフロー/パイプラインが適切なダウンストリーム システムと対話できるようにするには、運用またはプラットフォーム エンジニアリング チームの他のメンバーが、必要なシークレットを中央リポジトリに追加できます。 これを行う方法の詳細については、 GitHub Actions と Azure DevOps のドキュメント を参照してください。または、 Azure Key Vault などを使用してシークレットを一元化することもできます。
- これらのワークフロー/パイプラインは、モデルに従って、結果のエンティティをビルド/デプロイ成果物として発行できます (GitHub ドキュメント、 Azure DevOps ドキュメント)。
- 実行中、開発者プラットフォーム プロバイダーはワークフロー/パイプラインの状態を監視し、完了するまでオーケストレーターのライフサイクルの状態を更新できます。 たとえば、 GitHub Actions で Web フックを使用し、 Azure Pipelines でサービス フックを使用して更新を追跡できます。
- 完了すると、プロバイダーは、必要に応じて開発者プラットフォーム グラフに含めるために公開された成果物を使用できます。
最後に、特定のタスクの入力と共に、適切なリポジトリとワークフロー/パイプラインを参照する一連のテンプレートを開発者プラットフォーム グラフに出力するように、この開発者プラットフォーム プロバイダーを設定できます。
CI/CD システムを使用する場合の優れた点は、多くの場合、任意の CLI の実行をサポートするように設定されているため、すべての操作に対して一流の独自の統合は必要ありません。 必要に応じて、時間の経過と同時に追加できます。
この例で説明されている内容の多くは、他の種類のプロバイダーが機能する方法に適用されます。 また、このコンテキストで GitHub Actions または Azure Pipelines を使用する場合、実際の CI/CD パイプラインにも使用する必要はありません。
その他の例
テンプレートを処理できる他の種類の開発者プラットフォーム プロバイダーの例を次に示します。
| Example | Description |
|---|---|
| ソース管理の操作 | 場合によっては、リポジトリの作成または更新、PR の送信、または別のソース管理関連の操作の実行が必要になる場合があります。 一般的な非同期ワークフローエンジンはこのような操作を管理できますが、それがなくても基本的なGit操作を実行できることは便利です。 |
| インフラストラクチャ プロビジョナー | GitHub Actions と Azure Pipelines はインフラストラクチャ プロビジョニングの管理に適していますが、より直接的な統合を選択することもできます。 専用プロバイダーは、セットアップを合理化し、オーバーヘッドを回避できます。 Azure Deployment Environment や Terraform Cloud などのサービスは、IaC テンプレート ベースのプロビジョニングを安全かつ安全に有効にすることにより直接的に重点を置かれています。 その他の例としては、共有クラスター内のアプリケーション用の Kubernetes 名前空間の作成や、 Flux または Argo CD を特定の種類のプロバイダーとして使用する GitOps ワークフローでの Git の使用などがあります。 独自の CLI を使用した実験用 Radius OSS インキュベーション プロジェクトのようなアプリ中心のモデルは、時間の経過と共に独自の開発者プラットフォーム プロバイダーを持つことができます。 重要なのは、適応できるように拡張性を探して計画することです。 |
| アプリケーションスキャフォールディング/シード処理 | アプリケーション テンプレートは、プラットフォーム エンジニアリングが時間の経過とともにリードする重要な部分です。 アプリケーション ソース ツリーをスキャフォールディングするだけでなく、コンテンツを作成してソース コード リポジトリにプッシュし、結果のエンティティをグラフに追加するように設計された専用の開発者プラットフォーム プロバイダーを提供することで、任意のテンプレート エンジンをサポートできます。 すべてのエコシステムには、Yeoman、cookiecutter、または Azure Developer CLI などの独自のアプリケーション スキャフォールディング設定があるため、ここでのプロバイダー モデルを使用すると、同じインターフェイスから複数をサポートできます。 ここでも、重要なのは拡張性です。 |
| 手動プロセス | 手動承認用の PR を自動的に生成する場合でも、Power Platform などを使用して対応する非開発者ペルソナの手動ワークフロー ステップでも、開発者プラットフォーム プロバイダーでも同じテンプレート ベースのモデルを使用できます。 時間の経過と同時に、より自動化された手順に移行することもできます。 |
これらのプロバイダーをすべて開始する必要はないかもしれませんが、開発者プラットフォーム プロバイダーなどを通じた拡張性が、時間の経過と同時に自動化機能の成長にどのように役立つかを確認できます。
ユーザーとチーム
プラットフォーム エンジニアリングは本質的に多システムの問題であるため、セルフサービス基盤でこれらのシステムを統合する際のより困難な問題に対処する方法を計画することが重要です。 ID、ユーザー、チームに関する一般的な課題に取り組むための戦略を次に示します。
| 勧告 | Description |
|---|---|
| 開発者プラットフォーム API を ID プロバイダーと直接統合して、最適なセキュリティを実現します。 | 開発者プラットフォーム API をセキュリティで保護するには、堅牢な ID と Entra ID の RBAC 機能を使用して、Microsoft Entra ID などの ID プロバイダーと直接統合することをお勧めします。 抽象化ではなく、ID プロバイダーのネイティブ SDK と API (MSAL Entra ID など) を直接使用する利点は多数あります。 エンド ツー エンドのセキュリティを推進し、条件付 きアクセス ポリシー が (サインイン時にのみではなく) 継続的に評価されるようにしながら、同じ RBAC モデルに依存することができます。 |
| ダウンストリーム システムでシングル サインオンと ID プロバイダー グループ統合を使用します。 | シングル サインオン (SSO) 統合では、開発者プラットフォーム API に使用しているのと同じ ID プロバイダーとテナントを使用する必要があります。 必ず、SCIM などどのプロトコルのサポートも活用し、IDプロバイダーグループ（例えば、ADグループ）を統合してください。 これらの ID プロバイダー グループをダウンストリーム システムのアクセス許可に結び付けるのは常に自動ではありませんが、少なくとも、後で手動でメンバーシップを管理することなく、各ツールのグループ化の概念に識別プロバイダー グループを手動で関連付けることができます。 たとえば、GitHub の Enterprise Managed User (EMU) のサポートと、 ID プロバイダー グループを GitHub チームに関連付ける機能を手動で利用できます。 Azure DevOps にも 同様の機能があります。 |
1 つの ID プロバイダー グループを超えてチームの概念を確立する
プラットフォーム エンジニアリングの取り組みが進むにつれて、ID プロバイダー グループはメンバーシップを管理するのに適していますが、RBAC とデータ集計のチームの概念を形成するには、複数のグループを組み合わせる必要がある可能性があります。
プラットフォーム エンジニアリングのコンテキストでは、チームを、共同作業を行うさまざまな役割を持つ一連のユーザーとして定義します。 データ集計の場合、レポート ダッシュボードなどの場所で情報を検出してロールアップするには、マルチロール チームのアイデアが不可欠です。 一方、グループは一連のユーザーに対する一般的な ID プロバイダーの概念であり、他の方法ではなく、特定のロールに複数のユーザーを追加するという考え方で設計されています。 そのため、RBAC を使用すると、チームは異なるロールを通じて複数の ID プロバイダー グループに関連付けることができます。
チーム データのソースは、いくつかの異なる場所から取得できます。 たとえば、 チームをコード (TAC) パターンとして使用している場合、開発者プラットフォーム プロバイダーはリポジトリ内のファイルの変更を監視し、ユーザー プロファイルとチーム メタデータ ストアにキャッシュできます。 または、これらのコア RBAC コンストラクトが既に使用可能な Azure デベロッパー センター プロジェクト と直接統合することもできます。
チームまたはユーザー レベルでダウンストリーム システムと統合するためのモデルを確立する
開発者および運用ツール/サービスの中には、ID プロバイダーの概念をネイティブに統合して使用するものもありますが、多くの開発者は、これをグループまたはユーザーの独自の表現 (SSO を使用しても) に抽象化します。 ツール間のアクセスを有効にするだけでなく、この現実はデータ集計の問題を引き起こす可能性もあります。 具体的には、ダウンストリーム システムの API では、ID プロバイダー識別子ではなく独自の識別子が使用されている場合があります (たとえば、Entra ID のオブジェクト ID は直接使用されません)。 これにより、異なる ID 間でマップできない限り、ユーザー レベルまたはチーム レベルのデータのフィルター処理と関連付けは困難になります。
チームとグループ レベルの違いに対処する
TaC などのパターンを使用すると、各システムのチームまたはグループ識別子間のリレーションシップを格納およびアクセスして、それらの間でマップすることができます。 要約すると、セキュリティで保護された監査可能な Git リポジトリがチームのソースになり、PR は更新を行う制御されたユーザー インターフェイスを提供します。 その後、CI/CD システムはダウンストリーム システムを更新し、それに使用したチームの関連識別子の関係を保持できます。
たとえば、これにより、次のリレーションシップを API 呼び出しに格納できます。
チームのリポジトリ内のファイル以外のデータ ソースを使用する場合は、開発者プラットフォーム オーケストレーターを使用して同じ概念を適用して同じことを実現できます。 このモデルでは、チーム データのソースの開発者プラットフォーム プロバイダーが、他のすべてのプロバイダーが受け取って適切に動作するチーム更新イベントをトリガーできます。
ユーザー ID チャレンジに対処する
データ アクセスと集計に関連するもう 1 つの課題は、ユーザー ID の違いです。 チームの場合と同様に、システム間統合を使用してユーザーに関するデータを照会する場合、ID プロバイダーのネイティブ ID (Entra ID のオブジェクト ID など) が特定の API をサポートしているとは想定できません。 ここでも、開発者プラットフォーム API を介してデータにアクセスするユーザー ID のマッピングを格納すると役立ちます。 たとえば、GitHub について考えてみましょう。
システムごとに、ユーザー トークンなしで API を介して別のシステムのユーザー ID を検索できる場合、特定の開発者プラットフォーム プロバイダーは、その場でこのマッピングを生成できます。 場合によっては、パフォーマンスを維持するために、この操作を一括で実行し、結果をキャッシュして参照する必要があるため、複雑になることがあります。
複数のユーザー トークンの使用にフォールバックする
プロバイダーが動作するユーザー ID 変換を行わずにユーザー レベルのデータにアクセスする必要がある場合は、開発者プラットフォーム API を設定して複数のユーザー トークンを管理できます。 例えば次が挙げられます。
- 開発者プラットフォーム API は、ダウンストリーム システムで使用するプロバイダー固有のユーザー トークンのキャッシュをサポートできます。
- API によってトリガーされる特定のプロバイダーとの対話は、プロバイダーのユーザー トークン (使用可能な場合) に含まれます。
- ユーザー トークンが使用できなかった場合に対処するために、プロバイダーは OAuth フローをトリガーして取得します。
- まず、開発者プラットフォーム API は、プロバイダーに渡されたリダイレクト URI を使用して、OAuth フローの認証 URI を返します。 渡される URI には、nonce/1 回限りの使用コードが含まれます。
- その後、API は URI を使用して 認証されていない 応答を返します。
- その後、どの UX でもこの URI を使用して、ブラウザーで適切な認証フローを駆動できます。
- リダイレクトが行われると、開発者プラットフォームは必要なユーザー トークンを受け取り、後で参照できるようにユーザー ID と共にキャッシュします。
- その後、クライアントは API 呼び出しを再試行できます。この呼び出しは成功します。
この概念では、可能な限り ID を再利用でき、ダウンストリーム システムごとに個別のリダイレクト URI を維持する必要がないため、複雑な認証に対処する方法の概要を示します。
ツールとレポート システムへのコンテキスト対応のディープ リンクを使用する
ここまでは、問題領域の自動化の側面について説明してきました。 UI はオートメーション中に返されたエンティティの値を使用してチームの他のシステムへのディープ リンクを作成できるため、これだけでは長い道のりを行うことができます。
自動化に関連しない場合でも、開発者プラットフォーム プロバイダーは、必要な任意の種類のエンティティを出力できます。 ただし、一般に、内部開発者プラットフォーム全体のすべての詳細データを開発者プラットフォーム グラフに取り込む必要はありません。 SonarQube などの製品の Grafana、Prometheus、DataDog、コード インテリジェンスなどの可観測性ソリューションのダッシュボードと、GitHub や Azure DevOps などの DevOps スイートのネイティブ機能はすべて可能です。 代わりに、多くの場合、これらの他のシステムへのディープ リンクを作成することをお勧めします。 エンティティは、ログの内容などの詳細情報を直接含めることなく、リンクを作成するのに十分な情報を提供できます。
ツール間で集計および集計されたデータが必要な場合や、カスタム メトリックを推進する必要がある場合は、 レポート ソリューション Power BI または Microsoft Fabric を次の呼び出しポートにすることができます。 チーム データをマージするには、基盤のデータベースに接続するか、開発者プラットフォーム API を使用します。 たとえば、「 計画と優先順位付け」で説明されているように、カスタム ダッシュボードが必要な場所の 1 つは、内部開発者プラットフォームの成功を測定することです。
"追加の体験を構築する際には慎重に選ぶ"
共通のポータルのようなもので既存の機能を再作成することは魅力的ですが、それを維持する必要があることに注意してください。 これは、製品の考え方に従することが重要な領域です。 ダッシュボードスタイルのインターフェイスは簡単に考え、理解できますが、開発者は他の場所でより多くの価値を見つける可能性があります。
しかし、ここでのモデルでは、開発者プラットフォーム グラフで集計データを使用して、カスタム ユーザー エクスペリエンスを作成できます。 エンティティは、ユーザーまたはチームと結び付けることができるように、組み込みのサポートを持っている必要があります。 これにより、開発者プラットフォーム API は(インデックス作成とキャッシュを使用して) 出力のスコープを設定できます。
ただし、ディープ リンクではなくカスタム UX を作成する必要がある場合でも、すべてのデータを開発者プラットフォーム グラフにプルすることは、通常は最適なアプローチではありません。 たとえば、明確に定義されたマネージド ホームが既に存在する UX にログを表示する場合を考えてみましょう。 関連エンティティの情報を使用して、UX がダウンストリーム システムから直接情報を収集するのに役立ちます。
まず、システム間統合を使用して接続する必要がある場合がありますが、 ユーザーとチームで説明されているモデルのいずれかを実装したら、必要に応じて、格納されているダウンストリームのユーザー/チーム ID またはユーザー認証トークンを使用できます。
考慮すべき一般的なエクスペリエンスの例を次に示します。
| Example | Description |
|---|---|
| 検出と探索 | あるプラットフォームエンジニアリング実務者が言うとおり、「プロジェクトの速度が遅いのは、開発者のスキルではなく、コミュニケーションです」-Daniel、クラウド エンジニア、Fortune 500 Media Company。 ソフトウェアはチームスポーツであるため、チームやその所有するエンティティを発見するのに役立つユーザーインターフェースを作成することは、通常、最初に取り組むべき課題の一つです。 チーム間の検索、検出、ドキュメントは、再利用を促進し、内部ソーシングやサポートのためのコラボレーションを支援します。 Teams は、環境、リポジトリ、ドキュメントなどの他のリソースなど、所有するものを見つけるためにワンストップ ショップを用意することでもメリットがあります。 |
| 環境またはリソースの手動登録 | 開発者プラットフォーム オーケストレーターを介して多くのことをプロビジョニングして追跡できますが、既に存在する、またはまだ自動化されていないリソースや環境を登録することもできます。 Git リポジトリから情報を取得し、リソース/環境管理に情報を追加する単純なプロバイダーは、ここで役立ちます。 既にソフトウェア カタログがある場合、これはモデルに統合する方法にもなります。 |
| API カタログ | 開発者が使用する必要がある追跡 API は、長い道のりを行くことができます。 まだ何も持っていない場合は、API とその状態を表す一連のファイルを含む単純な Git リポジトリから始めて、PR を使用して承認ワークフローを管理することもできます。 これらは開発者プラットフォーム グラフに追加して、表示したり、他のエンティティに関連付けたりすることができます。 より堅牢な機能を実現するために、 Microsoft の API センター や別の製品などを統合できます。 |
| ライセンスの準拠 | 場合によっては、ソフトウェア ライセンスのコンプライアンスとライセンスの使用量を可視化することもできます。 開発者プラットフォームは、ライセンスを使用するために必要な自動化を追加することもできますが、ライセンスが手動で割り当てられている場合でも (たとえば、Git リポジトリの PR プロセスを使用して)、開発者は所有しているもの (およびすべての全体を表示する管理者の能力) を可視化します。 |
| Kubernetes のアプリケーション中心のビュー | 共有 Kubernetes クラスターを使用する場合、開発者がクラスター管理者 UX を使用してアプリケーションの状態を見つけて理解することが困難になる場合があります。 組織によってこの問題の処理方法が異なる場合がありますが、名前空間を使用してアプリケーションを表す方法は、よく知られている方法の 1 つです。 そこから、エンティティを使用して、クラスター内のアプリケーションの名前空間とチームの間の関連付けを確立し、アプリケーションの状態をより開発者に重点を置いたビューを作成し、他のツールや Web UI へのディープ リンクを提供できます。 |
ユーザー エクスペリエンス
組織内のさまざまな役割には、日常業務の重心を表すツールやサービスがあります。 これらのシステムの引っ張りによって、これらの重心外の新しいユーザー エクスペリエンスが牽引力を得るのが困難になる可能性があります。 完璧な世界では、開発者、運用、その他の役割は、多くの場合、既に使用している環境で作業を続けることができます。
これを念頭に置いて、プラットフォーム エンジニアリングの過程を進める際に複数のユーザー インターフェイスを計画することをお勧めします。 これにより、単純な作業を開始し、価値を証明し、必要に応じてより複雑なインターフェイスに成長する機会を得ることもできます。
持っているものを統合する
ソフトウェア エンジニアリング システムの適用とアプリケーション プラットフォームの調整に関する記事を読んだ場合は、引き続き使用するシステムを特定した可能性があります。 どちらの場合も、新しいエクスペリエンスをゼロから構築する前に、自分が持っているものを強化して拡張できるかどうかを評価します。 (ユーザーは、別の新しいユーザー エクスペリエンスや、現在のエクスペリエンスの改善されたバージョンに対してより良い反応を得られるでしょうか。
引き続き使用するツール、ユーティリティ、または Web アプリの一部はカスタムであり、これらは強化の候補として適しています。 ただし、お気に入りのツールやサービスに使用できる拡張性モデルがあるかどうかを忘れないでください。 そこから始めると、大きなメリットが得られます。 これにより、メンテナンスとセキュリティの頭痛を排除し、解決しようとしている問題に集中することができます
たとえば、既に使用している次のサーフェスを拡張できる場合があります。
- エディター と IDE
- あなたのDevOps スイート
- CLI の 拡張性も高まっています
- Power Pages のような低コード/コードなしの環境
それぞれが、既存の重心であるため、最初から設定したものよりも、特定のロールの開始点が優れている場合があります。 共通の開発者プラットフォーム API をベースラインとして使用すると、時間の経過と同時に、物事のスワップ、実験、変更を行えます。
開発者ポータルを作成するための Web エディター拡張機能を検討する
開発者向けの Web ベースのエクスペリエンスをお探しの場合は、最近の傾向は、Web ベースのバージョンのエディターと IDE であることに注意してください。 VS Code を使用する場合と同様に、多くのユーザーには拡張機能のサポートがあります。 VS Code では、これらの Web エクスペリエンス用に構築したものは、2 つの利点のためにローカルに翻訳されます。
GitHub Codespaces などのサービス以外にも、vscode.dev はコンピューティングを使用しない VS Code エディターの無料 Web バージョンですが、カスタム UI に Web ビューを使用する拡張機能など、特定の種類の拡張機能のサポートが含まれています。
開発者が VS Code 自体を使用していない場合でも、UX パターンはよく知られており、他の開発者ツールで見つけることができます。 vscode.dev を使用すると、ツール自体に加えて、開発者エクスペリエンスのための便利で使い慣れた Web ベースの基盤を提供できます。
これらは、開発者向けのポータルとして使い慣れた形式で機能し、ローカルでの使用にも変換できます。
ChatOps
見過ごされることが多いもう 1 つの機会は、ChatOps インターフェイスの実装です。 ChatGPT や GitHub Copilot などの AI 製品の増加によるチャットベースのインターフェイスの増加を考えると、アクション コマンドやスラッシュ コマンドは、自動化ワークフローをトリガーしたり、状態を確認したりするための便利な方法を提供できます。 ほとんどのアプリケーションCI/CDプラットフォームは、Microsoft Teams、Slack、Discordなどのシステムをすぐにサポートしているため、これは他のユーザーインターフェースや関連する運用職が毎日使用する通常の方法で統合する自然な手段です。 さらに、これらすべての製品には拡張性モデルがあります。
新しい開発者ポータルへの投資
ベースとして使用する既存のポータルまたはインターフェイスがないと仮定して、新しい開発者ポータルを構築することができます。 これは出発点ではなく目的地と考えてください。 開発チームがまだあなたと一緒に作業していない場合は、今がその取り組みを始める時です。 すべての組織が異なるので、この種のエクスペリエンスで何が必要かについて、万能の答えはありません。 その結果、現時点では、このような目的でそのまま素早く立ち上げて使用できる既製品に対する既定の回答はありません。
カスタムビルドのセルフホステッド オプションの場合、一般的な Web ポータル フレームワークは新しくはありません。また、開発チームが既に使用している可能性があります。 早期のフィードバックのためにユーザーの前で何かを取得しようとしている場合は、一般的な開発者プラットフォーム API に接続するための低コード の Power Pages と同じくらい単純なものから始めることもできます。
最近の開発者ポータルの取り組みは、より多くの意見を持っています。 たとえば、 Backstage.io は、Spotifyのニーズを満たすために最初に構築されたカスタム開発者ポータルツールキットです。 これには、React.js用の create-react-app と同様に、ソース ツリーをブートストラップするのに役立つ CLI が含まれています。
ポータル ツールキットとして、作業を開始する必要があり、カスタマイズするには TypeScript、Node.js、React に関する知識が必要です。 しかし、それについての素晴らしい点は、ツールキットとして、ほとんど何でも変更できることです。 独自のソフトウェア カタログとテンプレートメカニズムも備えていますが、その使用は必要なく、プラグインと呼ばれる新しいコードを取り込むための明確に定義された方法です。