開発者のセルフサービス基盤を設計する

エンジニアリング システムのターゲットを十分に理解したら、より洗練された開発者セルフサービス エクスペリエンスを作成できます。 開発者のセルフサービス エクスペリエンスは、概念、パターン、コンポーネントの基盤に基づいて構築されています。

現在、ここで説明されているすべてが組織に必要なわけではありませんが、カスタム製品を構築したり、関連製品を評価したりする場合は、これらの概念を念頭に置く必要があります。 開発者のセルフサービス エクスペリエンス モデルは、自社製品、既製製品、オープンソース製品の組み合わせで構成できます。 Backstage.io のような製品やオープンソースのポータル ツールキットでは、以下で説明するモデルの一部の要素に異なる用語が使用される場合がありますが、モデルは引き続き役立ちます。

ワークフローの自動化, データの集計, 単純な開始, 段階的な拡張

目標は、制御および管理されたタスクの実行とプロビジョニングを通じてガードレールを使用したセルフサービスを有効にし、一元的な可視性を実現することです。 重点を置く最も重要な領域は、面倒なものか、複雑さまたはアクセス許可のために開発者が自分でできないものです。 この最後の部分は、手動のサービス デスク プロセスを開発者に強制することなく、最小限の特権の原則に従えるようにするために重要です。

これらのニーズを満たすために DevOps スイートを拡張することもできますが、多くの場合、時間の経過と共に複数のアプリケーション プラットフォームをサポートする必要があり、それらをサポートする特定のツールとプロセスも変更する必要があります。 主な問題は、標準が移動するターゲットであるということです。 あるプラットフォーム エンジニアリング専門家は、次のように述べます。

問題なのは、標準化と... 'アバンダンウェア' への対処です... 自動化されたプロセスが中断する可能性があり、必要な変更を特定する時間のかかるタスクが原因で、標準化が実現されないことがよくあります。 - Martin、DevOps エンジニア、大手物流会社

新しい標準または更新された標準に迅速に切り替えることは、通常は不可能であり、既存のプロセスを破棄するとリスクが生じます。 組織で既に複数の DevOps スイートを使用している場合や、個々のツールと開発者サービスの異なる組み合わせをシナリオ別に使用している可能性があります。 中央チームと標準的なソリューションをもってしても、セルフサービスのニーズが高まるにつれて、変動は避けられません。 そのため、指定されたチームが新しいテクノロジやデプロイ戦略などを試し、その後、意図的な導入と段階的なロールアウトを行う、制御された実験を有効にする必要があります。

一般に、セルフサービス エクスペリエンスは、自動化とデータ集計という 2 つの主要なカテゴリに分類されます。

データ集計は優れたユーザー エクスペリエンスを生み出しますが、自動化はより重要です。

自動化は重要であり、すべての人に愛されます。 [データ] 集計はあまり重要ではありません。 – Peter、プラットフォーム エンジニアリング リーダー、多国籍テクノロジ企業

プラットフォーム エンジニアリング体験では、自動化によって解決される可能性のある問題を特定しました。 自動化は、認知的負荷と開発者の作業を減らすだけでなく、運用、セキュリティ、その他の役割に最適なツールとサービスにアプリケーションが接続されるようにするのにも役立ちます。

ただし、自動化を推進するために複数のシステムを使用している場合は、自動化された要求と関連する結果を追跡するのに役立つデータ集計のレベルが便利です。 外部システムにリンクして、他のニーズを満たしたり、詳細にドリルインしたりすることから始めることができます。 データの集計と可視性は、監査、ガバナンス、無駄の削減 (未使用の環境など) にも重要です。

インフラストラクチャのプロビジョニングなどの自動化は、システム統合を使用して行うことができますが、開発者に自動化されたように見える手動ワークフロー プロセスをトリガーして容易にすることもできます。 これは、プラットフォームの初期段階、エコシステムに取り込む新しい製品、システム (ソフトウェア ライセンスの割り当てなど) の使用を自動化していない領域、または自動化できない領域で役立ちます。 適切な設計を使用すると、時間の経過と共に完全に自動化されたフローに切り替える Power Automate などの手動プロセスから始めることができます。 そのため、最初から自動化を設計します。

