開発者向けセルフサービス基盤を設計する
エンジニアリング システムのターゲットを十分に理解したら、より高度な開発者向けセルフサービス エクスペリエンスの作成を開始できます。 このセクションでは、製品を作成するための柔軟な基盤を作成する製品を構築または評価するための概念アーキテクチャについて説明します。 これらの概念、パターン、コンポーネントを総称して、開発者セルフサービス基盤として参照します。
現在のorganizationでここに記載されているすべてが必要なわけではありませんが、カスタム製品を構築したり、関連製品を評価したりする場合は、これらの概念を念頭に置く必要があります。 あなたの世界では、このモデルは、自家製、既製、オープンソース製品の組み合わせで構成できます。 Backstage.io のような製品またはオープンソースのポータル ツールキットでは、このセクションで説明するモデルの一部の要素に異なる用語が使用される場合がありますが、モデルは引き続きユーザーの方向を変えるのに役立ちます。
Goalsと考慮事項
この分野での取り組みの主な目標は、制御された管理されたタスクの実行とプロビジョニングを通じてガードレールを使用したセルフサービスと一元的な可視性を実現することです。 多くの場合、焦点を当てる最も重要な領域は、面倒なものか、複雑さやアクセス許可のために開発者が自分で実行できないことです。 この最後の部分は、開発者に手動のサービス デスク プロセスを強制することなく、最小限の特権の原則に従えるようにするために重要です。
これらのニーズを満たすために DevOps スイートを拡張することもできますが、多くの場合、時間の経過と同時に複数の アプリケーション プラットフォーム をサポートする必要があり、それらをサポートする特定のツールとプロセスも変更する必要があります。 主要な問題は、標準が移動ターゲットであるということです。 1 つのプラットフォーム エンジニアリング実務者が述べたように、
困難には、標準化が含まれます... と 'abandonware' を処理しています... 自動化されたプロセスが中断する可能性があり、必要な変更を特定する時間のかかるタスクにより、標準化が実現されないことが多くあります。 - 大規模な物流会社の DevOps エンジニア、Martin
この引用が強調するように、新しい標準または更新された標準に迅速に切り替えることは通常は不可能であり、既存のプロセスを破棄するとリスクが生じます。 organizationは、既に複数の DevOps スイートを使用しているか、シナリオ別に個々のツールと開発者サービスの異なる組み合わせを使用している可能性があります。 中央のチームと標準的なソリューションであっても、セルフサービスのニーズが高まるにつれて、変動は避けられません。 そのため、指定されたチームが新しいテクノロジやデプロイ戦略などを試し、その後に意図的な導入と段階的なロールアウトを試す、制御された実験を有効にする必要があります。
一般的にセルフサービス エクスペリエンスは、次の 2 つの主要なカテゴリに分類されます。
- Automation
- データ集計
データ集計は優れたユーザー エクスペリエンスを生み出しますが、1 人のプラットフォーム エンジニアリング担当者が次のように設定します。
自動化は重要であり、すべての人に愛されます。 [データ] 集計はセカンダリです。 – Peter、プラットフォーム エンジニアリング リーダー、多国籍技術会社
このため、グラフ化したプラットフォーム エンジニアリングの 過程 で、自動化によって解決できるいくつかの問題が特定された可能性があります。 自動化は、コグニティブな負荷と開発者の負担を軽減するだけでなく、運用、セキュリティ、およびその他の役割に最適なツールとサービスにアプリケーションを確実に接続するのにも役立ちます。
ただし、自動化を推進するために複数のシステムを使用している場合は、自動化された要求と関連する結果を追跡するのに役立つデータ集計のレベルが役立ちます。 多くの場合、外部システムにリンクして他のニーズを満たしたり、詳細をドリルインしたりすることから始めることができます。 データの集計と可視性は、監査、ガバナンス、廃棄物の削減にも重要です (例: 未使用の環境)。
インフラストラクチャのプロビジョニングなどの自動化は、システム統合を使用して行うことができますが、開発者が自動化しているように見える手動ワークフロー プロセスをトリガーして容易にすることもできます。 これは、プラットフォームの初期段階、エコシステムに取り込む新しい製品、またはシステムの使用を自動化していない、または自動化できない領域 (ソフトウェア ライセンスの割り当てなど) で役立ちます。 適切な設計を使用すると、時間の経過と共に完全に自動化されたフローに切り替える Power Automate などの手動プロセスから始めることができます。 そのため、最初から自動化を設計します。
製品の考え方と 、最も薄い実行可能なプラットフォーム (TVP) ( プラットフォームの MVP ) の考え方を考えると、まず、エンジニアリング システムや内部ポータルなどの既存の投資を再利用し、CLI、基本的な Web ページ、さらには Power Pages、 Power BI、 または Microsoft Fabric ダッシュボードを作成し、必要に応じて拡張することから始める必要があります。 その点を念頭に置いて、UX が使用する一貫性のある API を使用すると、ニーズや設定の変化に応じて、時間の経過と共に複数のインターフェイスをサポートするのに役立ちます。
概念の概要
次の図を考えてみましょう。
図に示すように、次のコンポーネントは、開発者向けセルフサービス基盤の概念の中核をなしています。
| コンポーネント | 説明 |
|---|---|
| 開発者プラットフォーム API | これは、ユーザー エクスペリエンスの単一の連絡先です。 これは、実質的に他のシステムとのシステムの契約です。 |
| 開発者プラットフォーム グラフ | さまざまな種類のエンティティとテンプレートを検出、関連付け、使用できる、マネージドで安全なデータ グラフ。 エンティティは、複数のソースからのデータ集計を有効にするオブジェクトであり、テンプレートは自動化を可能にするユーザー入力を駆動します。 |
| 開発者プラットフォーム オーケストレーター | テンプレートベースの要求をルーティングして追跡し、システム内または手動プロセスでアクションを実行する機能。 これらの要求は、任意の数の異なるワークフロー システムやその他のサービスに統合できる一連の開発者プラットフォーム プロバイダーのいずれかにルーティングされます。 |
| 開発者プラットフォーム プロバイダー | エンティティに対する CRUD 操作やテンプレート ベースのアクション要求のフルフィルメントをサポートするためにダウンストリーム システムと統合するために必要なロジックをカプセル化する一連のコンポーネント。 各プロバイダーは、独自の特定の種類のテンプレートをサポートし、一意または一般的な種類のエンティティを出力できます。 |
| ユーザー プロファイルとチーム メタデータ | 開発者プラットフォーム API をグループ化してアクセスするために、概念チームに関連付けられている一連の個人に関する情報を保持する機能。 ユーザーは ID プロバイダー アカウント (サインインMicrosoft Entra IDなど) に密接に関連付けられていますが、それとチームの両方が、関連する任意の数のダウンストリーム システム表現に結び付けることができます。 このインフォメーション ストアの実装の 1 つは、開発者プラットフォーム グラフを再利用することです。 開発者セルフサービス基盤は、ユーザーとチームの両方に共通のエンティティ型を確立し、その情報をグラフに保持できます。 ただし、ここではわかりやすくするために、このストアを個別に保持します。 |
これらの基本コンポーネントを使用すると、時間の経過と同時にさまざまな構成要素を使用してスワップアウトできます。 これらの各詳細については、以降のセクションで詳しく説明します。
作業を開始するには、このすべてをビルドする必要がありますか?
いいえ。 まず、これは、このような基盤が完了したら何ができるかを考えるのに役立つ概念モデルです。 2 つ目は、開発者プラットフォーム API が重要なインターフェイスになることを考えると、実装の詳細はあまり重要ではありません。 最初の実装では、他の製品で記述または混在しているさまざまなレイヤーに対して、コード内のインターフェイスとクラスを使用し始める場合があります。 また、顧客の開発では、それが単に優先順位が低いことを伝えるので、側面を省略することもできます。 自分が持っているものから始め、成長してください。
そのことを念頭に置いて、各部分をより深く掘り下げてみましょう。
開発者プラットフォーム API
システムのコントラクトとして機能する開発者プラットフォーム API を定義する必要があります。 API は、データ アクセスやドライブのプロビジョニングやその他のアクションを有効にするために、さまざまなユーザー インターフェイスで使用されます。
この API は、他のシステムの生の基になる API へのアクセスをより具体的で制御されたデータと操作に制限することで、重要な認証とセキュリティ層としても機能する必要があります。 API は、ユーザー プロファイルの独自の表現、プラットフォーム内のユーザーの高レベルロール (チーム メンバー、管理者など)、プライマリ ID プロバイダーのシステム識別子へのアクセスを提供します。 詳細については、「 ユーザーとチーム」を参照してください。
開発者プラットフォーム プロバイダー
内部開発者プラットフォームの幅が広い場合は、拡張可能なプロバイダー モデルに従って API に機能を導入するシステムを作成または検索することをお勧めします。 オートメーションやデータ集計などの主要な機能は、適切に定義されたインターフェイスを使用してプラグ可能なコンポーネントと対話することによって提供されるという考え方です。 この緩い結合は、必要なものを段階的に結び付け、基盤の残りの部分から独立して機能をテストできるため、保守性を向上させます。
また、プラットフォームに対してスケーラブルな 内部ソース のメンタリティを有効にする重要な方法でもあります。 通常、プラットフォーム エンジニアリングに関する内部ソーシング作業は、継続的なメンテナンスの課題により牽引力を得ることはできません。 他のチームは機能を提供する意思があるかもしれませんが、プラットフォームのコア内で何かを維持してテストする意思は低くなります。 逆に、一元化されたチームは、投稿されたコードを維持したり、pull request をレビューしたりするための容量が限られています。 開発者プラットフォーム プロバイダーの概念は、開発者のセルフサービス 基盤内のコア機能に個別に記述されたコードを "プラグイン" できるようにすることで、この緊張を軽減します。 どのプロバイダーを使用するかを慎重に管理し、プロバイダー コードを確認し、特定のプロバイダーが開発者プラットフォームでアクセスできる領域を制限する必要がありますが、プラグ可能なアプローチは、organizationのより広い部分にわたって作業をスケーリングすることで、より多くの作業を行うのに役立ちます。
開発者プラットフォーム プロバイダーの主要な概念
エンティティ
エンティティの概念は、内部開発者プラットフォームの開発者または他のシステムが追跡、更新、提示、または操作を行う必要があるものです。 エンティティは相互にリレーションシップを持つことができます。このリレーションシップを組み合わせると、内部開発者プラットフォームの一部に関する重要な情報を提供する グラフ を構成できます。 その後、開発者プラットフォーム プロバイダーはエンティティを出力して、次のようなコア機能を有効にすることができます。
- 外部でプロビジョニングされたリソース/環境、または検出と使用に使用できる API の表示
- 依存関係分析、影響分析、検出などのリレーションシップを公開する。
- 探索とコラボレーションのための保守管理者/所有権情報の表示
- ユーザー エクスペリエンスで使用するためにより多くのデータを表示する
この機能を明確に定義された開発者プラットフォーム プロバイダー インターフェイスにカプセル化すると、統合とテストが簡素化され、独立したデプロイが可能になり、プライマリ内部開発者プラットフォーム チーム外の開発者がプロバイダーに貢献および管理できるようになります。 これは、すべてのツール、サービス、またはプラットフォームが一元的に管理されているわけではありませんが、より広範なorganizationがまだ機能を共有したいと考える大規模または部門の組織で重要です。 そのため、最初にこの道を進まない場合でも、長期的に考える必要があります。
共通のプロパティ
各エンティティには、Foundation で管理できるようにするための共通プロパティのセットが必要です。 考慮すべきプロパティには、次のようなものがあります。
- 一意識別子
- 名前
- 発信元プロバイダー
- オプションの関連付け:
- 所有ユーザー
- 所有チーム
- その他のエンティティ
ユーザーとチームのプロパティは、ロールベースのアクセス制御 (RBAC)、検出、データ集計 (チーム レベルの概要など) の 3 つの理由で重要です。 最初から RBAC で構築することは、セキュリティにとって重要であり、時間の経過と同時に内部開発者プラットフォームを成長させます。 開発がチーム スポーツである場合、エンティティについて話すユーザーを見つけ出すと、再利用、サポート、内部リソース作成にとってすぐに重要になります。
共通エンティティとプロバイダー固有のエンティティ
また、複数のプロバイダーが出力できる一般的な高レベルの正規化されたエンティティのセットを確立することもできます。 次に例を示します。
- 環境
- リソース
- API
- リポジトリ
- コンポーネント
- ツール
これらは通常、C4 モデル コンテキスト または最も高いレベルの コンポーネント 図に配置する場合と同様に、高レベルである必要があります。 たとえば、環境の場合、内部インフラストラクチャの地形の詳細を含める必要はありません。同じ UX 内の複数のプロバイダーから異なる概念環境を一覧表示して関連付けるのに十分な情報が必要です。 エンティティは、すべてを使用しようとするのではなく、システム外のより低い詳細レベルを指すことができます。 これらは、時間の経過と同時にデータ集計を有効にするための中心となる検出の開始点を提供します。
他のユーザーは特定のユース ケースまたはプロバイダーに固有であるため、徐々に増加する一連のエンティティ型に対応する方法について考える必要があります。
テンプレート
このコンテキストでのテンプレートの概念は、アクションを実行することを意図しているエンティティの概念とは異なります。 シナリオの例としては、インフラストラクチャのプロビジョニング、リポジトリの作成、その他の実行時間の長いプロセスがあります。 これらのテンプレートは、拡張可能な開発者プラットフォーム プロバイダーでも使用でき、エンティティの関連付けを含め、エンティティと同じ共通プロパティをサポートする必要があります。
ただし、システムまたはユーザーが指定したかどうかに関係なく、アクションを実行するために必要な入力を定義することもできます。 これらは、リソースに名前を付けるなどのものから、オプションの追加まで多岐に分けることができます。
テンプレートの例を次に示します。
- コードとしてのインフラストラクチャ (IaC) テンプレート
- アプリケーション テンプレート (Start Right) またはテンプレート リポジトリ
- パイプライン/ワークフロー テンプレートをビルドする
- デプロイ パイプライン/ワークフロー テンプレート
- パラメーター化されたスクリプト
- パラメーター化された Power Automate フロー (例: HTTP 要求によってトリガーされるクラウド フロー)
- Email templates
エンティティと同様に、テンプレートにはプロバイダー固有のプロパティを含めることができます。
各テンプレートには、プロバイダーに固有の表現が異なる場合があります。 これらは、Terraform または ARM テンプレートから、Helm チャート、パラメーター化されたGitHub Actionsワークフロー、Azure Pipelines、単純なスクリプト、またはカスタム形式まで多岐に渡ります。
実際の基になるテンプレートの詳細は、必ずしも一元的に格納する必要はありません。 これらは、異なるリポジトリ、レジストリ、またはカタログに存在する可能性があります。 たとえば、アプリケーション テンプレートには GitHub テンプレート リポジトリ を使用できますが、IaC テンプレートは制限付きカタログ リポジトリに存在する可能性があり、開発者は Azure Deployment Environments のようなものを介してのみ間接的にアクセスできます。 その他の IaC テンプレートは、Helm チャートなどの OCI Artifact Registry に格納される場合があります。 それ以外の場合、テンプレートはパラメーター化された HTTP エンドポイントへの参照である可能性があります。 開発者プラットフォーム プロバイダーは、参照できるように各種類のテンプレートに関する十分な情報と、ユーザー エクスペリエンスで使用するために公開されるオプションを提供する必要があります。 ただし、テンプレート自体は、ユース ケースにとって最も自然な場所に格納できます。
特定の領域のプラットフォーム エンジニアまたは専門家がこれらのテンプレートを記述し、再利用のために開発チームと共有します。 システムを介してこれらのテンプレートの使用を一元化すると、開発者のセルフサービスが可能になり、組織の標準またはポリシーへの準拠を強制するのに役立つガードレールが作成されます。 これについては、開発者プラットフォーム オーケストレーターについて少し説明します。
開発者プラットフォーム グラフ
開発者プラットフォーム グラフは、複数のプロバイダーのエンティティとテンプレートを検索可能なグラフに関連付けることができるものとして考えることができます。 ただし、エンティティの実際のデータをグラフ固有のデータベースに直接永続化する必要はありません。 代わりに、プロバイダーとの対話を必要なメタデータと共にキャッシュして、すべてを一緒に収めることができました。
グラフは、複数のプロバイダーが貢献できる一般的なエンティティと共に使用すると強力です。 たとえば、API の一覧は Azure API Center などの製品から取得される場合がありますが、継続的デプロイ システムからデプロイと環境を自動的にフィードすることもできます。 時間の経過と同時に、異なるデプロイ システムを切り替えたり、複数のデプロイ システムをサポートしたりすることもできます。 各デプロイ システムに開発者プラットフォーム プロバイダーがある限り、関連付けを行うことができます。
このグラフから構築された各ユーザー エクスペリエンスは、一般的な API を利用して、検出、検索、ガバナンスなどを強化できます。 開発者プラットフォーム オーケストレーターは、この同じグラフを利用して、開発者プラットフォーム プロバイダーによって実行されたすべてのアクションが、同じ API で使用できるエンティティを自動的に提供できるようにします。
開発者プラットフォーム オーケストレーター
開発者プラットフォーム オーケストレーターを使用すると、開発者またはシステムはテンプレートを使用してアクションを実行する要求を作成できます。 これらのアクション自体は実行されませんが、代わりにタスク エンジン、ワークフロー エンジン、または別のオーケストレーターと連携して調整します。 これは、セルフサービス基盤の一部であることを確認する重要な要素の 1 つです。 これにより、開発者はテンプレートを使用して要求を作成したり、直接のアクセス許可なしでアクションを実行したりできます。 さらに、CI または CD の概念とは異なり、これらのアクションはアプリケーションのソース コードに関連している必要はありません。
「ソフトウェア エンジニアリング システムを適用する」で説明されているように、オーケストレーターとして GitHub Actions、Azure Pipelines、または別のワークフロー エンジンを使用できます。 これは適切な開始場所ですが、さまざまな種類のテンプレートで異なる基になるエンジンを使用できるように、少し抽象化した方が良い場合があります。 これは、いくつかの理由で役立ちます。
- まず、 フラッシュ カットを必要とせずに、時間の経過と同時にさまざまなワークフローとタスク実行エンジンを選択できるようにする必要があります。 複数のエンジンを許可することで、古いエンジンに影響を与えることなく、時間の経過と同時に、または単に新しいエンジンを使用して新しいアクションに移行できます。
- 調整に役立つ一部のプロセスでは、後で完全に自動化する予定であっても、最初は手動の手順が必要になる場合があります。
- その他のアクションでは、買掛金勘定やライセンス管理者など、開発チーム外のロールをターゲットにしている可能性があります。Power Automate のようなローコード エンジンは、多くの場合、これらの役割に適しています。
- その他のアクションは、GitHub ActionsやAzure Pipelines と同じくらいの能力を持つものをスピンアップする必要がない、またはスケーリングにコスト効率が高くない単純な HTTP 要求によって処理される場合があります。
幸いなことに、開発者プラットフォーム プロバイダーのアイデアを拡張して、自動化のトリガーと追跡の手順をカバーすることで、この必要な抽象化を実現できます。 次の図を考えてみましょう。
一般的な概念を次に示します。
- テンプレートでは、必要に応じて、ユーザーが入力できる入力のセットを指定できます。 開発者が特定のアクションをトリガーすると、(そのように記述されていない場合でも) テンプレートを選択し、入力を入力します。
- テンプレート関連の入力への参照は、開発者プラットフォーム 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 ドキュメント)。
- 実行中に、開発者プラットフォーム プロバイダーはワークフロー/パイプラインの状態をwatchし、完了するまでオーケストレーターのライフサイクルの状態を更新できます。 たとえば、Azure Pipelines でGitHub Actionsとサービス フックを含む Web フックを使用して、更新プログラムを追跡できます。
- 完了すると、プロバイダーは発行された成果物を使用して、必要に応じて開発者プラットフォーム グラフに含めることができます。
最後に、この開発者プラットフォーム プロバイダーを設定して、特定のタスクの入力と共に、適切なリポジトリとワークフロー/パイプラインを参照する一連のテンプレートを開発者プラットフォーム グラフに出力できます。
CI/CD システムを使用する場合の優れた点は、任意の CLI の実行をサポートするように設定されることが多いため、すべての作業に対して一流の独自の統合は必要ありません。 必要に応じて、時間の経過と同時に追加できます。
この例で説明する内容の多くは、他の種類のプロバイダーがどのように機能するかを適用します。 また、このコンテキストで GitHub Actions または Azure Pipelines を使用する場合、実際の CI/CD パイプラインにも使用する必要はありません。
その他の例
テンプレートを処理できるその他の種類の開発者プラットフォーム プロバイダーの例を次に示します。
| 例 | 説明 |
|---|---|
| ソース管理操作 | 場合によっては、リポジトリの作成または更新、PR の送信、または他のソース管理関連の操作の実行が必要になる場合があります。 一般的な非同期ワークフロー エンジンでは、このような操作を管理できますが、基本的な Git 操作を 1 つなしで実行できると便利です。 |
| インフラストラクチャ のプロビジョニング | GitHub Actionsと Azure Pipelines はインフラストラクチャ プロビジョニングの管理に適していますが、より直接的な統合を選択することもできます。 専用プロバイダーは、セットアップを効率化し、オーバーヘッドを回避できます。 Azure デプロイ環境や Terraform Cloud などのサービスは、IaC テンプレートベースのプロビジョニングを安全かつ安全に有効にすることにより直接的に焦点を当てています。 その他の例としては、共有クラスター内のアプリケーション用の Kubernetes 名前空間の作成や、 Flux または Argo CD を特定の種類のプロバイダーとして使用する GitOps ワークフローでの git の使用などがあります。 独自の CLI を使用した実験的な Radius OSS インキュベーション プロジェクトのようなアプリ中心のモデルは、時間の経過と共に独自の開発者プラットフォーム プロバイダーを持つ可能性があります。 重要なことは、適応できるように拡張性を探して計画することです。 |
| アプリケーションスキャフォールディング/シード処理 | アプリケーション テンプレートは、プラットフォーム エンジニアリングが時間の経過と同時にリードする重要な部分です。 選択したテンプレート エンジンをサポートするには、アプリケーション ソース ツリーをスキャフォールディングするだけでなく、コンテンツを作成してソース コード リポジトリにプッシュし、結果のエンティティをグラフに追加するように設計された専用の開発者プラットフォーム プロバイダーを提供します。 すべてのエコシステムには、Yeoman、cookiecutter、またはAzure Developer CLIのようなものに関係なく、独自のアプリケーション スキャフォールディングの優先順位があるため、ここでのプロバイダー モデルを使用すると、同じインターフェイスから複数のものをサポートできます。 ここでも、重要なのは拡張性です。 |
| 手動プロセス | 手動承認用の PR を自動的に生成する場合も、開発者以外のペルソナが Power Platform のようなものを使用して応答するための手動ワークフロー ステップの場合でも、開発者プラットフォーム プロバイダーでも同じテンプレート ベースのモデルを使用できます。 時間の経過と同時に、より自動化された手順に移行することもできます。 |
これらのプロバイダーをすべて開始する必要はないかもしれませんが、開発者プラットフォーム プロバイダーなどの機能拡張が、時間の経過と同時に自動化機能の成長にどのように役立つかを確認できます。
ユーザーとチーム
プラットフォーム エンジニアリングは本質的にマルチシステムの問題であるため、セルフサービス基盤でこれらのシステムを統合する際に、より困難な問題にどのように対処するかを計画することが重要です。 このセクションでは、ID、ユーザー、チームで一般的な課題に取り組むための戦略について説明します。
まず、次の 2 つの推奨事項を検討します。
| 推奨 | 説明 |
|---|---|
| 最適なセキュリティのために開発者プラットフォーム 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) としてチームを使用している場合、開発者プラットフォーム プロバイダーはリポジトリ内のファイル変更をwatchし、ユーザー プロファイルとチーム メタデータ ストアにキャッシュできます。 または、これらのコア 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/one-time-use コードが含まれます。
- その後、API は URI を使用して "認証されていない" 応答を返します。
- その後、どの UX でもこの URI を使用して、ブラウザーで適切な認証フローを推進できます。
- リダイレクトが行われると、開発者プラットフォームは必要なユーザー トークンを受け取り、ユーザー ID と共に将来参照できるようにキャッシュします。
- その後、クライアントは API 呼び出しを再試行できます。この呼び出しは成功します。
この概念では、可能な限り ID を再利用できるため、複雑な認証に対処する方法について説明します。ダウンストリーム システムごとに個別のリダイレクト URI を維持する必要はありません。
データの集計と追加機能の提供
ツールとレポート システムへのコンテキスト対応のディープ リンクを使用する
ここまでは、問題領域の自動化の側面について説明してきました。 UI でオートメーション中に返されたエンティティの値を使用してチームの他のシステムへのディープ リンクを作成できるため、これだけでは長い道のりを行くことができます。
自動化に関連しない場合でも、開発者プラットフォーム プロバイダーはあらゆる種類のエンティティニーズを出力できます。 ただし、一般に、内部開発者プラットフォーム全体のすべての詳細データを開発者プラットフォーム グラフに取り込む必要はありません。 SonarQube などの製品の Grafana、Prometheus、DataDog、コード インテリジェンスなどの監視ソリューションのダッシュボードと、GitHub や Azure DevOps などの DevOps スイートのネイティブ機能はすべて非常に優れた機能です。 代わりに、多くの場合、これらの他のシステムへのディープ リンクを作成することをお勧めします。 エンティティは、ログの内容などの詳細情報を直接含めることなく、リンクを作成するのに十分な情報を提供できます。
ツール全体で集計および集計されたデータが必要な場合や、カスタム メトリックを推進する必要がある場合は、 レポート ソリューション Power BI または Microsoft Fabric を次の呼び出しポートにすることができます。 チーム データをマージするには、Foundation のデータベースに接続するか、開発者プラットフォーム API を使用します。 たとえば、「 計画と優先順位付け」で説明されているように、カスタム ダッシュボードが必要な場所の 1 つは、内部開発者プラットフォームの成功を測定することです。
ビルドする追加のエクスペリエンスごとに選択する
共通のポータルのようなもので既存の機能を再作成することは魅力的ですが、それを維持する必要もある点に注意してください。 これは、製品マインドセットをフォローすることが重要な領域です。 ダッシュボードスタイルのインターフェイスは簡単に想像して理解できますが、開発者は他の場所でより多くの価値を見つける可能性があります。
つまり、ここでのモデルでは、開発者プラットフォーム グラフの集計データを使用して、カスタム ユーザー エクスペリエンスを作成できます。 エンティティは、ユーザーまたはチームと結び付けることができるように、組み込みのサポートを持っている必要があります。 これにより、開発者プラットフォーム API は、(インデックス作成とキャッシュを使用して) 出力のスコープを設定できます。
ただし、ディープ リンクではなくカスタム UX を作成する必要がある場合でも、すべてのデータを開発者プラットフォーム グラフにプルすることは、通常、最適なアプローチではありません。 たとえば、適切に定義されたマネージド ホームが既にある UX にログを表示する場合があるとします。 関連エンティティの情報を使用して、UX がダウンストリーム システムから直接情報を収集できるようにします。
まず、システム間統合を使用して接続する必要があるかもしれませんが、 ユーザーとチームで説明されているモデルの 1 つを実装したら、必要に応じて、格納されているダウンストリームユーザー/チーム ID またはユーザー認証トークンを使用できます。
考慮すべき一般的なエクスペリエンスの例を次に示します。
| 例 | 説明 |
|---|---|
| 検出と探索 | あるプラットフォーム エンジニアリングの実務者が言うとおり、"プロジェクトの速度が低下するのは、開発者のスキルではなくコミュニケーションです。" –Daniel、Cloud Engineer、Fortune 500 Media Company。 ソフトウェアはチーム スポーツであるため、チームの検出に役立つユーザー インターフェイスを作成し、自分が所有するエンティティは、通常、最初に取り組むことの 1 つです。 チーム間の検索、検出、ドキュメントは、再利用を促進し、内部ソーシングやサポートのためのコラボレーションを支援します。 Teams には、環境、リポジトリ、ドキュメントなどのその他のリソースを含む所有物を見つけるためのワンストップ ショップがあることもメリットがあります。 |
| 環境またはリソースの手動登録 | 開発者プラットフォーム オーケストレーターを使用して多くのことをプロビジョニングおよび追跡できますが、既に存在するか、まだ自動化されていないリソースまたは環境を登録することもできます。 Git リポジトリから情報を取得し、リソース/環境管理に情報を追加する単純なプロバイダーは、ここで役立ちます。 既にソフトウェア カタログがある場合、これはモデルに統合する方法にもなります。 |
| API カタログ | 開発者が使用する必要がある API の追跡は、長い道のりを行くことができます。 まだ何も持っていない場合は、API とその状態を表す一連のファイルを含む単純な Git リポジトリから始めて、PR を使用して承認ワークフローを管理することもできます。 これらは開発者プラットフォーム グラフに追加して、表示したり、他のエンティティに関連付けたりすることができます。 より堅牢な機能を実現するために、 Microsoft の API センター や別の製品などを統合できます。 |
| ライセンス コンプライアンス | 場合によっては、ソフトウェア ライセンスのコンプライアンスとシートの使用量を可視化することもできます。 開発者プラットフォームでは、シートを使用するために必要な自動化を追加することもできますが、シートが手動で割り当てられている場合でも (たとえば、Git リポジトリの PR プロセスを介して)、開発者は自分の持っているもの (およびすべての全体を見る管理者の能力) を可視化します。 |
| Kubernetes のアプリケーション中心のビュー | 共有 Kubernetes クラスターを使用する場合、開発者がクラスター管理者 UX を使用してアプリケーションの状態を見つけて理解することが困難になる場合があります。 この問題の処理方法は組織によって異なりますが、名前空間を使用してアプリケーションを表す方法は、よく知られている方法の 1 つです。 そこから、エンティティを使用して、クラスター内のアプリケーションの名前空間とチームの間の関連付けを確立し、アプリケーションの状態をより開発者に焦点を当てたビューを作成し、他のツールや Web UI へのディープ リンクを提供できます。 |
ユーザー エクスペリエンス
organizationのさまざまな役割には、日常業務の重心を表すツールやサービスがあります。 これらのシステムを引っ張ると、これらの重心外の新しいユーザー エクスペリエンスが牽引力を得るのが困難になる可能性があります。 完璧な世界では、開発者、運用、その他の役割は、既に使用している環境 (多くの場合) で引き続き機能します。
これを念頭に置いて、プラットフォーム エンジニアリングの取り組みを進めるにつれて、複数のユーザー インターフェイスを計画することをお勧めします。 また、これにより、単純な作業を開始し、価値を証明し、必要に応じてより複雑なインターフェイスに成長する機会が得られます。
持っているものを統合する
「ソフトウェア エンジニアリング システムの適用」と「アプリケーション プラットフォームの絞り込み」の記事を読んだ場合は、引き続き使用するシステムを特定した可能性があります。 どちらの場合も、新しいエクスペリエンスをゼロから構築する前に、自分が持っているものを拡張して拡張できるかどうかを評価します。 (自分に尋ねると、人々は別の新しいユーザーエクスペリエンスや改善されたバージョンの今のものに対してより良い反応をしますか?
引き続き使用するツール、ユーティリティ、または 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 などのシステムがすぐにサポートされている場合、これは、別のユーザー インターフェイス開発者や、毎日使用される関連する運用ロールと統合する自然な方法です。 さらに、これらの製品はすべて拡張性モデルを備えています。
新しい開発者ポータルへの投資
ベースとして使用する既存のポータルまたはインターフェイスがない場合は、新しい開発者ポータルを構築する場合があります。 これは出発点ではなく、目的地と考えてください。 開発チームがまだ作業していない場合は、この作業を開始する必要があります。 すべてのorganizationは異なるため、この種のエクスペリエンスに何が必要かについての 1 つのサイズに適合する答えはありません。 その結果、現在このようなものに対して起動してそのまま使用できる、パッケージ化された製品に対するデファクトの答えはありません。
カスタムビルドのセルフホステッド オプションの場合、一般的な Web ポータル フレームワークは新しくはありません。開発チームは、既に利用できるオプションを使用している可能性があります。 早期のフィードバックのためにユーザーの前で何かを得ようとしている場合は、一般的な開発者プラットフォーム API に接続するためのローコード Power Pages と同じくらい簡単なものから始めることもできます。
最近の開発者ポータルの取り組みは、より多くの意見を持っています。 たとえば、 Backstage.io は、Spotifyのニーズを満たすために最初に構築されたカスタム開発者ポータルツールキットです。 これには、create-react-app が React.js に対して行うのと同様に、ソース ツリーをブートストラップするのに役立つ CLI が含まれています。
ポータル ツールキットでは、作業を開始する必要があり、カスタマイズには TypeScript、Node.js、Reactに関する知識が必要です。 しかし、それについての素晴らしい点は、ツールキットとして、ほぼすべてのものを変更できることです。 独自のソフトウェア カタログとテンプレート メカニズムも備えていますが、その使用は必要なく、プラグインと呼ばれる新しい 1st および 3rd パーティ コードを取り込むための明確に定義された方法があります。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示