ソフトウェアエンジニアリングシステムを適用する

[アーティクル]
02/20/2024

プラットフォームエンジニアリングの取り組みで最初に取り組みたい問題を理解すると、開発者のセルフサービスの向上が一覧の一番上に表示される可能性があります。自動化されたセルフサービスエクスペリエンスの有効化を開始する最も簡単な方法の 1 つは、既存のエンジニアリングシステムを再利用することです。これらのシステムは、ユーザーや社内の顧客にとってなじみがあるだけでなく、初期のユーザーエクスペリエンスが適切でなくても、幅広い自動化シナリオを実現できます。

この記事では、エンジニアリングシステムを適用して、より広範なセルフサービスシナリオに取り組むためのヒントと、ベストプラクティスを適切に開始して正しく維持するのに役立つテンプレートにカプセル化する方法について説明します。

基本の DevOps と DevSecOps プラクティスを評価する

エンジニアリングシステムは、内部開発者プラットフォームの重要な側面です。ただし、DevOps と DevSecOps の少なくとも一部のメインテナントをターゲットとするシステムがまだない場合は、特定した問題によって、そこから始める必要がある可能性があります。内部開発者プラットフォームは、関係者全員の認知負荷を軽減するために、そこから構築されます。

要約すると、DevOps は開発と運用を組み合わせて、アプリケーションの計画、開発、配信、運用で人、プロセス、テクノロジを統合します。これは、開発、IT 運用、品質エンジニアリング、セキュリティなど、歴史的にサイロ化された役割全体のコラボレーションを改善することを目的としています。開発、デプロイ、監視、観察、フィードバックの間に継続的なループを確立します。 DevSecOps は、アプリケーション開発プロセス全体を通じて継続的なセキュリティプラクティスを使用して、このループにレイヤー化します。

計画、提供、開発、運用を含む DevOps ライフサイクルの画像。

Microsoft の DevOps リソースセンターは、必要なプロセスとシステムの種類に関するアドバイスを探すのに最適な場所であるため、このセクションではこれらの詳細については説明しません。これらは、あなたが前に進むにつれて不可欠な成分になります。また、コンテナーサプライチェーンのセキュリティなどの最近の DevSecOps トピックを計画に組み込むのを忘れないでください。

継続的フィードバックの詳細については、考慮すべきメトリックに関するページを参照してください。監視、監視、および継続的フィードバック領域で使用するツールの詳細については、「アプリケーションプラットフォームを絞り込む」を参照してください。

この記事の残りの部分では、プラットフォームエンジニアリングの動きにより直接的に起因する改善に焦点を当てます。これには、舗装されたパス、自動化されたインフラストラクチャプロビジョニング (アプリケーションのデプロイに加えて)、コーディング環境のセットアップ、およびアプリケーション開発ループの直接の一部ではないツール、チーム資産、サービスのセルフサービスプロビジョニングと構成が含まれます。

必要な舗装されたパスを確立する

エンジニアリングシステムを構成する複数のツールセットが既にある場合は、最初のプラットフォームエンジニアリング作業の一環としてそれらを統合する際に合格するか、最初からさまざまなツールの組み合わせをサポートするのかを早期に決定する必要があります。ほとんどの場合、このツールのコンステレーション内で舗装されたパスのセットを定義することが最も効果的であり、柔軟性のレベルが向上します。

製品の考え方に移行し始めると、これらの舗装されたパス内のエンジニアリングシステムは、開発チームへのサービスとして一元的に管理されるツールで構成されると考えることができます。その後、organization内の個々のチームまたは部門は逸脱する可能性がありますが、コンプライアンス要件に準拠しながら、ツールを個別に管理、維持、支払う必要があります。これにより、時間の経過と同時に舗装されたパスに含まれる可能性がある場合に逸脱するものを評価できるため、中断することなく新しいツールをエコシステムにフィードする方法が提供されます。 1 つのプラットフォームエンジニアリングリーダーが次のように言います。

あなたはまだあなた自身のことを行うことができますが、私たちが行く方向にそれを行います... 必要なものは何でも変更できますが、これはユーザーの責任になります。あなたは変更を所有している - あなたは鋭いナイフを所有しています。 - Mark、プラットフォームエンジニアリングリーダー、大規模な欧州多国籍小売会社