まず、エンジニアリング システムや内部ポータルなどの既存の投資を再利用してから、CLI、基本的な Web ページ、または Power Pages、Power BI、または Microsoft Fabric ダッシュボードを作成し、必要に応じて拡張します。 UX で使用される一貫性のある API を使用すると、ニーズや設定の変化に応じて、時間の経過と共に複数のインターフェイスをサポートするのに役立ちます。

開発者のセルフサービス プラットフォーム コンポーネント: API、グラフ、オーケストレーター、プロバイダー、メタデータ

開発者のセルフサービス基盤について考えてみましょう。

図に示すように、次のコンポーネントは、開発者のセルフサービス基盤の概念の中核をなしています。

これらの基本コンポーネントを使用すると、時間の経過と共にさまざまな構成要素を使用してスワップ アウトできます。

作業を開始するには、このすべてをビルドする必要がありますか?

いいえ。 まず、これは概念モデルであり、このような基盤が完成したら何ができるかを考えるのに役立ちます。 2 つ目は、開発者プラットフォーム API が主要なインターフェイスになることを考えると、実装の詳細はあまり重要ではありません。 最初の実装では、コード内のインターフェイスとクラスを、他の製品に記述された、または混在するさまざまなレイヤーに使うことから始めるのがいいでしょう。 また、顧客開発が優先順位が低いことを示すため、側面を省略できる可能性もあります。 自分が持っているものから始めて、成長してください。

開発者プラットフォーム API

システムのコントラクトとして機能する開発者プラットフォーム API を定義する必要があります。 この API は、データ アクセスを有効にしたり、プロビジョニングやその他のアクションを実行したりするために、さまざまなユーザー インターフェイスによって使用されます。

この API は、他のシステムの基になる生の API へのアクセスをより具体的で制御されたデータと操作に制限することで、重要な認証とセキュリティ レイヤーとして機能します。 API は、ユーザー プロファイル、プラットフォーム内のユーザーの高レベルのロール (チーム メンバー、管理者など)、プライマリ ID プロバイダーのシステム識別子の独自の表現へのアクセスを提供します。 詳細については、「ユーザーとチーム」をご覧ください。

開発者プラットフォーム プロバイダー

内部開発者プラットフォームの幅を考慮して、拡張可能なプロバイダー モデルに従って API に機能を導入するシステムを作成または特定します。 オートメーションやデータ集計などの主要な機能は、適切に定義されたインターフェイスを持つプラグ可能なコンポーネントと対話することによって提供されるという考え方です。 この疎結合は、必要なものを段階的に結び付けるのに役立ち、基盤の残りの部分から独立して機能をテストできるため、保守性が向上します。

また、スケーラブルな内部ソースの考え方をプラットフォームに対して有効にする重要な方法でもあります。 通常、プラットフォーム エンジニアリングに関する内部ソーシングの取り組みは、継続的なメンテナンスの課題により勢いを得ることができません。 他のチームは、機能を提供することを望んでいるかもしれませんが、プラットフォームのコア内で何かを維持してテストする可能性は低くなります。 逆に、一元化されたチームは、投稿されたコードを維持したり、プル要求を確認したりする能力が限られています。 開発者プラットフォーム プロバイダーの概念は、開発者のセルフサービス基盤内のコア機能に個別に記述されたコードを "プラグイン" できるようにすることで、この緊張を軽減します。 使用するプロバイダーを慎重に管理し、プロバイダー コードを確認し、開発者プラットフォームで特定のプロバイダーがアクセスできる領域を制限する必要がありますが、プラグ可能なアプローチは、組織全体のより広範な部分で作業をスケーリングすることで、より多くの作業を行うのに役立ちます。

開発者プラットフォーム プロバイダーの主要な概念

エンティティ

エンティティの概念は、開発者または内部開発者プラットフォームの他のシステムが追跡、更新、提示、または操作を行う必要があるものです。 エンティティは相互にリレーションシップを持つ可能性があり、これらを組み合わせると、内部開発者プラットフォームの一部に関する重要な情報を提供するグラフを構成できます。 その後、開発者プラットフォーム プロバイダーはエンティティを出力して、次のようなコア機能を有効にすることができます。

