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

開発者のセルフサービスの向上は、プラットフォーム エンジニアリング経験で最初に取り組む問題の 1 つである必要があります。

自動化されたセルフサービス エクスペリエンスの有効化を開始する最も簡単な方法の 1 つは、既存のエンジニアリング システムを再利用することです。 これらのシステムは、ユーザーや社内の顧客にとってなじみがあるだけでなく、初期のユーザー エクスペリエンスが適切でない場合でも、幅広い自動化シナリオを実現できます。

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

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

エンジニアリング システムは、社内の開発者プラットフォームの重要な側面です。 社内の開発者プラットフォームは、DevOps と DevSecOps のメイン テナントから構築され、関係するすべてのユーザーの認知的な負荷を軽減します。

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

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

目的の舗装されたパスを確立する

エンジニアリング システムを構成する複数のツール セットが既にある場合は、最初のプラットフォーム エンジニアリング作業の一環として統合するか、最初からさまざまなツールの集合をサポートするのかを早期に決定します。 このツールの集合の中で一連の舗装されたパスを定義することが最も効果的であり、柔軟性を向上させることができます。

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

自分自身のことをまだ行うことができますが、私たちが目指す方向に沿って行います... 必要なら何でも変更できますが、それはあなたの責任になります。 あなたは変化を起こすことができ、そして、鋭いナイフを持つこともできます。 - 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 成果物を一元的に発行する必要があります。 たとえば、レジストリ内の Terraform モジュール、Bicep モジュール、Radius レシピ、または Azure Container Registry (ACR)、DockerHub、または Azure Deployment Environments (ADE) のカタログなど、クラウド ネイティブの OCI アーティファクト レジストリに格納された Helm チャートを使用できます。 GitOps と Kubernetes の場合、Cluster 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 の概念はアプリケーション開発に関連していますが、内部顧客がプロビジョニングする必要のあるものの多くは、特定のアプリケーションと直接結びついていないものです。 これは、共有インフラストラクチャ、リポジトリの作成、プロビジョニング ツールなどです。

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

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

最初に自動化する可能性のあるターゲットとして、頻繁な、作業量が高い、またはエラーが発生しやすいプロセスを特定します。

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

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

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

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

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

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

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

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

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

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

このアプローチのスケーリングを開始する際は、プロビジョニングされたインフラストラクチャの追跡方法を検討してください。 Git リポジトリは構成に適した信頼できる情報源ですが、作成したインフラストラクチャに関する特定の URI や状態情報は提供されません。 ただし、Everything as Code アプローチを採用すると、プロビジョニングされたインフラストラクチャのインベントリを合成するために利用できる情報源を得られます。 プロビジョナーも、同様に活用できる優れた情報源になる可能性があります。 たとえば、Azure Deployment Environments には、開発者が可視化できる環境追跡機能が含まれています。

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

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

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

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

独自のシナリオに Everything as Code を使用する

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

PR は、さまざまなプロセス、特に開始したばかりのプロセスに適したベースラインのセルフサービス ユーザー エクスペリエンスになります。 Git 自体が提供するセキュリティ、監視能力、ロールバックの利点をプロセスに自然に適用できるだけでなく、今後、ユーザー エクスペリエンスに影響を与えずに、関係するシステムを変更できます。

Teams as Code

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

このパターンの高度かつ広範な実装の例については、エンタイトルメントの管理方法に関する GitHub のブログ記事をご覧ください。 GitHub は、試用や採用を支援するために、洗練されたエンタイトルメントの実装をオープンソースとして提供しています。 このブログ記事では、従業員全体のエンタイトルメントについて説明していますが、Teams as Code コンセプトをより限定的に開発チームのシナリオに適用することもできます。 このような開発チームは、従業員組織図に表示されていない場合があり、独自のツールやサービスの使用によってチーム メンバーのオンボーディングやオフボーディングが複雑化している可能性があります。

このアイデアの簡単なバリエーションの概要を次に示します。ここでは、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 を使用して、これらのシステムのグループ化概念を、ロールごとの ID プロバイダー グループに関連付けます (例: 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 を介して手動でトリガーできます。 開発者や関連する運用のロールはこれらのユーザー エクスペリエンスにすでに精通している可能性が高いため、手動トリガーを活用して Everything as Code パターンを拡張し、自然なファイル表現がないアクティビティ (またはジョブ) や、PR プロセスを回避して完全に自動化するのが望ましいアクティビティ (またはジョブ) を自動化できます。

CI システムでは、API を使用して、独自のユーザー エクスペリエンスからこれらのワークフローまたはパイプラインをトリガーすることを選択できる場合があります。 GitHub アクションの場合、これを実行するには、ワークフロー ディスパッチ イベントを起動するアクション REST API を使用してワークフローの実行をトリガーする必要があります。 Azure DevOps トリガーは似ていますが、実行に Azure DevOps Pipeline APIを使用することもできます。 他の製品でも同じ機能が表示される可能性があります。 手動でトリガーするか API 経由でトリガーするかにかかわらず、ワークフロー YAML ファイルに workflow_dispatch 構成を追加することで、各ワークフローが一連の入力をサポートできるようになります。 たとえば、Backstage.io などのポータル ツールキットと GitHub Actions はこのように連携できます。

CI/CD システムのワークフローまたはジョブ システムは、確実にアクティビティを追跡し、状態を報告し、開発者と運用チームの両方が問題を確認するために使用できる詳細なログを提供します。 この方法には、Everything as Code パターンと同様のセキュリティ、監視能力、可視性の利点があります。 ただし、留意すべき点の 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アプリケーションの管理と保守などに役立ちます。

ワークスペースの仮想化と Linux をターゲットとする

Linux をターゲットとしている場合は、ワークスペースの仮想化オプションを検討してください。 これらのオプションは、開発者のデスクトップを置き換えることよりも、プロジェクトやアプリケーション固有のワークスペースに焦点を当てています。

起動に適した構成を含む、起動に適したアプリケーション テンプレートを作成する

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

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

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

適切に維持し、的確に取得する

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

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

テンプレートの内容

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

関連するコンテンツ

• Microsoft DevOps リソース センター
• コンテナー サプライ チェーンのセキュリティ
• GitHub Actions と GitFlow を使用した AKS アプリの CI/CD