プラットフォームエンジニアリングの主な目標は、内部の顧客に価値を提供する製品マインドセットに移行することです。この星座アプローチは、通常、トップダウンの義務よりも優れています。舗装されたパスを確立して改良すると、ある程度の柔軟性を残すことにより、チームは、organizationの他のユーザーに影響を与えることなく、特定のアプリケーションに対して入力を提供し、特定のアプリケーションの真に固有の要件に対処できます。これにより、完全に舗装されたゴールデンパスのセットが作成され、他のパスは部分的にのみ舗装されます。固有の要件がない場合は、開発チームが引き受ける余分な作業によって、時間の経過と同時にサポートされているパスに移行する必要が生じるのは当然です。

統合戦略を好む場合は、既存のアプリケーションの移行が予想よりも多くの作業になる可能性があることに注意してください。そのため、まず、この領域の最初の適切な側面に焦点を当て、新しいプロジェクトに集中する必要があります。これにより、最初の舗装されたパスが提供されますが、既存のパスはすべて本質的に未舗装です。その後、未移行パスの開発チームは、新しい舗装されたパスの値がorganizationに表示されたら、移動することを検討します。その時点で適切なキャンペーンを実行して、開発チームはこれを税金ではなく利益と見なしているため、双方向のコミュニケーションを通じてすべてのユーザーに望ましい状態を得ることができます。キャンペーン中、プラットフォームエンジニアリングチームはチームの移行を支援することに集中できます。一方、開発チームは、舗装されたパスをより良くする方法に関するフィードバックを提供します。

関係なく、舗装されたパスの使用を管理しないようにしてください。それらをロールアウトする最も効果的な方法は、強制導入ではなく、チームが何を抜け出すのかを強調することです。内部開発者プラットフォームでは、これらのまったく同じチームを幸せにすることに重点を置いているため、個々のリーダーに対する予算と価値への時間の圧力は、残りの部分を処理する傾向があります。次に、適切なキャンペーンを取得し、未承認のパス上の人が切り替える最善の方法で双方向の会話を行うための手段を提供します。

開発者オートメーションツールを使用して、舗装されたパスのセルフサービスを向上させる

最初の舗装されたパスを作成する一環として、開発者向けの主要な自動化製品を確立する必要があります。これらは、開発者のセルフサービス機能を有効にすることを考え始める際に重要です。

継続的デリバリー中にアプリケーションインフラストラクチャの自動プロビジョニングを有効にする

まだ実装されていない場合、計画中に特定した問題は、継続的インテグレーション (CI) と継続的デリバリー (CD) が解決に役立つ問題を示している可能性があります。この領域には、GitHub Actions、Azure DevOps、Jenkins などの製品と、Flux や Argo CD などのプルベースの GitOps ソリューションが存在します。これらのトピックは、 Microsoft DevOps リソースセンターで開始できます。

既存のインフラストラクチャにアプリケーションを継続的にデプロイする方法を既に実装している場合でも、コードとしてのインフラストラクチャ (IaC) を使用して、CD パイプラインの一部として必要なアプリケーションインフラストラクチャを作成または更新することも検討する必要があります。

たとえば、GitHub Actionsを使用してインフラストラクチャを更新し、Azure Kubernetes Serviceにデプロイする 2 つの方法を示す次の図を考えてみましょう。1 つはプッシュベースのデプロイを使用し、もう 1 つはプルベース (GitOps) のデプロイです。

各アプローチの詳細については、「GitHub Actionsと Gitflow を使用した AKS アプリの CI/CD」を参照してください。

多くの場合、選択するのは、既存の IaC スキルセットとターゲットアプリケーションプラットフォームの詳細によって決まります。 GitOps アプローチは、より新しく、アプリケーションのベースとして Kubernetes を使用する組織の間で人気があります。一方、プルベースモデルでは現在、使用可能なオプションの数に応じて最も柔軟性が高くなります。ほとんどの組織では、2 つの組み合わせを使用することを期待しています。いずれの場合も、IaC プラクティスに精通することは、さらに自動化シナリオに適用されるパターンを学習するのに役立ちます。