• 外部にプロビジョニングされたリソースや環境、または検出と使用に使用できる API の表示
• 依存関係分析、影響分析、検出などのリレーションシップの公開
• 検出とコラボレーションのためのメンテナンス担当者や所有権情報の表示
• ユーザー エクスペリエンスで使用するために、より多くのデータを表示

この機能を明確に定義された開発者プラットフォーム プロバイダー インターフェイスにカプセル化することで、統合とテストが簡素化され、独立したデプロイが可能になり、プライマリ内部開発者プラットフォーム チームの外部の開発者がプロバイダーに貢献および管理できるようになります。 これは、すべてのツール、サービス、またはプラットフォームが一元的に管理されているわけではありませんが、より広範な組織がまだ機能を共有することを望んでいる大規模または部門の組織で重要です。 そのため、最初はこのパスを進まない場合でも、長期的に考えてみてください。

共通プロパティ

各エンティティには、基盤で管理できるようにするための一連の共通プロパティが必要です。 考慮すべきプロパティには、次のようなものがあります。

• 一意識別子
• Name
• 送信元プロバイダー
• 以下の項目との関連付け:
  • 所有ユーザー
  • 所有チーム
  • その他のエンティティ

ユーザーとチームのプロパティは、ロールベースのアクセス制御 (RBAC)、検出、データ集計 (チーム レベルの概要など) の 3 つ理由から重要です。 最初から RBAC を構築することは、セキュリティの観点から重要であり、時間の経過に伴う内部開発者プラットフォームの拡張に不可欠です。 開発はチーム スポーツであり、再利用、サポート、内部リソース化を達成するには、エンティティについて相談できるユーザーを見つけておくことが重要です。

共通エンティティとプロバイダー固有のエンティティ

また、複数のプロバイダーが出力できる共通かつ高レベルの正規化されたエンティティのセットを確立する必要があります。 次に例を示します。

• 環境
• リソース
• API
• リポジトリ
• コンポーネント
• ツール

これらは一般的に、C4 モデルのコンテキストや最も高レベルのコンポーネント図に置く場合と同様に、高レベルに位置する必要があります。 たとえば、環境の場合、内部インフラストラクチャ トポグラフィの詳細を含める必要はありません。必要になるのは、同じ UX 内の複数のプロバイダーからの異なる概念環境を一覧表示して関連付けるための十分な情報のみです。 エンティティは、すべての情報を使用せずに、システム外のより低いレベルの詳細を指すことができます。 これは、検出の開始点となり、時間の経過に伴うデータ集計を実現するための中心的な要素となります。

その他は特定のユース ケースまたはプロバイダーに固有であるため、徐々に増加するエンティティの種類に対応する方法について検討する必要があります。

テンプレート

このコンテキストにおけるテンプレートの概念は、アクションの推進を目的としている点で、エンティティの概念とは異なります。 シナリオの例には、インフラストラクチャのプロビジョニング、リポジトリの作成、その他の長期プロセスなどがあります。 これらのテンプレートは、拡張可能な開発者プラットフォーム プロバイダーでも使用でき、エンティティの関連付けなどの、エンティティと同じ共通プロパティをサポートする必要があります。

ただし、システム指定かユーザー指定かに関係なく、アクションを実行するために必要な入力を定義することもできます。 入力にはさまざまな種類があり、リソースの名前付けやオプションの追加などが含まれます。

テンプレートの例は次のとおりです。

• コードとしてのインフラストラクチャ (IaC) テンプレート
• アプリケーション テンプレート (Start Right) またはテンプレート リポジトリ
• ビルド パイプライン/ワークフロー テンプレート
• デプロイ パイプライン/ワークフロー テンプレート
• パラメーター化されたスクリプト
• パラメーター化された Power Automate フロー (例: HTTP 要求によってトリガーされたクラウド フロー)
• メール テンプレート

エンティティと同様に、テンプレートにはプロバイダー固有のプロパティを含めることができます。

各テンプレートには、プロバイダー固有の異なる表現が含まれる場合があります。 これには、Terraform または ARM テンプレート、Helm チャート、パラメーター化された GitHub Actions ワークフロー、Azure Pipelines、単純なスクリプト、カスタム形式などのさまざまな種類があります。

