ドキュメンテーションと開始方法

このドキュメンテーションは、ONDEMANDENVのセットアップと使用方法を案内し、プラットフォームを運用可能にし、サービスを統合するために必要な詳細を提供します。

インストールとセットアップ

以下の手順に従って、ONDEMANDENVプラットフォームを環境にセットアップします。

1. 環境準備

AWS環境:

  • AWS Organization: AWS Organizationをセットアップします。
  • 2つのAWSアカウント: 組織内で、以下を指定または作成します:
    • 中央アカウント:コアONDEMANDENVプラットフォームエンジンが実行される場所です。
    • ワークスペースアカウント (workspace0):必須のcontractsLib enverを含む、デプロイの初期ターゲットです。
  • ホストゾーン: 中央アカウント内のRoute 53にパブリックホストゾーンを作成します。適切なドメイン名を選択します(例:<your-chosen-name>.root.ondemandenv.link)。この名前は後で必要になるため、メモしておいてください。
  • リージョン: プライマリAWSリージョンを決定します(例:us-east-1)。すべての初期セットアップリソースはこのリージョンにある必要があります。
  • AWS CDKブートストラップ: 選択したリージョンに対して、中央アカウントとworkspace0アカウントの両方でCDKをブートストラップします。以下を実行します:
    # 中央アカウントのコンテキストで
    aws configure set region YOUR_REGION
    cdk bootstrap aws://CENTRAL_ACCOUNT_ID/YOUR_REGION
    
    # workspace0アカウントのコンテキストで
    aws configure set region YOUR_REGION
    cdk bootstrap aws://WORKSPACE0_ACCOUNT_ID/YOUR_REGION
  • クロスアカウント信頼: workspace0アカウントが中央アカウントを信頼するように構成します。workspace0にIAMロール(例:OndemandenvDeployerRole)を作成し、AdministratorAccess(または後で最小権限に基づくより制限されたポリシー)を付与し、中央アカウントがそのロールを引き受けられるようにします。信頼ポリシーは、ONDEMANDENVプラットフォームが中央アカウントで使用するロールARNを明示的に許可する必要があります(これはプラットフォームテンプレートによって定義されます)。
  • GitHubアプリの秘密鍵シークレット: 中央アカウント内のAWS Secrets Managerにシークレットを作成します。このシークレットに特定の名前を選択します(例:ondemandenv/github-app-private-key)。次のステップでGitHubアプリの秘密鍵をここに保存します。このシークレット名(ghAppPrivateKeySecretName)をメモしておいてください。ONDEMANDENVプラットフォームテンプレートでこの名前が必要になります。

GitHub環境:

  • GitHub組織: GitHub組織がセットアップされていることを確認します。
  • プライベートGitHubアプリ: 組織が所有する新しいプライベートGitHubアプリを作成します。
    • 生成された秘密鍵(.pemファイル)をダウンロードします。
    • 重要: この秘密鍵ファイルの内容を、中央アカウントで作成したAWS Secrets Managerシークレット(ghAppPrivateKeySecretName)に新しいバージョンとして安全に保存します。
    • アプリに必要な権限を構成します(詳細についてはONDEMANDENVのドキュメントを参照してください。通常、コード、メタデータへの読み取りアクセス、および課題、プルリクエスト、ワークフロー、チェック、ステータス、デプロイメントへの書き込みアクセスが含まれます)。
    • Webhook URLは今のところ空白のままにしておきます。プラットフォームをデプロイした後に更新します。
    • このGitHubアプリを、`contractsLib`に使用する特定のリポジトリにインストールします。
  • `contractsLib`リポジトリ: GitHub組織内にリポジトリを作成し、サービスコントラクトを定義します。このリポジトリには、ONDEMANDENVのビルドとenver定義が含まれます。
    • `ondemandenv/odmd-contracts-sandbox`をサンプル構造として使用できます。
    • リポジトリに必要な依存関係(`@ondemandenv/odmd-contracts-base`など)とビルドスクリプト(例:`package.json`内)が含まれていることを確認し、TypeScript定義をコンパイルします。
    • npm packを使用して、コンパイルされた`contractsLib`定義をパッケージ化する必要があります。これにより、.tgzファイルが生成されます。