カタログまたはレジストリ内の IaC を一元化して、セキュリティをスケーリングおよび向上させる

アプリケーション間で IaC を管理およびスケーリングするには、再利用のために IaC 成果物を一元的に発行する必要があります。たとえば、Azure Deployment Environments (ADE) の Azure Container Registry (ACR)、DockerHub、カタログなど、クラウドネイティブ OCI Artifact レジストリに格納されているレジストリ、Bicep モジュール、Radius レシピ、Helm Chart で Terraform モジュールを使用できます。 GitOps と Kubernetes の場合、クラスター API (および CAPZ などの実装) を使用して Kubernetes ワークロードクラスターを管理できます。一方、 Azure Service Operator などのカスタムリソース定義では、他の種類の Azure リソースのサポートを追加できます。 Crossplane などの他のツールは、複数のクラウドにまたがるリソースをサポートします。これにより、より広範なシナリオに対して、ACR などの一元化された Helm グラフまたは一般的な Helm グラフを使用できます。

IaC を一元化すると、アプリケーションコードと共に保存されなくなったため、更新できるユーザーをより適切に制御できるため、セキュリティが向上します。エキスパート、運用、またはプラットフォームエンジニアが必要な変更を加えたときに、コードの更新中に不注意による変更によって偶発的な中断が発生するリスクは少なくなります。開発者は、完全な IaC テンプレートを自分で作成する必要がなく、エンコードされたベストプラクティスの恩恵を自動的に受ける必要がないため、これらの構成要素の利点もあります。

どの IaC 形式を選択するかは、既存のスキルセット、必要な制御レベル、使用するアプリモデルによって異なります。たとえば、Azure Container Apps (ACA) と最近の実験的な Radius OSS インキュベーションプロジェクトは、Kubernetes を直接使用するよりも意見が多いですが、開発者エクスペリエンスも合理化されます。「クラウドサービスの種類について説明する」トレーニングモジュールは、さまざまなモデルの長所と短所を理解するのに役立ちます。関係なく、ソースツリーに完全な定義を含めるのではなく、一元化されたマネージド IaC を参照することには大きな利点があります。

開発者がガバナンスの基本的な構成要素のレイヤーに直接アクセスできない方法で、必要なプロビジョニング ID またはシークレットを保持します。たとえば、 Azure Deployment Environments (ADE) を使用して実現できるロールの分離に関するこの図を考えてみましょう。

ここでは、プラットフォームエンジニアや他の専門家が IaC やその他のテンプレートを開発し、カタログに配置します。操作では、"環境の種類" によってマネージド ID とサブスクリプションを追加し、プロビジョニングに使用できる開発者や他のユーザーを割り当てることができます。

開発者または CI/CD パイプラインは、Azure CLI またはAzure Developer CLIを使用して、基になるサブスクリプションや ID にアクセスしなくても、事前に構成された制御されたインフラストラクチャをプロビジョニングできます。 ADE のようなものを使用するかどうかにかかわらず、継続的デリバリーシステムは、シークレットを分離し、開発者が自分でアクセスまたは変更できない場所から IaC コンテンツをソーシングすることで、インフラストラクチャを安全かつ安全に更新するのに役立ちます。

アプリケーションの継続的デリバリー以外のシナリオでセルフサービスを有効にする

CI と CD の概念はアプリケーション開発に関連付けられていますが、内部の顧客がプロビジョニングする必要がある多くは、特定のアプリケーションに直接結び付くわけではありません。これは、共有インフラストラクチャ、リポジトリの作成、プロビジョニングツールなどです。

これがどこで役立つかを理解するには、現在手動またはサービスデスクベースのプロセスがある場所について考えてください。それぞれについて、次の質問について考えます。

このプロセスはどのくらいの頻度で行われますか?
プロセスが遅い、エラーが発生しやすい、または達成するために重要な作業が必要ですか?
これらのプロセスは、必要な承認手順または単に自動化がないために手動ですか?
承認者が必要な場合、ソース管理システムと pull request プロセスに精通していますか?
プロセスの監査要件は何ですか? これらは、ソース管理システムの監査要件とは異なりますか?
より複雑なプロセスに進む前に、リスクが低いプロセスから始めることができますか?