実際の基礎となるテンプレートの詳細は、必ずしも一元的に格納する必要はありません。 これらは、異なるリポジトリ、レジストリ、カタログに存在する可能性があります。 たとえば、アプリケーション テンプレートには GitHub テンプレート リポジトリを使用できますが、IaC テンプレートは制限付きのカタログ リポジトリに存在し、開発者は Azure Deployment Environments などを介して間接的にのみアクセスできます。 他の IaC テンプレートは、Helm チャートと同様に OCI アーティファクト レジストリに保存される場合があります。 それ以外の場合は、テンプレートがパラメーター化された HTTP エンドポイントへの参照である可能性があります。 開発者プラットフォーム プロバイダーは、各種類のテンプレートに関する十分な情報を参照可能な状態にし、ユーザー エクスペリエンスで使用するために公開されるオプションを提供する必要があります。 ただし、テンプレート自体は、ユース ケースに最も適した場所に格納できます。

特定の領域に関するプラットフォーム エンジニアまたは専門家がテンプレートを作成し、それらを開発チームと共有して再利用します。 システムを介してこれらのテンプレートの使用を一元化することで、開発者のセルフサービスが可能になり、組織のコンプライアンスまたはポリシーへの準拠を強制するのに役立つガードレールが作成されます。 これについては、開発者プラットフォーム オーケストレーターについて少し説明します。

開発者プラットフォーム グラフ

開発者プラットフォーム グラフは、複数のプロバイダーのエンティティとテンプレートを検索可能なグラフに関連付けることができるものとして考えることができます。 ただし、エンティティの実際のデータをグラフ固有のデータベースに直接永続化する必要はありません。 代わりに、プロバイダーとの対話を、必要なメタデータと共にキャッシュして、すべてが一緒に収まるようにすることができます。

グラフは、複数のプロバイダーが提供できる一般的なエンティティと共に使用する場合に効果的です。 たとえば、API の一覧は、Azure API Center などの製品から取得される場合がありますが、継続的デプロイ システムからデプロイと環境に自動的にフィードすることもできます。 時間の経過と同時に、異なるデプロイ システムを切り替えたり、複数のデプロイ システムをサポートしたりすることもできます。 各デプロイ システムに開発者プラットフォーム プロバイダーがある限り、関連付けを行うことができます。

このグラフから構築された各ユーザー エクスペリエンスでは、共通の API を利用して、検出、検索、ガバナンスなどを強化できます。 開発者プラットフォーム オーケストレーターは、この同じグラフを利用して、開発者プラットフォーム プロバイダーによって実行されたすべてのアクションが、同じ API で使用できるエンティティを自動的に提供できるようにします。

開発者プラットフォーム オーケストレーター

開発者プラットフォーム オーケストレーターを使用すると、開発者またはシステムはテンプレートを使用してアクションを実行する要求を作成できます。 これらのアクション自体は実行されませんが、代わりにタスク エンジン、ワークフロー エンジン、または別のオーケストレーターと調整してアクションを実行します。 これは、セルフサービス基盤の一部であることを確認する重要な要素の 1 つです。 これにより、開発者はテンプレートを使用して要求を作成したり、直接アクセス許可なしでアクションを実行したりできます。 さらに、CI や CD の概念とは異なり、これらのアクションはアプリケーションのソース コードに関連している必要はありません。

オーケストレーターとして、GitHub Actions、Azure Pipelines、または別のワークフロー エンジンを使用できます。 これは適切な開始場所ですが、さまざまな種類のテンプレートで異なる基になるエンジンを使用できるように、少し抽象化することをお勧めします。 これは、次のようなさまざまな理由で役立ちます。

