翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

内部開発者プラットフォームを構築する原則

製品の考え方を採用する

成功の主な原則は、内部開発者プラットフォームを通常のアプリケーションまたは一連の機能とロードマップを持つ製品として扱うことです。これにより、内部開発者プラットフォームが提供する一連のツールとプロセスを定義できます。また、ソフトウェア配信サイクルの改善や運用インシデントの数の削減など、プラットフォーム機能の導入の成功を測定する方法を特定するのに役立ちます。製品マインドセットを採用することで、内部開発者プラットフォームが提供する価値を定量化し、それが元の目標を達成していることを確認することができます。

顧客に焦点を当てる

もう 1 つの重要な原則は、内部開発者プラットフォームの顧客を特定することです。基本的に、顧客は開発者です。プラットフォームの目標はデベロッパーのニーズを満たし、そのニーズを満たしていることであるため、顧客を理解することは非常に重要です。つまり、プラットフォームロードマップを調整する必要があります。開発者が必要とするものに基づいて機能に優先順位を付けます。

セルフサービス機能をオンデマンドで自動的に提供する

もう 1 つの成功の原則は、プラットフォームがセルフサービスメカニズムを通じて機能を提供することで、開発者から複雑さを隠す必要があることです。チームがクラウドプロバイダーを使用しているか、Amazon Elastic Kubernetes Service (Amazon EKS) などのコンピューティングサービスを使用しているかにかかわらず、開発者はこれらの詳細を気にしないでください。内部デベロッパープラットフォームは、グラフィカルユーザーインターフェイス (GUI)、API、またはデベロッパーが価値を提供するのに役立つコマンドラインインターフェイス (CLI) などのシンプルなインターフェイスを提供する必要があります。セルフサービスメカニズムを成功させるには、適切なテンプレート設計から始めることが重要です。テンプレートには、機能配信を自動化するために必要な最小パラメータが含まれている必要があります。開発者が品質ゲートとセキュリティ要件を満たすのに役立つテストプロセスを自動化し、機能のデプロイ後に主要なメトリクスに関するフィードバックを提供する必要があります。

セルフサービスメカニズムは、開発者の認知負荷を軽減するのに役立ちます。これにより、デベロッパーが本番環境へのデプロイに使用する必要があるサービスとツールの数が減少します。ユーザーエクスペリエンスを簡素化することで、より多くのチームにプラットフォームをマーケティングできます。開発者が使用したい場合は常に、内部開発者プラットフォームをオンデマンドで利用できるようにすることが重要です。次に、より多くのチームをオンボーディングする際に、内部開発者プラットフォームをスケールする準備をする必要があります。

オプションを使用し、特定の機能の使用を有効にする

すべてのチームが最初の日に内部開発者プラットフォームを使用できるわけではありません。たとえば、コンテナを使用してワークロードをモダナイズしているチームもあれば、サーバーレスソリューションを使用しているチームもあります。内部開発者プラットフォームは 1 つのジャーニーをサポートすることから始まり、時間の経過とともにさらに多くの機能が開発されます。プラットフォームがスケーリングされ、より成熟したパターンがデベロッパーに提供する準備ができるまで、プラットフォームとその機能をオプションで使用します。

これは、チームが内部開発者プラットフォームを使用できないことを意味するわけではありません。一部のチームは、引き続きツールとプロセスを管理し、内部開発者プラットフォームの特定機能を採用できます。たとえば、チームは CI/CD パイプラインを採用してインフラストラクチャの準備を整えることができます。プラットフォームは、インフラストラクチャの管理にかかる時間を短縮することで価値を提供し、開発者がアプリケーションコードに集中できるようにします。

セキュリティ標準に沿ったゴールデンパスを定義する

ゴールデンパスは、内部開発者プラットフォームが提供するべき最も基本的な機能です。これは、ゴールデンパスには、開発者が数分で開始するのに役立つベストプラクティスと標準が含まれているためです。Golden パスは、開発からオブザーバビリティまで、ソフトウェア開発ライフサイクル (SDLC) エクスペリエンスを簡素化します。ソースコードリポジトリ、テスト、デプロイ、オブザーバビリティなど、開発者が使用する機能のほとんどを自動化します。

ただし、ゴールデンパスは自動パターンを提供することだけではありません。また、組織のコンプライアンス要件に従った安全な方法で開発者がワークロードをデプロイするためのガバナンスも提供します。開発者の主な課題の 1 つは、開発ライフサイクルの早い段階でセキュリティに対処することです。したがって、セキュリティスキャンツールと policy-as-code ツールをゴールデンパスのステージとして含めることで、この課題を削除することが重要です。これにより、開発者に早期フィードバックを提供し、デプロイ用のガバナンスフレームワークを提供できます。

ゴールデンパスを設計するときは、プロセスを不必要に難しくしないでください。目標は、SDLC のすべてのステージを最初に自動化することではありません。目標は、さまざまなツールやインフラストラクチャを使用する複雑さをすべて隠すことができる抽象化レイヤーを提供することです。これにより、デベロッパーは基盤となるサービスとやり取りするのではなく、すぐに開始し、機能開発に集中できます。ゴールデンパスの例は、開発者がソースコードリポジトリを指すいくつかのパラメータを提供できるテンプレートです。内部開発者プラットフォームは、テスト、セキュリティ、スキャン、デプロイなど、他のすべてのステージを自動化します。

オンボーディングエクスペリエンスを文書化して簡素化する

内部開発者プラットフォームの成功のもう 1 つの重要な原則はドキュメントです。内部開発者プラットフォームには、開発者にeasy-to-followオンボーディングガイドを提供するドキュメントを含める必要があります。このガイドでは、開発者がプロジェクトにどのように貢献できるかに焦点を当て、インターフェイスやプラットフォームの隠れた複雑さを説明するべきではありません。例えば、オンボーディングガイドでは、プラットフォームが Amazon EKS で実行されていることや、 AWS アカウント のベースライン設定方法を記述しないでください。このガイドでは、サービスの依存関係とゴールデンパスについて説明する必要があります。マイクロサービスアーキテクチャでは、サービスの接続方法を説明することもできます。

ドキュメントとシンプルなオンボーディングエクスペリエンスにより、開発者が内部開発者プラットフォームを理解して使用するために必要な時間が最小限に抑えられます。ドキュメントの効果を測定する場合は、コード変更ボリュームメトリクスが役立ちます。このメトリクスは、コード変更を最も多く行うユーザーと、時間の経過とともに最もアクティブになるリポジトリに関するデータを提供します。デベロッパーレベルまたはリポジトリレベルでデータを収集できます。