最初に自動化する潜在的なターゲットとして、頻繁な、高い労力、またはエラーが発生しやすいプロセスを特定します。次に、これを実現するためのいくつかの簡単な方法について説明します。

すべてをコードパターンとして使用する

git のユビキタスに加えて、git に関する優れた点の 1 つは、セキュリティで保護された監査可能な情報源を意図していることです。コミット履歴とアクセス制御以外にも、pull request やブランチ保護などの概念は、メインブランチにマージする前に渡す必要がある特定のレビュー担当者、会話履歴、または自動チェックを確立する方法を提供します。 CI/CD システムのような柔軟なタスクエンジンと組み合わせると、安全な自動化フレームワークが得られます。

コードとしてのすべての背後にある考え方は、セキュリティで保護された Git リポジトリ内のファイルにほとんど何でも変換できることです。その後、リポジトリに接続されているさまざまなツールまたはエージェントがコンテンツを読み取ることができます。テンプレートを使用してすべてをコードとして扱うと、反復性が向上し、開発者のセルフサービスが簡素化されます。これがどのように機能するかの例をいくつか見てみましょう。

任意のインフラストラクチャに IaC パターンを適用する

IaC はアプリケーションの配信の自動化に役立つ人気を得ましたが、このパターンは、特定のアプリケーションに関連付けられているインフラストラクチャ、ツール、またはサービスだけでなく、プロビジョニングと構成が必要になる可能性があるあらゆるインフラストラクチャにまで及びます。たとえば、Flux がインストールされているクラスターで K8 を共有したり、複数のチームやアプリケーションで使用される DataDog のようなものをプロビジョニングしたり、お気に入りのコラボレーションツールを設定したりします。

これが機能する方法は、プロビジョニングと構成を表す一連のファイル (この場合は Bicep、Terraform、Helm チャート、その他の Kubernetes ネイティブ形式) を格納する、セキュリティで保護された個別の一元化されたリポジトリを持っているということです。運用チームまたは他の一連の管理者がリポジトリを所有しており、開発者 (またはシステム) は pull request を送信できます。これらの PR がこれらの管理者によってメインブランチにマージされると、アプリケーションの開発時に使用されるのと同じ CI/CD ツールを使用して変更を処理できます。 Azure デプロイ環境に格納されているGitHub Actionsと IaC とデプロイ ID を使用する次の図を考えてみましょう。

アプリケーションのデプロイに GitOps アプローチを既に使用している場合は、これらのツールも再利用できます。 Flux や Azure Service Operator などのツールを組み合わせると、Kubernetes の外部に拡張できます。

どちらの場合も、生成されたものがアプリケーション用ではない場合でも、完全に管理され、再現可能で監査可能な情報源があります。アプリケーション開発と同様に、必要なシークレットまたはマネージド ID は、パイプライン/ワークフローエンジンまたはプロビジョニングサービスのネイティブ機能に格納できます。

PR を作成するユーザーはこれらのシークレットに直接アクセスできないため、開発者は自分で直接アクセス許可を持っていないアクションを安全に開始する方法を提供します。これにより、開発者にセルフサービスオプションを提供しながら、最小限の特権の原則に従うことが可能になります。

プロビジョニングされたインフラストラクチャを追跡する

このアプローチのスケーリングを開始したら、プロビジョニングされたインフラストラクチャを追跡する方法について考えてください。 Git リポジトリは構成の真実のソースですが、作成した内容に関する特定の URI と状態情報は通知されません。ただし、コードアプローチとしてすべてを実行すると、プロビジョニングされたインフラストラクチャのインベントリを合成するために活用する情報ソースが提供されます。また、プロビジョニング担当者は、この情報を活用できる適切なソースになる場合もあります。たとえば、Azure Deployment Environments には、開発者が可視性を持つ環境追跡機能が含まれています。

さまざまなデータソース間での追跡の詳細については、「開発者のセルフサービス基盤を設計する」を参照してください。

コードとしてセキュリティを適用し、コードパターンとしてポリシーを適用する