• まず、flash cut を必要とせずに、時間の経過と同時に異なるワークフローおよびタスク実行エンジンを選択できるようにする必要があります。 複数のエンジンを許可することで、古いエンジンに影響を与えることなく、時間の経過と共に、または、新しいエンジンを使用することで新しいアクションに移行できます。
• 調整を支援する一部のプロセスでは、後で完全に自動化する場合でも、最初は手動の手順が必要になる場合があります。
• その他のアクションでは、買掛金勘定管理者やライセンス管理者など、開発チームの外部ロールを対象とすることがあります。Power Automate のようなローコード エンジンは、多くの場合、これらのロールに適しています。
• その他のアクションは、単純な HTTP 要求を通じて処理できます。ここで、GitHub Actions または Azure Pipelines のように機能するものをスピンアップするのは不要であるか、スケーリングに対してコスト効率が高くありません。

幸いなことに、開発者プラットフォーム プロバイダーのアイデアを拡張して、自動化のトリガーと追跡の自動化手順に対応することで、この必要な抽象化を実現できます。 次の図について考えてください。

一般的な概念を次に示します。

• テンプレートでは、必要に応じて、ユーザーが入力できる入力のセットを指定できます。 開発者は、特定のアクションをトリガーするときに、テンプレートを選択し (そのように記述されていない場合でも)、入力を入力します。
• テンプレート関連の入力への参照は、開発者プラットフォーム API の要求になります。
• 要求が送信されると、オーケストレーター内の要求ルーティングと処理コンポーネントが要求のライフサイクルの追跡を開始します。 要求ルーティングと処理コンポーネントは、要求内のテンプレートを、テンプレートが発生した開発者プラットフォーム プロバイダーにルーティングします。
• その後、開発者プラットフォーム プロバイダーは、実装に適した手順を実行します。
• (省略可能) 開発者プラットフォーム プロバイダーは、アクションの実行時に要求の状態を更新します。
• 要求が満たされると、開発者プラットフォーム プロバイダーは、開発者プラットフォーム グラフに追加 / 更新するエンティティのセットを返すことができます。 これらは、プロバイダー固有のエンティティまたは一般的なエンティティです。

必要に応じて、より高度な対話をサポートするために、開発者プラットフォーム プロバイダーは開発者プラットフォーム API を直接呼び出して、より多くのエンティティを入力として取得するか、別の関連アクションを要求することもできます。

一般的なタスクまたはワークフロー エンジンを使用する開発者プラットフォーム プロバイダーを選択します。 具体的には、ソフトウェア エンジニアリング システムを適用するの一部としてまとめるものを橋渡しするものが必要です。 投資する一般的なワークフローまたはタスク実行エンジンの 1 つは CI/CD システムです。

Azure Pipelines または GitHub Actions を使用する例

開発者プラットフォーム プロバイダーとしての 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 Pipeliness でサービス フックを使用して更新プログラムを追跡できます。
• 完了すると、プロバイダーは、必要に応じて開発者プラットフォーム グラフに含めるために公開された成果物を使用できます。

最後に、特定のタスクの入力と共に、適切なリポジトリとワークフロー / パイプラインを参照する一連のテンプレートを開発者プラットフォーム グラフに出力するように、この開発者プラットフォーム プロバイダーを設定できます。

CI/CD システムを使用する場合の優れた点は、多くの場合、任意の CLI の実行をサポートするように設定されているため、すべての作業に対してファーストクラスの独自の統合は必要ありません。 必要に応じて、それらは時間の経過と共に追加できます。

この例で説明されている内容の多くは、他の種類のプロバイダーがどのように機能するかについて適用されます。 また、このコンテキストで GitHub Actions または Azure Pipelines を使用する場合、実際の CI/CD パイプラインにも使用する必要はありません。

その他の例

テンプレートを処理できる他の種類の開発者プラットフォーム プロバイダーの例を次に示します。

これらのプロバイダーをすべて開始する必要はないかもしれませんが、開発者プラットフォーム プロバイダーなどで拡張性を持たせておくと、将来的に自動化機能の強化に役立ちます。

ユーザーとチーム

プラットフォーム エンジニアリングは本質的にマルチシステムの問題であるため、これらのシステムを統合する際に発生するより困難な問題を、セルフサービス基盤でどのように解決するかを計画しておくことが重要です。ID、ユーザー、チームに関する一般的な課題に取り組むための戦略を次に示します。

1 つの ID プロバイダー グループを超えてチームの概念を確立する