2. プラットフォームのデプロイ

  1. ONDEMANDENVサービスへの情報送信:

    ONDEMANDENVチーム(または指定された連絡先)に以下の情報を提供し、プラットフォームの初期設定とCloudFormationテンプレートの生成を依頼します。これには通常、オンボーディングプロセスが含まれます。

    • 中央アカウントID
    • ワークスペースアカウントID (workspace0)
    • プライマリAWSリージョン
    • Route 53ホストゾーン名(例:<your-chosen-name>.root.ondemandenv.link
    • GitHubアプリID
    • GitHubアプリのインストールID(アプリを`contractsLib`リポジトリにインストールした後)
    • GitHub組織名
    • `contractsLib`リポジトリ名
    • `contractsLib`定義の.tgzファイル(例:`my-org-contractslib-1.0.0.tgz`) - これは安全な方法で共有する必要があります。
    • `contractsLib`のビルド定義名(例:MyOrgContractsLibSbx - `contractsLib`コード内の`OdmdBuildContracts`インスタンスの名前)
    • `contractsLib`のenver定義名(例:contractsLibSbx - `contractsLib`コード内の`OdmdEnverContracts`インスタンスの名前)
    • GitHubアプリの秘密鍵シークレット名ghAppPrivateKeySecretName
    • (オプション)初期管理ユーザーのメールアドレス(プラットフォームUI/APIへのアクセス用)
  2. CloudFormationスタックのデプロイ:

    ONDEMANDENVチームから受け取ったCloudFormationテンプレートとパラメータを使用して、中央アカウントにスタックをデプロイします。

    • これにより、コアプラットフォームエンジン、API、Webhookハンドラー、および関連するIAMロールがプロビジョニングされます。
    • デプロイメントが完了すると、プラットフォームAPIエンドポイントとWebhook URLが出力されます。
  3. GitHubアプリのWebhookの設定:
    • CloudFormationスタックの出力からWebhook URLを取得します。
    • GitHubアプリの設定に移動し、このURLでWebhook URLを更新します。Webhookシークレットも設定してください(プラットフォームから提供されるか、設定時に指定します)。
    • イベント(プッシュ、プルリクエストなど)をサブスクライブします。
  4. `contractsLib` Enverの初期デプロイ:

    プラットフォームは、通常、`contractsLib`リポジトリへの最初のプッシュ時に(または手動トリガーを介して)、`contractsLib` enverをworkspace0アカウントに自動的にデプロイしようとします。これには以下が含まれます。

    • `contractsLib`リポジトリからコードをチェックアウトします。
    • `npm ci`および`npm run build`(または`package.json`で定義されたビルドスクリプト)を使用してコードをビルドします。
    • CDKを使用して、`contractsLib`で定義されたインフラストラクチャ(例:S3バケット、CodePipeline)をworkspace0アカウントにデプロイします。

    このステップが成功すると、ONDEMANDENVプラットフォームの基盤が整います。

ONDEMANDENVセットアップアーキテクチャ

図1:ONDEMANDENVの概念的なセットアップアーキテクチャ。中央アカウントがプラットフォームエンジンをホストし、ワークスペースアカウント(例:workspace0)が`contractsLib` enverおよびその後のサービスenverをホストします。

コアワークフローとハウツー

プラットフォームがセットアップされると、開発者は以下の一般的なワークフローに従ってサービスを定義、デプロイ、管理します。

1. `contractsLib`での定義

すべてのサービスとその環境(Envers)は、まず`contractsLib`リポジトリで宣言的に定義されます。これにより、一元化された制御と一貫性が保証されます。

a. ビルド定義の定義 (`OdmdBuild`)

各サービスタイプ(例:Node.js Lambda、Spring Boot Fargateサービス、静的サイト)に対して、`OdmdBuild`インスタンスを作成します。これは、サービスのビルド方法とパッケージ化方法を定義します。

//例:my-org-contractslib/lib/builds/my-service-builds.ts
import { OdmdBuild } from '@ondemandenv/odmd-contracts-base';
import { MyOrgAppEnver } from '../envers/my-org-app-enver'; // Enverタイプをインポート

export const MyNodeJsLambdaBuild = new OdmdBuild(this, 'MyNodeJsLambdaBuild', {
    githubRepoAlias: 'my-nodejs-lambda-service-repo', // サービスのコードが存在するリポジトリ
    buildType: 'lambda_nodejs', // または 'cdk', 'container_image'など
    sourcePath: 'src', // buildTypeに応じたソースパス
    // buildTypeに固有の追加パラメータ
});

githubRepoAliasは、ONDEMANDENVプラットフォーム設定(例:GitHubアプリのインストール)でマッピングされたリポジトリを指します。

b. Enver定義の定義 (`OdmdEnver`の拡張)

各サービスに対して、`OdmdEnverCdk`(CDKベースのデプロイメントの場合)または`OdmdEnverGeneric`を拡張するクラスを作成します。これにより、特定の環境インスタンス(例:開発、ステージング、本番)をモデル化できます。

//例:my-org-contractslib/lib/envers/my-org-app-enver.ts
import { OdmdEnverCdk, Product, Consumer } from '@ondemandenv/odmd-contracts-base';
import { Construct } from 'constructs';

// このEnverタイプが公開および消費する製品/消費者を定義するインターフェース
export interface MyOrgAppEnverProps {
    // このEnverが公開する製品の例
    readonly outputsProduct?: Product;
    // このEnverが消費する製品の例
    readonly userDatabaseConsumer?: Consumer;
}

export class MyOrgAppEnver extends OdmdEnverCdk implements MyOrgAppEnverProps {
    readonly outputsProduct?: Product;
    readonly userDatabaseConsumer?: Consumer;

    constructor(scope: Construct, id: string, props: OdmdEnverCdkProps & MyOrgAppEnverProps) {
        super(scope, id, props);
        this.outputsProduct = props.outputsProduct;
        this.userDatabaseConsumer = props.userDatabaseConsumer;
    }
}

c. 特定のEnverインスタンスのインスタンス化

ビルドとEnverタイプを使用して、特定の環境インスタンス(例:`myServiceDev`、`myServiceProd`)をインスタンス化します。製品(このEnverが公開する出力)と消費者(このEnverが必要とする依存関係)を定義します。

//例:my-org-contractslib/lib/envers/service-instances.ts
import { MyNodeJsLambdaBuild } from '../builds/my-service-builds';
import { MyOrgAppEnver } from './my-org-app-enver';
import { Product } from '@ondemandenv/odmd-contracts-base';
// 他のEnverインスタンスをインポートして依存関係を定義
// import { sharedDatabaseProd } from './shared-services';

export const myServiceDev = new MyOrgAppEnver(this, 'MyServiceDev', {
    build: MyNodeJsLambdaBuild, // 関連するビルド定義にリンク
    targetAccountAlias: 'dev-account', // プラットフォーム設定で定義されたアカウントエイリアス
    targetRegion: 'us-east-1', // オプション、デフォルトはプラットフォームのプライマリリージョン
    outputsProduct: new Product(this, 'Outputs'), // このEnverは出力を公開します
    // userDatabaseConsumer: new Consumer(this, 'UserDb', sharedDatabaseProd.outputsProduct), // 別のEnverからの製品を消費
    // enverSpecificConfig: { key: 'devValue' } // 環境固有の構成
});

export const myServiceProd = new MyOrgAppEnver(this, 'MyServiceProd', {
    build: MyNodeJsLambdaBuild,
    targetAccountAlias: 'prod-account',
    immutable: true, // 本番環境は不変としてマークされることがよくあります
    outputsProduct: new Product(this, 'Outputs'),
    // userDatabaseConsumer: new Consumer(this, 'UserDb', sharedDatabaseProd.outputsProduct),
    // enverSpecificConfig: { key: 'prodValue' }
});

`contractsLib`への変更をコミットしてプッシュすると、プラットフォームはこれらの定義を自動的に処理します。

2. サービスの実装

`OdmdBuild`定義で指定されたリポジトリ(例:`my-nodejs-lambda-service-repo`)に、サービスのビジネスロジックを実装します。デプロイメントタイプ(CDK、Lambda、コンテナ)に応じて、関連するファイル(例:`cdk-stack.ts`、`lambda-handler.js`、`Dockerfile`)を作成します。

CDKベースのサービスの場合 (`buildType: 'cdk'`)

CDKスタックは`OdmdEnverCdk`(またはそのサブクラス)から`getSharedValue('consumerName')`を介して消費された値と、`getEnverSpecificConfig()`を介して環境固有の構成にアクセスできます。

//例:my-nodejs-lambda-service-repo/lib/my-service-stack.ts
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { OdmdEnverCdk, OdmdShareOut } from '@ondemandenv/odmd-contracts-base'; // ベースライブラリからインポート
import * as lambda from 'aws-cdk-lib/aws-lambda';
// ... 他のCDKインポート

// MyOrgAppEnverで定義されたenverSpecificConfigのインターフェース
interface MyServiceConfig {
    key: string;
    // 他の構成プロパティ
}

export class MyServiceStack extends OdmdEnverCdk { // OdmdEnverCdkを拡張
    constructor(scope: Construct, id: string, props?: cdk.StackProps) {
        super(scope, id, props);

        // 消費された値を取得 (contractsLibで定義)
        // const userDbDetailsJson = OdmdEnverCdk.getSharedValue('UserDb');
        // const userDbDetails = JSON.parse(userDbDetailsJson || '{}');

        // 環境固有の構成を取得 (contractsLibで定義)
        const config = OdmdEnverCdk.getEnverSpecificConfig();

        const myFunction = new lambda.Function(this, 'MyLambdaFunction', {
            runtime: lambda.Runtime.NODEJS_18_X,
            handler: 'index.handler',
            code: lambda.Code.fromAsset('src'), // MyNodeJsLambdaBuildで定義されたsourcePathに一致
            environment: {
                // DB_HOST: userDbDetails.host,
                CONFIG_KEY: config?.key || 'defaultValue',
            },
        });

        // このスタックの出力を公開 (contractsLibのOutputs製品に一致)
        new OdmdShareOut(this, 'Outputs', {
            value: cdk.Stack.of(this).toJsonString({
                lambdaFunctionName: myFunction.functionName,
                // 他の出力
            }),
        });
    }
}

サービスコードに必要な依存関係(`@ondemandenv/odmd-contracts-base`など)を`package.json`に含めます。

3. デプロイとイテレーション

サービスリポジトリ(例:`my-nodejs-lambda-service-repo`)への変更をコミットしてプッシュします。

  • プラットフォームはプッシュイベントを検出し、`contractsLib`で定義された関連するEnver(例:`myServiceDev`)のビルドとデプロイをトリガーします。
  • ビルドログとデプロイステータスは、ONDEMANDENVプラットフォームのUIまたはAPIを介して監視できます。
  • デプロイされたサービスのエンドポイントまたはリソース詳細は、通常、プラットフォームUIまたは`Product`の消費を介して利用可能になります。

このサイクルを繰り返してサービスを開発および更新します。

4. Enverのクローン(動的環境)

ONDEMANDENVは、既存のEnverのオンデマンドクローニングをサポートしており、分離されたテスト、機能開発、または一時的なサンドボックスに最適です。

クローンを作成するには、サービスリポジトリのターゲットブランチ(例:`feature/new-feature`)にコミットし、コミットメッセージの本文に特別なコマンドを含めます。

git commit -m "フィーチャー:新しい認証フローを実装

odmd: create@myServiceDev"
  • odmd: create@BASE_ENVER_ID:`BASE_ENVER_ID`(例:`myServiceDev`)のクローンを作成し、現在のブランチのコードを使用してデプロイします。
  • クローンされたEnverは、ベースEnverの構成(依存関係、ターゲットアカウントなど)を継承しますが、現在のブランチのコードでデプロイされます。
  • リソース名は、競合を避けるためにクローンに対して一意に生成されます。
  • クローンされたEnverの詳細は、プラットフォームUIまたはAPIを介してアクセスできます。

あるいは、`contractsLib`で静的に`ClonedEnver`インスタンスを定義することもできます。

5. クローンの削除

動的に作成されたクローンEnverが不要になったら、それを削除してリソースを解放できます。

クローンEnverに関連付けられたブランチにコミットし、コミットメッセージの本文に特別なコマンドを含めます。

git commit --allow-empty -m "フィーチャーブランチクローンの削除

odmd: delete"
  • odmd: delete:現在のブランチに関連付けられたクローンEnverを破棄します。
  • プラットフォームは、クローンされたEnverに関連付けられているすべてのプロビジョニング済みリソースをクリーンアップします。

プラットフォームサービスの使用(製品と消費者)

Enverは、`Product`を公開し、他のEnverによって公開された`Product`を`Consumer`として使用することにより、相互作用できます。これにより、契約ベースの依存関係管理が可能になります。

  • 製品の公開: CDKスタックで`OdmdShareOut`コンストラクトを使用して、Enverの出力をJSON文字列として公開します。`contractsLib`で定義された`Product` IDと一致する必要があります。
  • 製品の使用: `contractsLib`で`Consumer`を定義し、別のEnverの`Product`をターゲットにします。CDKスタックでは、`OdmdEnverCdk.getSharedValue('ConsumerName')`を使用してJSON文字列として製品の値を取得し、解析して使用します。

プラットフォームは、これらのクロスEnverおよびクロスアカウントの依存関係の安全な解決をオーケストレーションします。

デプロイメントモデル

ONDEMANDENVは、柔軟なデプロイメントモデルをサポートしています。

  • マルチアカウント: Enverは、`contractsLib`で定義された`targetAccountAlias`に基づいて、異なるAWSアカウントにデプロイできます。プラットフォームは、クロスアカウントのロールの引き受けとリソース共有を管理します。
  • マルチリージョン: Enverは、`targetRegion`を指定することにより、異なるAWSリージョンにデプロイできます。
  • ビルドタイプ:
    • cdk:AWS CDKを使用してインフラストラクチャとアプリケーションをデプロイします。
    • lambda_nodejs / lambda_python / lambda_javaなど:指定されたランタイムのAWS Lambda関数を直接デプロイします(プラットフォームは必要なラッパーまたはCDKコードを生成する場合があります)。
    • container_image:コンテナイメージをビルドしてECSまたはEKSなどのサービスにデプロイします。
    • static_site:静的WebサイトコンテンツをS3/CloudFrontにデプロイします。
  • 不変性: Enverは`immutable: true`としてマークでき、意図しない変更を防ぎます。変更には、新しいEnverバージョンまたはクローンの作成が必要です。

セキュリティに関する考慮事項

ONDEMANDENVは、セキュリティを念頭に置いて設計されています。

  • 最小権限のIAMロール: プラットフォームコンポーネントとデプロイされたEnverは、最小権限の原則に従って設計されたIAMロールを使用します。
  • 契約ベースのセキュリティ: `contractsLib`での製品と消費者の間の接続は、クロスアカウントアクセス許可を管理するための信頼の基礎を形成します。プラットフォームは、これらの契約に基づいて必要なIAMポリシーとリソース共有(例:AWS RAM)を自動的に構成します。
  • シークレット管理: GitHubアプリの秘密鍵などの機密データは、AWS Secrets Managerに安全に保存されます。
  • ネットワーク分離: Enverは、標準のAWSネットワーキングコンストラクト(VPC、セキュリティグループなど)を利用して分離できます。共有ネットワークパターンは、一元管理されたネットワーキングリソースへの安全な接続を可能にします。
  • 監査とロギング: プラットフォームのアクションとEnverのデプロイは、AWS CloudTrailとCloudWatch Logsを介してログに記録され、監査機能を提供します。

CI/CD統合

ONDEMANDENVは、既存のCI/CDプラクティスを補完し、強化します。

  • GitOps中心: コアワークフローはGit操作(プッシュ、コミットメッセージ)を中心に展開され、GitOpsの原則と自然に一致します。
  • Webhook統合: GitHub(または他のVCS)Webhookは、`contractsLib`およびサービスリポジトリへの変更に基づいてプラットフォームアクションをトリガーします。
  • プラットフォームAPI: ONDEMANDENV APIを使用して、外部CI/CDパイプライン(Jenkins、GitLab CI、GitHub Actionsなど)からビルド、デプロイ、クローン操作をプログラムでトリガーできます。
  • 環境プログレッション: `contractsLib`で異なるEnver(開発、ステージング、本番)を定義し、ソースコミットハッシュを指定する機能と組み合わせることで、CI/CDパイプライン内で制御された環境プログレッションが可能になります。

ベースライブラリ (`@ondemandenv/odmd-contracts-base`)

@ondemandenv/odmd-contracts-baseライブラリは、ONDEMANDENVプラットフォームと対話するためのコアコンストラクトとユーティリティを提供します。

主なコンストラクト:

  • OdmdBuild:サービスアーティファクトのビルド方法を定義します。
  • OdmdEnverCdk:AWS CDKを使用してデプロイされる環境の基本クラス。環境固有の構成と共有値へのアクセスを提供します。
  • OdmdEnverGeneric:CDK以外のデプロイメントシナリオ用の汎用環境基本クラス。
  • OdmdBuildContracts / OdmdEnverContracts:`contractsLib`自体を定義およびデプロイするための特別なタイプ。
  • Product:Enverによって公開される出力またはリソースを定義します。
  • Consumer:別のEnverのProductに対する依存関係を定義します。
  • OdmdShareOut:CDKスタック内からProductの値を公開するために使用されます。

ユーティリティ:

  • OdmdEnverCdk.getSharedValue(consumerName):CDKスタック内の消費されたProductの値を取得します。
  • OdmdEnverCdk.getEnverSpecificConfig():CDKスタック内のEnver固有の構成を取得します。

これらのコンストラクトの詳細なAPIドキュメントと使用例については、ライブラリのソースコードと関連する型定義を参照してください。

コードの探索

ONDEMANDENVの機能をより深く理解するには、以下のリポジトリを探索することをお勧めします。

  • `odmd-contracts-base`

    コアTypeScriptライブラリ。`OdmdBuild`、`OdmdEnverCdk`、`Product`、`Consumer`などの基本的なコンストラクトが含まれています。これは、独自の`contractsLib`とサービスCDKコードを構築するための基礎です。

  • `odmd-contracts-sandbox`

    サンプル`contractsLib`リポジトリ。さまざまなビルドタイプ、Enver定義、製品/消費者の使用方法、およびフォルダ構造のベストプラクティスを示しています。独自の`contractsLib`の出発点として最適です。

  • `odmd-example-services` (もしあれば、または個々のサービス例)

    ONDEMANDENVを使用してデプロイできるさまざまなタイプのサンプルサービス(例:Node.js Lambda、Python Fargateサービス)。これらの例は、`odmd-contracts-sandbox`で定義された契約とどのように連携するかを示しています。

  • プラットフォームエンジンリポジトリ (アクセス可能な場合)

    ONDEMANDENVプラットフォーム自体のコアロジックを含むプライベートリポジトリ(通常はアクセスできません)。Webhookハンドラー、API、デプロイメントオーケストレーション、および状態管理が含まれます。

プラットフォーム内部(高度な概要)

ONDEMANDENVプラットフォームは、いくつかの主要コンポーネントで構成されています。

  • 契約ストア (`contractsLib`): すべての環境とサービスの定義の信頼できる情報源。これは、専用のAWSアカウント(例:`workspace0`)で実行される特別なEnverとして管理されます。その主な出力は、処理された契約定義を含むS3バケットです。
  • Webhookハンドラー: GitHub(または他のVCSプロバイダー)からのWebhookイベント(例:プッシュ、コミットメッセージコマンド)をリッスンするAPI GatewayとLambda関数。これらのイベントを解析し、対応するプラットフォームアクションをトリガーします。
  • APIエンドポイント: プラットフォームと対話するためのRESTful API。ビルドのトリガー、Enverステータスのクエリ、クローンの管理などに使用されます。
  • オーケストレーションエンジン (Step Functions / Lambda): ビルド、デプロイ、クローン作成、削除などの複雑なワークフローを管理するAWS Step FunctionsステートマシンとLambda関数。これらのワークフローには、コードのチェックアウト、依存関係の解決(Products/Consumers)、CDKの合成とデプロイ、および状態の更新が含まれます。
  • 状態データベース (DynamoDB): Enver、ビルド、デプロイ、およびそれらの関係の状態を追跡するDynamoDBテーブル。
  • ID管理: APIおよびUIアクセス用のユーザーIDと認証を管理します(例:Amazon Cognito)。
  • CDKツールキットの統合: プラットフォームは、指定されたターゲットアカウントとリージョンでCDKスタックを合成およびデプロイするために、AWS CDKツールキットと深く統合されています。クロスアカウントデプロイロールを活用します。
  • 通知サービス (SNS/SES): (オプション)デプロイの完了やエラーなどの重要なイベントについてユーザーに通知します。

プラットフォームがコマンド(例:`odmd: create@baseEnver`)を受信すると、次の一般的なシーケンスが発生します。

  1. Webhookハンドラーがコマンドを検証し、オーケストレーションエンジンをトリガーします。
  2. オーケストレーションエンジンが契約ストアからベースEnver定義を読み取ります。
  3. 指定されたブランチからサービスコードをチェックアウトします。
  4. ターゲットアカウントとリージョンで、ベースEnverの構成とブランチのコードを使用して新しいEnver(クローン)のCDKスタックを合成します。
  5. 合成されたテンプレートをデプロイし、リソース名が一意であることを保証します。
  6. 状態データベースを更新し、プラットフォームUIを介して詳細を利用可能にします。

このアーキテクチャにより、スケーラブルで回復力があり、安全な方法で、オンデマンドで忠実度の高い環境を作成および管理できます。