プロビジョニングインフラストラクチャは便利ですが、これらの環境が安全であり、通常はorganizationのポリシーに従っていることを確認することが同様に重要です。これが、"コードとしてのポリシー" 概念の台頭につながりました。ここでは、ソース管理リポジトリの構成ファイルを使用して、セキュリティスキャンの推進やインフラストラクチャポリシーの適用などを行うことができます。

Azure Policy、Open Policy Agent 、GitHub Advanced Security、GitHub CODEOWNERS など、多くの異なる製品やオープンソースプロジェクトがこのアプローチをサポートしています。アプリケーションインフラストラクチャ、サービス、またはツールを選択するときは、これらのパターンをどの程度サポートしているかを評価してください。アプリケーションとガバナンスの調整の詳細については、「アプリケーションプラットフォームの絞り込み」を参照してください。

すべてを独自のシナリオのコードとして使用する

コードとしてのすべてが、これらのパターンを IaC 以外のさまざまな自動化および構成タスクに拡張します。あらゆる種類のインフラストラクチャの作成または構成だけでなく、ダウンストリームシステムでのデータの更新やワークフローのトリガーもサポートできます。

PR は、さまざまなプロセス (特に作業を開始する場合) に適したベースラインセルフサービスユーザーエクスペリエンスになります。プロセスは、Git 自体が提供するセキュリティ、監査可能性、ロールバックの利点を当然得ます。また、関係するシステムは、ユーザーエクスペリエンスに影響を与えることなく、時間の経過と同時に変化する可能性もあります。

コードとしての Teams

すべてをコードとして独自のシナリオに適用する例の 1 つは、コードパターンとしてのチームです。組織は、このパターンを適用してチームメンバーシップを標準化し、場合によっては、さまざまなシステムにわたって開発者ツール/サービスのエンタイトルメントを標準化します。このパターンにより、システム開発者とオペレーターが独自のグループ化、ユーザー、アクセスの概念にアクセスする必要性によって推進される、手動オンボードとオフボードサービスデスクプロセスが不要になります。手動サービスデスクプロセスは、アクセスを過剰プロビジョニングする可能性があるため、潜在的なセキュリティリスクです。チームをコードパターンとして使用する場合、git 要求と pull request の組み合わせにより、監査可能なデータソースからのセルフサービスを有効にすることができます。

このパターンの成熟した広範なバリエーションの例については、エンタイトルメントの管理方法に関する GitHub のブログ記事をチェック。 GitHub では、高度なエンタイトルメントの実装をオープンソース化して試したり、採用したりすることもできます。ブログ記事では従業員のエンタイトルメントについて説明していますが、より狭い範囲の開発チームシナリオにコード概念としてチームを適用できます。これらの開発チームは、従業員組織図にまったく表示されず、オンボーディングやオフボードチームメンバーを複雑にする可能性がある独自のツールやサービスが含まれる場合があります。

CI/CD システムと ID プロバイダーグループを使用して更新を調整する、このアイデアの簡略化されたバリエーションの概要を次に示します。

この例では、次のことを想定しています。

関連する各システムは、シングルサインオン (SSO) に ID プロバイダー (Microsoft Entra ID など) を使用するように設定されています。
複雑さを軽減し、一元的な監査を維持するために、システム間で ID プロバイダーグループ (Entra グループなど) を使用してロール別のメンバーシップを管理します。

大まかに言えば、このパターンのしくみを次に示します。

中央のロックダウンされた Git リポジトリには、各抽象チーム、関連するユーザーメンバーシップ、およびユーザーロールを表す一連の (通常は YAML) ファイルがあります。チーム変更の所有者/承認者は、この同じ場所 ( CODEOWNERS など) に格納することもできます。これらのファイル内のユーザーへの参照は ID プロバイダーですが、このリポジトリは、これらのチームの真実のソースとして機能します (ただし、ユーザーは機能しません)。
他のコードケースと同様に、これらのファイルに対するすべての更新は pull request を介して行われます。これにより、会話と、監査のために git コミットへの要求に関連する参加者が結び付きます。
潜在顧客と個々のユーザーは、PR をユーザーの追加/削除にすることができ、開発リードやその他のロールは、テンプレートから新しいチームファイルを含む PR を使用して新しいチームを作成できます。
PR がメインにマージされるたびに、リポジトリに関連付けられた CI/CD システムによって、ID プロバイダーシステムとすべてのダウンストリームシステムが必要に応じて更新されます。