プラットフォーム エンジニアリングの過程が進むにつれて、ID プロバイダー グループはメンバーシップを管理するのに最適ですが、ロールベースのアクセス制御 (RBAC) とデータ集計のチームの概念を形成するには、複数のグループを組み合わせる必要があります。

プラットフォーム エンジニアリングのコンテキストでは、チームを、共同作業を行うさまざまな役割を持つ一連のユーザーとして定義します。 データ集計の場合、レポート ダッシュボードなどの場所で情報を検出してロールアップするには、マルチロール チームのアイデアが不可欠です。 一方、グループは一連のユーザーに対する一般的な ID プロバイダーの概念であり、特定のロールに複数のユーザーを追加するという考え方で設計されており、その逆ではありません。 そのため、RBAC を使用すると、チームは異なるロールを通じて複数の ID プロバイダー グループに関連付けることができます。

チーム データのソースは、いくつかの異なる場所から取得できます。 たとえば、コード パターンとしての Teams (TaC) を使用している場合、開発者プラットフォーム プロバイダーはリポジトリ内のファイルの変更を監視し、それらをユーザー プロファイルとチーム メタデータ ストアにキャッシュできます。 または、Azure Dev Center Project (これらのコア RBAC コンストラクトを既にもっている) のようなものと直接統合することもできます。

チームまたはユーザー レベルでダウンストリーム システムと統合するためのモデルを確立する

開発者および運用ツール / サービスの中には、ID プロバイダーの概念をネイティブに統合して直接使用するものもありますが、多くの開発者や運用ツール / サービスは、これをグループまたはユーザーの独自の表現 (SSO を使用する場合でも) に抽象化します。 ツール間のアクセスを有効にするだけでなく、この現実はデータ集計の問題を引き起こす可能性もあります。 具体的には、ダウンストリーム システムの API では、ID プロバイダー識別子ではなく独自の識別子が使用されている場合があります (例: Entra ID のオブジェクト ID は直接使用されません)。 これにより、異なる ID 間でマップできない限り、ユーザー レベルまたはチーム レベルのデータのフィルター処理と関連付けは困難になります。

チームとグループ レベルの違いに対処する

TaC などのパターンを使用すると、各システムのチームまたはグループ識別子間のリレーションシップを格納およびアクセスして、それらの間でマップすることができます。 要約すると、セキュリティで保護された監査可能な Git リポジトリがチームのソースになり、PR は更新プログラムを作成する制御されたユーザー インターフェイスを提供します。 その後、CI/CD システムはダウンストリーム システムを更新し、それに使用したチームの関連識別子リレーションシップを保持できます。

たとえば、これにより、次のリレーションシップを API 呼び出しに対して格納できます。

Teams のリポジトリ内のファイル以外のデータ ソースを使用する場合は、開発者プラットフォーム オーケストレーターを使用して同じ一般概念を適用して同じことを実現できます。 このモデルでは、チーム データのソースの開発者プラットフォーム プロバイダーが、他のすべてのプロバイダーが受け取って適切に動作するチーム更新イベントをトリガーできます。

ユーザー 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 は自動化中に返されたエンティティの値を使用して、チームの他のシステムへのディープ リンクを作成できるため、これだけでも大きな効果が期待できます。

自動化に関連していない場合でも、開発者プラットフォーム プロバイダーはあらゆる種類のエンティティのニーズを発行できます。 ただし、一般的に、内部開発者プラットフォーム全体のすべての詳細データを開発者プラットフォーム グラフに取り込むことは望ましくありません。 Grafana、Prometheus、DataDog などの可観測性ソリューションのダッシュボード、SonarQube などの製品のコード インテリジェンス、GitHub や Azure DevOps などの DevOps スイートのネイティブ機能はすべて非常に優れています。 そのため、多くの場合は、データを直接取り込む代わりに、このような他のシステムに対するディープ リンクを作成することをお勧めします。 エンティティは、ログの内容などの詳細情報を直接含めることなく、リンクの作成に必要な情報を提供できます。

