開発者のセルフサービスの向上は、 プラットフォーム エンジニアリング体験で最初に取り組む問題の 1 つである必要があります。
自動化されたセルフサービス エクスペリエンスの有効化を開始する最も簡単な方法の 1 つは、既存のエンジニアリング システムを再利用することです。 これらのシステムは、ユーザーや社内の顧客にとってなじみがあるだけでなく、初期のユーザー エクスペリエンスが適切でない場合でも、幅広い自動化シナリオを実現できます。
この記事では、エンジニアリング システムを活用して、より幅広いセルフサービス シナリオに対応する方法に関するヒントと、ベストプラクティスをテンプレートに組み込む方法について詳しく説明します。
DevOps と DevSecOps の基本プラクティスを評価する
エンジニアリング システムは、内部開発者プラットフォームの重要な側面です。 内部開発者プラットフォームは、DevOps と DevSecOps のメイン テナントから構築され、関係するすべてのユーザーのコグニティブな負荷を軽減します。
DevOps は、開発と運用を組み合わせて、アプリケーションの計画、開発、配信、運用において人、プロセス、テクノロジを統合します。 これは、開発、IT 運用、品質エンジニアリング、セキュリティなど、歴史的にサイロ化されたロール間のコラボレーションを改善することを目的としています。 開発、デプロイ、監視、観察、フィードバックの間に継続的なループを確立します。 DevSecOps は、アプリケーション開発プロセス全体を通じて継続的なセキュリティ プラクティスを使用して、このループにレイヤー化します。
次のセクションでは、プラットフォーム エンジニアリングの動きに直接起因する改善に焦点を当てます。舗装されたパス、自動化されたインフラストラクチャ プロビジョニング (アプリケーションのデプロイに加えて)、コーディング環境のセットアップ、およびアプリケーション開発ループに直接含まれないツール、チーム資産、サービスのセルフサービス プロビジョニングと構成。
望む舗装された道を作る
エンジニアリング システムを構成する複数のツール セットが既にある場合は、最初のプラットフォーム エンジニアリング作業の一環として統合するか、最初からさまざまなツールの集合をサポートするのかを早期に決定します。 このツールの星座内で一連の舗装されたパスを定義することが最も効果的であり、柔軟性のレベルが向上します。
製品の考え方に移行し始めると、これらの舗装されたパス内のエンジニアリング システムは、開発チームへのサービスとして一元的に管理されるツールで構成されていると考えてください。 組織内の個々のチームまたは部門は逸脱する可能性がありますが、コンプライアンス要件に準拠しながら、ツールを個別に管理、維持、および支払う必要があります。 これにより、時間の経過に伴って舗装されたパスに含まれる可能性のあるものを評価できるため、中断することなく新しいツールをエコシステムに供給する方法が提供されます。 プラットフォームエンジニアリングのリーダーの1人が言ったように、
あなたはまだ自分自身のことをすることができますが、それを私たちが進む方向に合わせて行うことができます。 必要なものは何でも変更できますが、これはあなたの責任になります。 あなたは変更を掌握しています - あなたは鋭いナイフを持っています。 - Mark、プラットフォーム エンジニアリング リーダー、ヨーロッパの大手多国籍小売企業
プラットフォーム エンジニアリングの主な目標は、社内の顧客に価値を提供する製品の考え方に移行することです。このコンステレーション アプローチは、通常、トップダウンの義務よりも優れています。 舗装されたパスを確立して調整する際に、ある程度の柔軟性を残すことにより、チームは、組織内の他のユーザーに影響を与えることなく、特定のアプリケーションに対して入力を提供し、本当に固有の要件に対処することができます。 これは完全に舗装されたゴールデンパスのセットにつながりますが、他のパスは部分的にしか舗装されません。 固有の要件がない場合、チームが引き受ける余分な作業開発によって、時間の経過と同時にサポートされているパスに移行する必要が生じるのは当然です。
統合戦略を希望する場合は、既存のアプリケーションを移行する方が予想以上の作業になる可能性があるため、まず、この領域の最初の適切な側面に焦点を当て、新しいプロジェクトに焦点を当てる必要があります。 これにより、最初の舗装されたパスが提供されますが、既存のすべてが本質的に未舗装です。 その後、未移行パスの開発チームは、新しい舗装されたパスがその価値を組織に示した後に移動することを検討できます。 その時点で、是正キャンペーンを実行し、双方向のコミュニケーションを通じてすべてのユーザーを望ましい状態にすることができます。開発チームがこれを税金ではなく利益として捉えているため、実現することが可能なのです。 このキャンペーン中、プラットフォーム エンジニアリング チームはチームの移行を支援することに集中できます。一方、開発チームは、舗装されたパスをより良くする方法に関するフィードバックを提供します。
関係なく、舗装された道の使用を義務付けないでください。 舗装されたパスをロールアウトする最も効果的な方法は、強制的な導入ではなく、チームがそれらから抜け出す内容を強調することです。 社内の開発者プラットフォームは、これらのまったく同じチームを幸せにすることに重点を置いているので、個々のリーダーに対する予算と価値への時間の圧力が残りの部分を処理します。 適切なキャンペーンを策定し、舗装されていない道を進む人々が切り替えるための最善策について双方向の会話を行うための場を提供します。
開発者の自動化ツールを使用して、舗装されたパスのセルフサービスを向上させる
最初の舗装されたパスを作成する一環として、開発者の主要な自動化製品を確立する必要があります。 これらは、開発者のセルフサービス機能を有効にすることを検討し始める際に重要です。
継続的デリバリー中にアプリケーション インフラストラクチャの自動プロビジョニングを有効にする
まだ実装されていない場合、計画中に特定した問題は、継続的インテグレーション (CI) と継続的デリバリー (CD) が解決に役立つ問題を示している可能性があります。 この領域には、 GitHub Actions、 Azure DevOps、 Jenkins などの製品と、 Flux や Argo CD などのプルベースの GitOps ソリューションが存在します。 これらのトピックは、 Microsoft DevOps リソース センターで開始できます。
既存のインフラストラクチャにアプリケーションを継続的にデプロイする方法を既に実装している場合でも、コード としてのインフラストラクチャ (IaC) を使用して、CD パイプラインの一部として必要なアプリケーション インフラストラクチャを作成または更新することを検討する必要があります。
たとえば、GitHub Actions を使用してインフラストラクチャを更新し、Azure Kubernetes Service にデプロイする 2 つの方法を示す次の図を考えてみましょう。1 つはプッシュベースのデプロイを使用し、1 つはプルベース (GitOps) デプロイを使用します。
選択する対象は、既存の IaC スキル セットとターゲット アプリケーション プラットフォームの詳細によって決まります。 GitOps アプローチは、より新しく、アプリケーションのベースとして Kubernetes を使用する組織の間で人気があります。一方、プルベースモデルでは現在、使用可能なオプションの数に応じて最も柔軟性が高くなります。 ほとんどの組織では、この 2 つの組み合わせを使用する必要があります。 IaC プラクティスに精通することは、さらに自動化シナリオに適用されるパターンを学習するのに役立ちます。
カタログまたはレジストリ内の IaC を一元化して、セキュリティをスケーリングおよび向上させる
アプリケーション間で IaC を管理およびスケーリングするには、再利用するために IaC 成果物を一元的に発行する必要があります。 たとえば、
IaC を一元化すると、アプリケーション コードで保存されなくなったため、更新できるユーザーをより適切に制御できるため、セキュリティが向上します。 エキスパート、運用、またはプラットフォーム エンジニアが必要な変更を行うときに、コードの更新中に不注意による変更が原因で誤って中断されるリスクが少なくなります。 開発者は、完全な IaC テンプレート自体を作成する必要がなく、エンコードされたベスト プラクティスの恩恵を自動的に受ける必要がないため、これらの構成要素のメリットも得られます。
どの IaC 形式を選択するかは、既存のスキル セット、必要な制御レベル、使用するアプリ モデルによって異なります。 たとえば、 Azure Container Apps (ACA) と最近の実験用 Radius OSS インキュベーション プロジェクトは、Kubernetes を直接使用するよりも意見が高くなりますが、開発者エクスペリエンスも合理化されます。 さまざまなモデルの長所と短所については、「 クラウド サービスの種類について説明する」を参照してください。 関係なく、ソース ツリーで完全な定義を持つよりも、一元化されたマネージド IaC を参照すると、大きな利点があります。
開発者がガバナンスのための基本的な構成要素のレイヤーに直接アクセスできない方法で、必要なプロビジョニング ID またはシークレットを保持します。 たとえば、 Azure デプロイ環境 (ADE) を使用して実現できるロールの分離に関するこの図を考えてみましょう。
ここでは、プラットフォーム エンジニアや他の専門家が IaC やその他のテンプレートを開発し、カタログに配置します。 その後、運用では、マネージド ID とサブスクリプションを 環境の種類 別に追加し、プロビジョニングに使用できる開発者やその他のユーザーを割り当てることができます。
その後、開発者または CI/CD パイプラインは 、Azure CLI または Azure Developer CLI を使用して、構成済みの制御されたインフラストラクチャをプロビジョニングできます。それに必要な基になるサブスクリプションや ID にアクセスする必要もありません。 ADE のようなものを使用するかどうかにかかわらず、選択した継続的デリバリー システムは、シークレットを分離し、開発者が自分でアクセスまたは変更できない場所から IaC コンテンツを調達することで、インフラストラクチャを安全かつ安全に更新するのに役立ちます。
アプリケーションの継続的デリバリー以外のシナリオでセルフサービスを有効にする
CI と CD の概念はアプリケーション開発に関連していますが、内部のお客様がプロビジョニングする必要のあるものの多くは、特定のアプリケーションと直接結びついていないものです。 これは、共有インフラストラクチャ、リポジトリの作成、プロビジョニング ツールなどです。
これが役立つ可能性がある場所を理解するには、現在、手動またはサービス デスク ベースのプロセスがある場所を検討してください。 それぞれについて、次の質問について考えます。
- このプロセスはどのくらいの頻度で行われますか?
- プロセスが遅い、エラーが発生しやすい、または達成するために重要な作業が必要ですか?
- これらのプロセスは、必要な承認手順または単に自動化がないために手動ですか?
- 承認者はソース管理システムとプル要求プロセスに精通していますか?
- プロセスの監査要件は何ですか? これらは、ソース管理システムの監査要件とは異なりますか?
- より複雑なプロセスに進む前に、リスクが低いプロセスから始めることができますか?
最初に自動化する可能性のあるターゲットとして、頻繁、高労力、またはエラーが発生しやすいプロセスを特定します。
すべてをコード パターンとして使用する
Git のユビキタスに加えて、Git の優れた点の 1 つは、安全で監査可能な情報ソースを意図していることです。 コミット履歴やアクセス制御以外にも、プル要求やブランチ保護などの概念は、メイン ブランチにマージする前に渡す必要がある特定のレビュー担当者、会話履歴、または自動チェックを確立する方法を提供します。 CI/CD システムに含まれるような柔軟なタスク エンジンと組み合わせると、セキュリティで保護された自動化フレームワークが得られます。
コードとしてのすべての背後にある考え方は、セキュリティで保護された Git リポジトリ内のファイルにほぼすべてのものを変換できることです。 リポジトリに接続されているさまざまなツールまたはエージェントがコンテンツを読み取ることができます。 すべてをコードとして扱うと、テンプレート化による再現性が向上し、開発者のセルフサービスが簡素化されます。 これをどのように機能させるか、いくつかの例を見てみましょう。
任意のインフラストラクチャに IaC パターンを適用する
IaC はアプリケーションの配信の自動化に役立つ人気を得ましたが、このパターンは、特定のアプリケーションに関連付けられているインフラストラクチャ、ツール、またはサービスだけでなく、プロビジョニングと構成が必要になる可能性があるあらゆるインフラストラクチャにまで及びます。 たとえば、Flux がインストールされた共有 Kubernetes クラスター、複数のチームやアプリケーションで使用される DataDog のようなもののプロビジョニング、お気に入りのコラボレーション ツールの設定などです。
この方法は、プロビジョニングと構成を表す一連のファイル (この場合は Bicep または Terraform から Helm チャートやその他の Kubernetes ネイティブ形式まで) を格納する、個別の セキュリティで保護された 一元化されたリポジトリを持つことです。 運用チームまたは他の一連の管理者がリポジトリを所有しており、開発者 (またはシステム) はプル要求 (PR) を送信できます。 これらの PR がこれらの管理者によってメイン ブランチにマージされると、アプリケーションの開発時に使用されるのと同じ CI/CD ツールを使用して変更を処理できます。 Azure デプロイ環境に格納されている GitHub Actions、IaC、デプロイ ID を示す次の図を考えてみましょう。
アプリケーションのデプロイに GitOps アプローチを既に使用している場合は、これらのツールも再利用できます。 Flux や Azure Service Operator などのツールを組み合わせることで、Kubernetes の外部で拡張できます。
いずれの場合も、生成されたものがアプリケーション用ではない場合でも、完全に管理され、再現可能で監査可能な情報源が得られる。 アプリケーション開発と同様に、必要なシークレットまたはマネージド ID は、パイプライン/ワークフロー エンジンまたはプロビジョニング サービスのネイティブ機能に格納されます。
PR を作成するユーザーはこれらのシークレットに直接アクセスできないため、開発者が自分で直接アクセス許可を持っていないアクションを安全に開始する方法を提供します。 これにより、開発者にセルフサービス オプションを提供しながら、最小限の特権の原則に従うことができます。
プロビジョニングされたインフラストラクチャを追跡する
このアプローチのスケーリングを開始したら、プロビジョニングされたインフラストラクチャを追跡する方法について考えてください。 Git リポジトリは構成の信頼できるソースですが、作成した内容に関する特定の URI と状態情報は示されません。 ただし、コードアプローチとしてすべてを実行すると、プロビジョニングされたインフラストラクチャのインベントリを合成するために利用できる情報のソースが提供されます。 プロビジョニング担当者は、この情報を活用できる適切なソースになる場合もあります。 たとえば、Azure デプロイ環境には、開発者が可視性を持つ環境追跡機能が含まれています。
さまざまなデータ ソース間での追跡の詳細については、「 開発者のセルフサービス基盤を設計する」を参照してください。
セキュリティをコードとして適用し、ポリシーをコード パターンとして適用する
プロビジョニング インフラストラクチャは便利ですが、これらの環境が安全であり、通常は組織のポリシーに従っていることを確認することが同様に重要です。 これが 、コード概念としてのポリシー の台頭につながりました。 ここでは、ソース管理リポジトリの構成ファイルを使用して、セキュリティ スキャンの推進やインフラストラクチャ ポリシーの適用などを行うことができます。
Azure Policy、Open Policy Agent、GitHub Advanced Security、GitHub CODEOWNERS など、多くの異なる製品とオープンソース プロジェクトでこのアプローチが採用されています。 アプリケーション インフラストラクチャ、サービス、またはツールを選択するときは、それらのパターンがどの程度サポートされているかを必ず評価してください。 アプリケーションとガバナンスの調整の詳細については、「 アプリケーション プラットフォームの調整」を参照してください。
独自のシナリオのコードとしてすべてを使用する
コードとしてのすべてが、これらのパターンを IaC 以外のさまざまな自動化および構成タスクに拡張します。 あらゆる種類のインフラストラクチャの作成や構成だけでなく、ダウンストリーム システムでのデータの更新やワークフローのトリガーもサポートできます。
PR は、特に作業を開始する際に、さまざまなプロセスに適したベースラインのセルフサービス ユーザー エクスペリエンスになります。 プロセスは、Git 自体が提供するセキュリティ、監査可能性、ロールバックの利点を自然に得ることができ、関係するシステムもユーザー エクスペリエンスに影響を与えずに時間の経過と同時に変化する可能性があります。
コードとしての Teams
すべてをコードとして独自のシナリオに適用する例の 1 つは、コード パターンとしてのチームです。 組織は、このパターンを適用して、チーム メンバーシップを標準化し、場合によっては、さまざまなシステムにわたって開発者ツール/サービスの権利を標準化します。 このパターンにより、システム開発者とオペレーターが独自のグループ化、ユーザー、およびアクセスの概念にアクセスする必要性によって駆動される、手動のオンボードおよびオフボード サービス デスク プロセスが不要になります。 手動のサービス デスク プロセスは、アクセスをオーバープロビジョニングする可能性があるため、潜在的なセキュリティ リスクです。 チームをコード パターンとして使用する場合、Git と PR の組み合わせにより、監査可能なデータ ソースからのセルフサービスを有効にすることができます。
このパターンの成熟した広範なバリエーションの例については、 エンタイトルメントの管理方法に関する GitHub のブログ投稿を参照してください。 GitHub では、高度な エンタイトルメントの実装 もオープンソース化されており、試用または採用できます。 ブログ記事では従業員のエンタイトルメントについて説明していますが、より狭い範囲の開発チーム のシナリオに、コードの概念としてチームを適用できます。 これらの開発チームは、従業員組織図にまったく表示されず、チーム メンバーのオンボーディングやオフボードを複雑にする可能性がある独自のツールやサービスが含まれている場合があります。
CI/CD システムと ID プロバイダー グループを使用して更新を調整する、この考え方の簡略化されたバリエーションの概要を次に示します。
この例では：
- 関係する各システムは、シングル サインオン (SSO) に ID プロバイダー ( Microsoft Entra ID など) を使用するように設定されています。
- 複雑さを軽減し、一元的な監査を維持するために、システム間で ID プロバイダー グループ (Entra グループなど) を使用してロール別のメンバーシップを管理します。
大まかに言うと、このパターンのしくみを次に示します。
- 中央のロックダウンされた Git リポジトリには、各抽象チーム、関連するユーザー メンバーシップ、およびユーザー ロールを表す一連の (通常は YAML) ファイルがあります。 チームの変更の所有者または承認者は、この同じ場所 ( CODEOWNERS など) に格納することもできます。 これらのファイル内のユーザーへの参照は ID プロバイダーですが、このリポジトリは、これらのチームの信頼できるソースとして機能します (ユーザーではありません)。
- これらのファイルに対するすべての更新は、プル要求を通じて行われます。 これにより、監査可能性のために Git コミットへの要求に関する会話と関連する参加者が結び付けられます。
- リードと個々のユーザーは、ユーザーを追加または削除するための PR を作成できます。また、開発リーダーや他の役割の人々は、テンプレートから新しいチームファイルを用いて新しいチームを作成するための PR を作成できます。
- PR がメインにマージされるたびに、リポジトリに関連付けられた CI/CD システムによって、ID プロバイダー システムとすべてのダウンストリーム システムが必要に応じて更新されます。
具体的には、CI/CD システムは次のようになります。
- 適切なIDプロバイダーシステムのAPIを利用して、各役割に応じたIDプロバイダーグループを作成または更新し、正確にそのファイルに含まれている個人のみを対象とします。
- 各ダウンストリーム システムの API を使用して、システムグループ化の概念を各ロールの識別プロバイダー グループ ( GitHub や Azure DevOps など) に結び付けます。 これにより、役割を表すためにチームとダウンストリーム システムの間に一対多の関係が生じる可能性があります。
- (必要に応じて)各ダウンストリーム システムの API を使用して、システムのグループ化メカニズムに関連付けられたアクセス許可ロジックを実装します。
- API を使用して、ロックダウンされたデータストアを結果で更新し（ダウンストリームシステムチームのIDの関連付けを含む）、その結果は内部のシステムで利用できるようになります。 必要に応じて、同じ ID プロバイダーユーザー/アカウントのユーザー ID のさまざまなシステム表現の関連付けをここに格納することもできます。
組織で Entra エンタイトルメント管理のようなものが既に使用されている場合は、このパターンからグループ メンバーシップの管理を省略できる可能性があります。
ニーズとポリシーによって詳細が変わる可能性がありますが、一般的なパターンは任意の数のバリエーションに適応できます。 ダウンストリーム システムと統合するために必要なシークレットは、CI/CD システム ( GitHub Actions や Azure Pipelines など) または Azure Key Vault などに保持されます。
手動または外部でトリガーされた、パラメーター化されたワークフローを使用する
特定したセルフサービス関連の問題の一部は、Git でファイルを使用するのに役立たない可能性があります。 または、セルフサービス エクスペリエンスを促進するために使用するユーザー インターフェイスがある場合もあります。
さいわい、 GitHub Actions や Azure Pipelines を含むほとんどの CI システムには、UI または CLI を介して手動でトリガーできる入力を使用してワークフローを設定する機能があります。 開発者と関連する操作ロールは、これらのユーザー エクスペリエンスに既に精通している可能性が高いと考えられるため、手動トリガーはコード パターンとしてすべてを拡張して、自然なファイル表現を持たないか、PR プロセスを必要とせずに完全に自動化する必要があるアクティビティ (またはジョブ) の自動化を可能にすることができます。
CI システムでは、API を使用して、独自のユーザー エクスペリエンスからこれらのワークフローまたはパイプラインをトリガーすることを選択できる場合があります。 GitHub Actions の場合、この作業を行う鍵は、ワークフローの実行 をトリガーするワークフロー ディスパッチ イベントを発生させる Actions REST API です。 Azure DevOps トリガー は似ていますが、実行に Azure DevOps Pipeline API を使用することもできます。 他の製品でも同じ機能が表示される可能性があります。 手動でトリガーするか API を使用してトリガーされるかにかかわらず、各ワークフローは、ワークフロー YAML ファイルに workflow_dispatch 構成を追加することで、一連の入力をサポートできます。 たとえば、Backstage.io などのポータル ツールキットが GitHub Actions と 対話 する方法は次のとおりです。
CI/CD システムのワークフローまたはジョブ システムは、間違いなくアクティビティを追跡し、状態を報告し、開発者と運用チームの両方が問題を確認するために使用できる詳細なログを持っています。 この方法では、すべてをコードとして扱うパターンと同様に、セキュリティ、監査可能性、可視性の利点があります。 ただし、留意すべき点の 1 つは、これらのワークフローまたはパイプラインによって実行されるアクションは、ダウンストリーム システムへのシステム ID (たとえば、Microsoft Entra ID のサービス プリンシパルまたはマネージド ID) のように見えるということです。
CI/CD システムで要求を開始するユーザーを把握できますが、これが十分な情報であるかどうかを評価し、CI/CD リテンション期間の設定が、この情報が重要な場合の監査要件に準拠していることを確認する必要があります。
その他の場合、統合するツールには、依存できる独自の追跡メカニズムが用意されている場合があります。 たとえば、これらの CI/CD ツールには、ほとんどの場合、 Microsoft Teams や Slack チャネルの使用など、いくつかの通知メカニズムがあります。これにより、状態の更新を取得する要求を送信するすべてのユーザーを保持でき、チャネルは何が起こったかについて非公式の記録を提供します。 多くの場合、これらの同じワークフロー エンジンは、これらのパターンの有用性をさらに拡張するために、運用ツールと統合するように既に設計されています。
要約すると、CI/CD ツールの柔軟性とすぐに使用できるユーザー エクスペリエンスにより、ソース管理リポジトリに格納されているファイルを使用して、いくつかの自動化を実装できます。 内部開発者プラットフォームで、時間の経過とともに高度な機能を損なうことなくこのアプローチを開始点として使用する方法については、「 開発者のセルフサービス基盤を設計する」を参照してください。
開発者向けコーディング環境のセットアップを自動化する
エンジニアリング システムのもう 1 つの一般的な問題は、開発者向けのコーディング環境のブートストラップと正規化です。 この領域で聞く可能性がある一般的な問題の一部を次に示します。
- 場合によっては、開発者が最初のプル要求に到達するまでに数週間かかることがあります。 これは、機能チームやプロジェクト間で開発者を頻繁に移動する場合（たとえば、マトリックス型の組織の場合）、請負業者を迅速に対応させる必要があるとき、または採用フェーズにあるチームにいる場合に問題となる領域です。
- 開発者と CI システムの間の不整合により、熟練したチーム メンバーでも頻繁に "自分のコンピューターで動作する" 問題が発生する可能性があります。
- フレームワーク、実行時間、その他のソフトウェアの実験とアップグレードによって、既存の開発者環境が壊れ、何が問題なのかを正確に把握しようとする時間が失われる可能性もあります。
- 開発リーダーの場合、コード レビューでは、レビューが完了したら、テストと元に戻すために構成の変更が必要になる可能性があるため、開発が遅くなる可能性があります。
- また、チーム メンバーとオペレーターは、開発 (オペレーター、QA、ビジネス、スポンサー) 以外の関連する役割を増やして、チームが行っている作業のテスト、進行状況の確認、ビジネスロールのトレーニング、およびエバンジェリ化に時間を費やす必要があります。
舗装された道の一部
これらの問題を解決するには、明確に定義された舗装パスの一部として、特定のツールとユーティリティのセットアップについて考えてください。 開発者マシンのセットアップのスクリプト作成が役立ち、CI 環境でこれらの同じスクリプトを再利用できます。 ただし、提供できる利点があるため、コンテナー化または仮想化された開発環境をサポートすることを検討してください。 これらのコーディング環境は、組織またはプロジェクトの仕様に事前に設定できます。
ワークステーションの交換と Windows のターゲット設定
Windows を対象としている場合、または完全なワークステーション仮想化 (プロジェクト固有の設定に加えてクライアント ツールとホスト OS 設定) を実行する場合は、通常、VM が最適な機能を提供します。 これらの環境は、Windows クライアント開発から Windows サービスまで、または .NET フル フレームワーク Web アプリケーションの管理と保守に役立ちます。
| 方法 | 例示 |
|---|---|
| クラウドでホストされる VM を使用する | Microsoft Dev Box は、デスクトップ管理ソフトウェアとの統合が組み込まれた完全な Windows ワークステーション仮想化オプションです。 |
| ローカル仮想マシンを使用する | Hashicorp Vagrant は優れたオプションであり、 HashiCorp Packer を使用して、It と Dev Box の両方の VM イメージを構築できます。 |
ワークスペースの仮想化と Linux を対象とする
Linux を対象としている場合は、ワークスペースの仮想化オプションを検討してください。 これらのオプションは、開発者のデスクトップを置き換えることよりも、プロジェクトやアプリケーションに特化したワークスペースに重点を置きます。
| 方法 | 例示 |
|---|---|
| クラウドでホストされるコンテナーを使用する | GitHub Codespaces は、VS Code、JetBrains の IntelliJ、ターミナル ベースのツールとの統合をサポートする、Dev Containers 用のクラウドベースの環境です。 このサービスまたは同様のサービスがニーズを満たしていない場合は、リモート Linux VM 上の Dev Containers で VS Code の SSH または リモート トンネル のサポートを使用できます。 クライアントだけでなく、Web ベースの vscode.dev でも機能するトンネル ベースのオプション。 |
| ローカル コンテナーを使用する | 代わりに、またはクラウドでホストされているオプションに加えて、ローカルの Dev Containers オプションを使用する場合、 Dev Containers は VS Code、 IntelliJ でのサポート、 およびその他のツールやサービスを確実にサポートします。 |
| クラウドでホストされている VM を使用する | コンテナーの制限が多すぎる場合は、 VS Code や IntelliJ などの JetBrains ツールなどのツールで SSH サポートを使用すると、自分で管理する Linux VM に直接接続できます。 VS Code には トンネルベースのオプション もあります。 |
| Linux 用 Windows サブシステムを使用する | 開発者が Windows 専用の場合、 Windows Subsystem for Linux (WSL) は、開発者が Linux をローカルでターゲットにするための優れた方法です。 チームの WSL ディストリビューションをエクスポートし、設定されたすべてのものと共有できます。 クラウド オプションの場合、Microsoft Dev Box などのクラウド ワークステーション サービスでは、WSL を利用して Linux 開発をターゲットにすることもできます。 |
「開始時の正しい設定を含むテンプレートを作成し、継続してその設定を維持する」
コード パターンとしてのすべてのものの素晴らしい点は、開発者が最初から確立した舗装されたパスを維持できることです。 これが組織の課題である場合、アプリケーション テンプレートは、一貫性を促進し、標準化を促進し、組織のベスト プラクティスを体系化するために、構成要素を再利用するための重要な方法になる可能性があります。
まず、 GitHub テンプレート リポジトリのような単純なものを使用できますが、組織が monorepo パターンに従っている場合は、効果が低下する可能性があります。 アプリケーション ソース ツリーに直接関連しないものを設定するのに役立つテンプレートを作成することもできます。 代わりに、 cookiecutter、 Yeoman、または Azure Developer CLI (azd) のようなテンプレート エンジンを使用できます。テンプレート化と簡略化された CI/CD セットアップに加えて、開発者コマンドの便利なセットも提供します。 Azure Developer CLI は、すべてのシナリオで環境のセットアップを推進するために使用できるため、Azure Deployment Environment と統合して、セキュリティの向上、統合された IaC、環境の追跡、懸念事項の分離、および簡略化された CD セットアップを提供します。
一連のテンプレートを作成すると、開発リーダーはこれらのコマンド ライン ツールまたはその他の統合ユーザー エクスペリエンスを使用して、アプリケーションのコンテンツをスキャフォールディングできます。 ただし、開発者はテンプレートからリポジトリやその他のコンテンツを作成するアクセス許可を持っていない可能性があるため、これは手動でトリガーされたパラメーター化されたワークフローまたはパイプラインを使用するもう 1 つの機会でもあります。 CI/CD システムがリポジトリからインフラストラクチャに代わって何かを作成するように入力を設定できます。
正しい状態を維持し、正しく達成すること
ただし、スケーリングを支援するために、これらのアプリケーション テンプレートは、可能な限り一元化された構成要素 (IaC テンプレートや CI/CD ワークフローやパイプラインなど) を参照する必要があります。 実際、これらの一元化された構成要素を独自の形式の開始適切なテンプレートとして扱うと、特定した問題の一部を解決するための効果的な戦略になる可能性があります。
これらの個々のテンプレートは、新しいアプリケーションだけでなく、更新または改善されたガイドラインをロールアウトするための適切なキャンペーンの一部として更新する予定の既存のテンプレートにも適用できます。 さらに、この一元化は、新しいアプリケーションと既存のアプリケーションの両方を適切に維持し、時間の経過と共にベスト プラクティスを進化または拡張するのに役立ちます。
テンプレートの内容
テンプレートを作成するときは、次の領域を検討することをお勧めします。
| Area | 詳細 |
|---|---|
| アプリ パターン、SDK、およびツールの使用を促進するための十分なサンプル ソース コード | 推奨される言語、アプリ モデルとサービス、API、SDK、アーキテクチャ パターンに開発者を誘導するためのコードと構成を含めます。 選択したツールを使用して、分散トレース、ログ記録、および可観測性のコードを含めるようにしてください。 |
| ビルド スクリプトとデプロイ スクリプト | ビルドとローカル/サンドボックスのデプロイをトリガーする一般的な方法を開発者に提供します。 選択したツールを使用するために、IDE/エディターにデバッグ構成を追加してください。 これは、メンテナンスの煩わしさを避け、CI/CD の同期が取れないことを防ぐための重要な方法です。テンプレートエンジンが Azure Developer CLI のように意見を持っている場合、使用できるコマンドが既に存在する可能性があります。 |
| CI/CD の構成 | 推奨事項に基づいてアプリケーションをビルドおよびデプロイするためのワークフロー/パイプラインを提供します。 一元化された 再利用可能な、または テンプレート化された ワークフロー/パイプラインを利用して、最新の状態を保ちます。 実際、これらの再利用可能なワークフロー／パイプラインは、それ自体がテンプレートとして機能することができます。 これらのワークフローを手動でトリガーするオプションを必ず検討してください。 |
| コード資産としてのインフラストラクチャ | 中央管理されたモジュールまたはカタログ項目への参照を含む推奨される IaC 構成を提供して、インフラストラクチャのセットアップが最初からベストプラクティスに従っていることを確認します。 これらの参照は、チームが時間の経過とともに正しく保つのを助けます。 ワークフローやパイプラインと組み合わせることで、ほぼあらゆるものをプロビジョニングできる IaC や EaC を含めることも可能です。 |
| コード資産としてのセキュリティとポリシー | DevSecOps の移動により、セキュリティ構成がコードに移行されました。これはテンプレートに最適です。 コード成果物としての一部のポリシーは、アプリケーション レベルでも適用できます。 CODEOWNERS などのファイルから、GitHub Advanced Security の dependabot.yaml などのスキャン構成まで、すべてを含めます。 環境テストの実行と共に Defender for Cloud などを使用して、スキャンのスケジュールされたワークフロー/パイプライン実行を提供します。 これはサプライ チェーンのセキュリティにとって重要であり、アプリケーション パッケージとコードに加えて コンテナー イメージを考慮 に入れるようにしてください。 これらの手順は、開発チームが正しい方向に進み続けるのに役立ちます。 |
| 可観測性、監視、およびログ記録 | セルフサービスを有効にすることの一部は、デプロイ後にアプリケーションを簡単に可視化することです。 ランタイム環境のインフラストラクチャ以外にも、可観測性と監視のためのセットアップを必ず含めるようにしてください。 ほとんどの場合、IaC 設定の側面 (エージェントのデプロイ、インストルメンテーションなど) がありますが、異なるコードとしての設定アイテム (例えば、Azure Application Insights のモニタリングダッシュボード) である場合もあります。 最後に、選択したツールを使用して、分散トレース、ログ記録、および監視のためのコード サンプル コードを含めるようにします。 |
| コーディング環境のセットアップ | リンター、フォーマッタ、エディター、IDE をコーディングするための構成ファイルを含めます。 devcontainer.json、devbox.yaml、開発者向けの Dockerfile、Docker Compose ファイル、Vagrantfiles などのワークスペースまたはワークステーションの仮想化ファイルと共にセットアップ スクリプトを含めます。 |
| テスト構成 | UI 用の Microsoft Playwright Testing や Azure App Testing などの優先サービスを使用して、単体テストとより詳細なテストの両方の構成ファイルを提供します。 |
| コラボレーション ツールのセットアップ | 問題管理およびソース管理システムがタスク/問題/PR テンプレートをコードとしてサポートしている場合は、これらを含めます。 さらにセットアップが必要な場合は、必要に応じて、使用可能な CLI または API を使用してシステムを更新するワークフロー/パイプラインを提供できます。 これにより、Microsoft Teamsや Slack などの他のコラボレーション ツールを設定することもできます。 |