具体的には、CI/CD システムは次のとおりです。

適切な ID プロバイダーシステム API を使用して、ロールごとに ID プロバイダーグループを作成または更新し、ファイル内の正確な個人を使用します (これ以上、少なからず)。
各ダウンストリームシステムの API を使用して、これらのシステムグループ化の概念を各ロールの識別プロバイダーグループに結び付けます (例: GitHub と Azure DevOps)。これにより、ロールを表すためにチームとダウンストリームシステムの間に一対多の関係が生じる可能性があります。
必要に応じて、各ダウンストリームシステムの API を使用して、システムのグループ化メカニズムに関連付けられているアクセス許可ロジックを実装します。
API を使用して、ロックダウンされたデータストアを結果に更新します (ダウンストリームシステムチーム ID の関連付けも含む)。必要に応じて、同じ ID プロバイダーユーザー/アカウントのユーザー ID のさまざまなシステム表現の関連付けをここに格納することもできます。

organizationで 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 システムのワークフロー/ジョブシステムは、間違いなくアクティビティを追跡し、状態を報告し、開発者と運用チームの両方が問題を確認するために使用できる詳細なログを持っています。このように、コードパターンと同じセキュリティ、監査可能性、可視性の利点があります。ただし、これらのワークフローやパイプラインによって実行されるアクションは、ダウンストリームシステムに対するシステム ID (Microsoft Entra IDのサービスプリンシパルやマネージド ID など) のようになります。

CI/CD システムで要求を開始するユーザーを把握できますが、これが十分な情報であるかどうかを評価し、CI/CD 保持設定が、この情報が重要な場合の監査要件に準拠していることを確認する必要があります。

その他の場合、統合するツールには、依存できる独自の追跡メカニズムが用意されている場合があります。たとえば、これらの CI/CD ツールには、ほとんどの場合、 Microsoft Teams や Slack チャネルの使用など、いくつかの通知メカニズムが用意されています。これにより、すべてのユーザーが状態の更新を取得するための要求を送信し続けることができ、チャネルは何が起こったかについて非公式な記録を提供します。多くの場合、これらの同じワークフローエンジンは、これらのパターンの有用性をさらに拡張するために、運用ツールと統合するように既に設計されています。

まとめると、CI/CD ツールの柔軟性とすぐに使用できるユーザーエクスペリエンスにより、ソース管理リポジトリに格納されているファイルを使用して、いくつかの自動化を実装できます。

内部開発者プラットフォームで、時間の経過と同時に高度な機能を損なうことなくこのアプローチを出発点として使用する方法については、「開発者向けセルフサービス基盤を設計する」を参照してください。

開発者向けコーディング環境のセットアップを自動化する

エンジニアリングシステムが役立つ可能性があるもう 1 つの一般的な問題は、開発者向けのコーディング環境のブートストラップと正規化です。この領域で聞く可能性がある一般的な問題の一部を次に示します。

場合によっては、開発者が最初の pull request に到達するまでに数週間かかる場合があります。これは、フィーチャークルーとプロジェクト間で開発者を頻繁に転送する場合 (マトリックス化された組織など)、請負業者を立ち上げる必要がある場合、または採用フェーズにあるチームにいる場合に問題のある領域です。
開発者と CI システムの間の不整合により、経験豊富なチームメンバーであっても、頻繁に "自分のマシンで動作する" 問題が発生する可能性があります。
フレームワーク、実行時間、その他のソフトウェアの実験とアップグレードによって、既存の開発環境が壊れ、何が問題になったのかを正確に把握しようとする時間が失われる可能性もあります。
開発リードの場合、コードレビューは、レビューが完了したらテストおよび元に戻すために構成の変更が必要になる可能性があるため、開発が遅くなる可能性があります。
また、チームメンバーとオペレーターは、開発 (オペレーター、QA、ビジネス、スポンサー) 以外の関連ロールを増やして、チームが行っている作業のテスト、進行状況の確認、ビジネスロールのトレーニング、伝道に役立つ時間を費やす必要があります。