ツール間で集計および要約されたデータが必要な場合や、カスタム メトリックを推進する必要がある場合は、次にレポート ソリューション Power BI または Microsoft Fabric を使用できます。 チーム データを結合するには、Foundation のデータベースに接続するか、開発者プラットフォーム API を使用します。 たとえば、「計画と優先順位付け」で説明されているように、内部開発者プラットフォームの成功を測定するために、カスタム ダッシュボードが必要になる場合があります。

追加のエクスペリエンスを構築する際は慎重に選択する

既存の機能を共通のポータルなどに再作成することは魅力的ですが、それを管理する必要があることに注意してください。 この点に関しては、製品志向を重視する必要があります。 ダッシュボード スタイルのインターフェイスは想像しやすく、理解しやすいですが、開発者にとってより高価値なシステムが他にあるかもしれません。

しかし、このモデルでは、開発者プラットフォーム グラフで集計データを使用して、カスタム ユーザー エクスペリエンスを作成できます。 エンティティは、ユーザーまたはチームと関連付けることができるように、組み込みのサポートを持っている必要があります。 これにより、開発者プラットフォーム API は (インデックス作成とキャッシュを使用して) 出力のスコープを設定できます。

ただし、通常は、ディープ リンクではなくカスタム UX を作成する必要がある場合でも、開発者プラットフォーム グラフにすべてのデータを取り込むのは最適なアプローチではありません。 たとえば、明確に定義されたマネージド ホームが既にある UX にログを表示したい場合、 関連エンティティの情報を使用して、UX がダウンストリーム システムから直接情報を収集できるようにします。

最初はシステム間統合を使用して接続する必要があるかもしれませんが、ユーザーおよびチームで説明されているいずれかのモデルを実装した後は、必要に応じて、格納されているダウンストリームのユーザー/チーム ID またはユーザー認証トークンを使用できます。

ここで考慮すべき一般的なエクスペリエンスの例を次に示します。

ユーザー エクスペリエンス

組織内ではロールごとに、日常業務で使用する主要なツールやサービスが異なります。 使い慣れたシステムから完全に離れるのは難しく、これらを無視して新しいユーザー エクスペリエンスを導入することはできません。 開発者、運用、その他のロールが、慣れ親しんだ環境 (多くの場合は既存の環境) で作業を続けることができるのが理想です。

これを念頭に置いて、プラットフォーム エンジニアリング体験を進める際に複数のユーザー インターフェイスを計画することをお勧めします。 これにより、単純な作業を開始し、価値を証明し、必要に応じてより複雑なインターフェイスに成長する機会を得ることもできます。

持っているものを統合する

「ソフトウェア エンジニアリング システムを適用する」および「アプリケーション プラットフォームを絞り込む」の記事を読んだ場合は、引き続き使用するシステムを特定したかもしれません。 どちらの場合も、新しいエクスペリエンスをゼロから構築する前に、自分が持っているものを強化して拡張できるかどうかを評価します。 (ユーザーから、別の新しいユーザー エクスペリエンスや、現在のエクスペリエンスの改善されたバージョンに対してより良い反応を得られるか、自問してください。)

引き続き使用するツール、ユーティリティ、または 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 ポータル フレームワークは新しくはありません。また、開発チームが既に使用中で、利用できる可能性があります。 早期のフィードバックのためにユーザーの前で何かを取得しようとしている場合は、ローコードの Power Pages のように簡単なものから始めて、一般的な開発者プラットフォーム API に接続することもできます。

最近の開発者ポータルの取り組みは、より厳格です。 たとえば、Backstage.io は、Spotify のニーズを満たすために最初に構築されたカスタム開発者ポータル ツールキットです。 これには、create-react-app が React.js に対して行うのと同じように、ソース ツリーをブートストラップするのに役立つ CLI が含まれています。

ポータル ツールキットとして、作業を開始する必要があり、カスタマイズするには TypeScript、Node.js、React に関する知識が必要です。 しかし、それについての素晴らしい点は、ツールキットとして、ほとんど何でも変更できることです。 独自のソフトウェア カタログとテンプレート メカニズムも備えていますが、その使用は必須ではなく、プラグインと呼ばれる新しいファースト パーティおよびサード パーティのコードを取り込む方法が明確に定義されています。

関連するコンテンツ

• Power Pages
• Backstage.io
• ソフトウェア エンジニアリング システムの適用