舗装されたパスの一部

これらの問題を解決するには、明確に定義された舗装パスの一部として、特定のツールとユーティリティの設定について考えてください。開発者マシンのセットアップをスクリプト化すると役立ち、CI 環境でこれらの同じスクリプトを再利用できます。ただし、提供できる利点があるため、コンテナー化または仮想化された開発環境をサポートすることを検討してください。これらのコーディング環境は、organizationまたはプロジェクトの仕様に事前に設定できます。

ワークステーションの置き換えと Windows のターゲット設定

Windows をターゲットにしている場合、または完全なワークステーション仮想化 (プロジェクト固有の設定に加えてクライアントツールとホスト OS 設定) を実行する場合、VM は通常、最適な機能を提供します。これらの環境は、Windows クライアントの開発から Windows サービス、または .NET フルフレームワーク Web アプリケーションの管理と保守まで、あらゆる場合に役立ちます。

アプローチ	例
クラウドでホストされている VM を使用する	Microsoft Dev Box は、デスクトップ管理ソフトウェアへの統合が組み込まれた完全な Windows ワークステーション仮想化オプションです。
ローカル VM を使用する	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 のみを使用している場合、開発者が Linux をローカルでターゲットにするための優れた方法は、Linux 用 Windows サブシステム (WSL) です。チームの WSL ディストリビューションをエクスポートし、設定されたすべてのものと共有できます。クラウドオプションの場合、Microsoft Dev Box などのクラウドワークステーションサービスでは、WSL を利用して Linux 開発をターゲットにすることもできます。

適切な構成を維持するアプリケーションテンプレートを作成する

コードパターンとしてのすべてのものの素晴らしい点は、開発者が最初から確立した舗装されたパスを維持できることです。これがorganizationの課題である場合、アプリケーションテンプレートは、文書パーツを再利用して一貫性を高め、標準化を促進し、organizationのベストプラクティスを体系化するための重要な方法になる可能性があります。

まず、GitHub テンプレートリポジトリと同じくらい単純なものを使用できますが、organizationが monorepo パターンに従っている場合は、効果が低下する可能性があります。また、アプリケーションソースツリーに直接関連しないものを設定するのに役立つテンプレートを作成することもできます。代わりに、cookiecutter、Yeoman などのテンプレートエンジン、またはテンプレート化と簡略化された CI/CD セットアップに加えて、開発者コマンドの便利なセットも提供するAzure Developer CLI (azd) のようなものを使用できます。 Azure Developer CLIは、すべてのシナリオで環境のセットアップを推進するために使用できるため、Azure Deployment Environments と統合され、セキュリティの強化、統合された IaC、環境の追跡、懸念事項の分離、および簡略化された CD セットアップが提供されます。

一連のテンプレートを作成すると、開発リードは、これらのコマンドラインツールまたはその他の統合ユーザーエクスペリエンスを使用して、アプリケーションのコンテンツをスキャフォールディングできます。ただし、開発者はテンプレートからリポジトリやその他のコンテンツを作成するアクセス許可を持っていない可能性があるため、手動でトリガーされたパラメーター化されたワークフロー/パイプラインを使用するもう 1 つの機会でもあります。 CI/CD システムがリポジトリからインフラストラクチャに代わって何かを作成するように入力を設定できます。

正しく維持し、正しく取得する

ただし、スケーリングを支援するために、これらのアプリケーションテンプレートでは、可能な限り一元化された構成要素 (IaC テンプレートや CI/CD ワークフロー/パイプラインなど) を参照する必要があります。実際、これらの一元化された構成要素を独自の形式の開始右テンプレートとして扱うと、特定した問題の一部を解決するための効果的な戦略であることがわかります。

これらの個々のテンプレートは、新しいアプリケーションだけでなく、更新または改善されたガイドラインをロールアウトするための適切なキャンペーンの一環として更新する予定の既存のテンプレートにも適用できます。さらに、この集中化は、新しいアプリケーションと既存のアプリケーションの両方を適切に維持し、時間の経過と共にベストプラクティスを進化または拡張するのに役立ちます。

テンプレートの内容

テンプレートを作成するときは、次の領域を検討することをお勧めします。

領域	詳細
アプリパターン、SDK、ツールの使用を促進するための十分なサンプルソースコード	推奨される言語、アプリモデルとサービス、API、SDK、アーキテクチャパターンに開発者を誘導するためのコードと構成を含めます。選択したツールを使用して、分散トレース、ログ記録、監視のためのコードを必ず含めるようにしてください。
ビルドスクリプトとデプロイスクリプト	ビルドとローカル/サンドボックスデプロイをトリガーする一般的な方法を開発者に提供します。選択したツールで使用できるように、IDE またはエディター内のデバッグ構成を含めます。これは、メンテナンスの頭痛を避け、CI/CD が同期しなくなるのを防ぐ重要な方法です。テンプレートエンジンがAzure Developer CLIのように意見されている場合は、使用できるコマンドが既にある可能性があります。
CI/CD の構成	推奨事項に基づいてアプリケーションを構築およびデプロイするためのワークフロー/パイプラインを提供します。一元化された再利用可能なワークフローまたはテンプレート化されたワークフロー/パイプラインを活用して、最新の状態を維持します。実際、これらの再利用可能なワークフロー/パイプラインは、独自の適切なテンプレートを開始できます。これらのワークフローを手動でトリガーするオプションを必ず検討してください。
コード資産としてのインフラストラクチャ	一元管理されたモジュールまたはカタログ項目への参照を含む推奨される IaC 構成を提供して、インフラストラクチャのセットアップが get-go のベストプラクティスに従っていることを確認します。これらの参照は、時間が経つにつれてチームが正しく維持するのにも役立ちます。ワークフロー/パイプラインと組み合わせて、IaC または EaC を含め、あらゆるものをプロビジョニングすることもできます。
コード資産としてのセキュリティとポリシー	DevSecOps の動きにより、セキュリティ構成もコードに移行されました。これはテンプレートに最適です。コード成果物としての一部のポリシーは、アプリケーションレベルでも適用できます。 CODEOWNERS などのファイルから、GitHub Advanced Securityの dependabot.yaml などのスキャン構成まで、すべてを含めます。環境テストの実行と共に Defender for Cloud のようなものを使用して、スキャンのスケジュールされたワークフロー/パイプライン実行を提供します。これはサプライチェーンのセキュリティにとって特に重要であり、アプリケーションパッケージとコードに加えてコンテナーイメージを考慮に入れるようにしてください。これらの手順は、開発チームが正しく維持するのに役立ちます。
監視、監視、ログ記録	セルフサービスを有効にすることの一部は、デプロイ後にアプリケーションを簡単に可視化することです。ランタイムインフラストラクチャ以外にも、監視と監視のためのセットアップを含めるようにしてください。ほとんどの場合、セットアップには IaC の側面 (エージェントのデプロイ、インストルメンテーションなど) がありますが、他の場合は、コードとしての構成成果物の別の種類 (Azure アプリケーション Insights のダッシュボードの監視など) である可能性があります。最後に、選択したツールを使用して、分散トレース、ログ記録、監視のためのコードサンプルコードを含めるようにします。
コーディング環境のセットアップ	リンター、フォーマッタ、エディター、IDE をコーディングするための構成ファイルを含めます。 devcontainer.json、devbox.yaml、開発者向けの Dockerfiles、Docker Compose ファイル、Vagrantfiles などのワークスペースまたはワークステーションの仮想化ファイルと共にセットアップスクリプトを含めます。
テスト構成	UI のMicrosoft Playwright Testingや Azure Load Testing などの優先サービスを使用して、単体テストとより詳細なテストの両方に構成ファイルを提供します。
コラボレーションツールのセットアップ	問題管理とソース管理システムがタスク/issue/PR テンプレートをコードとしてサポートしている場合は、これらを含めます。より多くのセットアップが必要な場合は、必要に応じて、使用可能な CLI または API を使用してシステムを更新するワークフロー/パイプラインを提供できます。これにより、Microsoft Teams や Slack などの他のコラボレーションツールを設定することもできます。

アプリケーションプラットフォームを調整する

ソフトウェア エンジニアリング システムを適用する