開発基礎知識

まず、開発の一般的な流れは、「Commit → Build → Test → Deploy」

Commit	・変更をCommitする ・複数の変更を統合する ・変更の履歴を統合する
Build	・成果物をBuildする ・複数の成果物の依存関係を解決する ・(Docker)イメージを作る
Test	・成果物の単体テスト実行 ・成果物の結合テスト実行 ・テスト結果を出力
Deploy	・成果物を開発環境に反映 ・成果物を本番環境に反映

●Web Hook
「イベント駆動型のHTTP通知機能」。あるサービスで特定のイベントが発生したとき、事前に指定されたURLへ自動的にHTTPリクエスト（通常はPOST）を送信する。この機能によってイベントを起点としたプログラムをHTTP通信で実行できるため、ポーリングやメッセージングシステムの利用は不要。

CLI

※AWS操作は主にAWSマネジメントコンソールとAWS CLIを利用

◇コマンド

[情報を展開する]

start-build	使用してビルド仕様(buildspec)をオーバーライドできる。
aws configure	AWS CLI のインストールをセットアップするための最も簡単な方法。このコマンドを入力すると、AWS CLI によって 4 つの情報の入力が求められる。 ・アクセスキー ID ・シークレットアクセスキー ・AWS リージョン ・出力形式

SDK
【構築ツールセット】

※特定のプラットフォーム、オペレーティングシステム、またはプログラミング言語で実行されるコードを作成するには、デバッガー、コンパイラー、ライブラリなどのコンポーネントが必要。

・「AWS SDK」と「AWS CLI」はIAMロールから一時的なセキュリティ認証情報を自動取得できる。

特定のソフトウェア、プラットフォーム、ハードウェア、またはオペレーティングシステム向けのアプリケーションを構築するために必要な、ツールやライブラリ、ドキュメントなどをまとめたパッケージです。

ウェブアプリケーションがAPI Gatewayと連携するために必要なコード（JavaScript SDK）が含まれていれば、SDKを使うことで、開発者はAPIへの接続やデータのやり取りといった複雑な処理をゼロから書く必要がなくなり、効率的に開発を進めることができる。

例えるなら、組み立て式の家具を買ったときに付いてくる、ネジや六角レンチ、そして説明書がすべて入ったセットのようなもの。SDKがなければ、必要なツールや部品をすべて自分で見つけ出して揃えなければならないため、開発が非常に困難になる。

DataPipeline
【リソース上でデータの移動支援】

・データの取り出し・変換・保存など順次処理が可能。
（※オンプレミス環境からのデータ転送にはDataSyncを利用）

◇スケジュールされたパイプライン

[情報を展開する]

【関連項目】

パイプラインコンポーネント 【 データ管理のルールを定義】	・パイプラインのビジネスロジックを表し、パイプライン定義のさまざまなセクションによって表される。 ・ワークフローのデータソース、アクティビティ、スケジュール、および前提条件を指定する。 ・これらは親コンポーネントからプロパティを継承でき、コンポーネント間の関係は参照によって定義される。
インスタンス	各インスタンスには、特定のタスクを実行するためのすべての情報が含まれている。 ・パイプラインを実行するときに、パイプラインコンポーネントをコンパイルして、一連のアクション可能なインスタンスを作成する。 ・完全なインスタンスのセットは、パイプラインの To-Do リスト。Task Runner に処理するインスタンスを渡す。
試行	堅牢なデータ管理を提供するために、失敗したオペレーションを再試行する。 (※この処理は、タスクが最大許容再試行回数に到達するまで続行される) ・試行オブジェクトは、さまざまな試行、結果、および失敗の理由（該当する場合）を追跡する。 ・基本的に、試行はカウンター付きのインスタンス。Amazon EMR クラスターや EC2 インスタンスなど、以前の試行と同じリソースを使用して再試行を行う。

Code Star
【開発環境作成・ステータス管理】

事前設定された継続的デリバリーツールチェーンを提供することでアプリケーションの提供を迅速化。

◇機能性

[情報を展開する]

継続的デリバリー	ソフトウェア開発手法の一つ。コード変更が発生すると、自動的に実稼働環境へのリリース準備が実行される。アプリケーションのアップデートを素早く反映できる。
ツールチェーン	ある目的を達成するために組み合わせて使用する一連のツール(道具)のセット。
継続的デプロイメント 【開発アクティビティ管理】	CI/CD パイプラインでのコードのコミット、ビルド、テスト、デプロイなどのアクティビティを一元的に管理し、表示。 ・アプリケーションのビルドが正常に完了すると全て成功と表示 デプロイの進行状況やコミットの履歴なども同時に確認が可能。 ※ステージの追加、編集を行いたい場合には「Code Pipelineの詳細」を選択する。
チームwiki	内容をカスタマイズしてチームノートに保存したり、プロジェクトにリンクさせる、コードサンプル、チームメモなどのチーム情報の提供が容易。
アプリケーションアクティビティの監視と JIRA の問題管理	アプリケーション監視サービスであるCloudWatchやプロジェクト管理ツールであるAtlassian JIRA Softwareなどと統合することで、アプリケーションやJIRAの問題の監視、追跡、管理が可能。
アプリケーションエンドポイント	エンドポイントのリンクが表示。アプリケーションまたはサービスを表示するにはリンクを選択。
コミット履歴	リポジトリの最近のコミット履歴が表示。 コミットやリポジトリに関する全てのコミットや詳細を表示したい場合は… →コードがCodeCommitに保存されている　⇒　CodeCommitの詳細 →コードがGitHubに保存されている　⇒　GitHubで開く
アプリケーションアクティビティ	プロジェクトのAmazon CloudWatchメトリクスが表示。例えば、Code DeployリソースによってデプロイされたAmazon EC2のCPU使用率や、AWS Lambdaを使用すればLambda関数の呼び出しとエラーのメトリクスが表示され、情報は時間単位で表示される。

◇作成要素

[情報を展開する]

プロジェクトテンプレート	・EC2、Lambda、Elastic Beanstalk にデプロイするアプリケーションの開発をすばやく開始する助けになり、複数用意されている。 ・Java、JavaScript、Python、Ruby、PHP などの多くのプログラミング言語をサポート
自動化された継続的デリバリーパイプライン	CodePipelineと連携して、コードのビルド、テスト、デプロイが自動化された事前設定済みのパイプラインがプロジェクトごとに設定（継続的デリバリー）されている。
自動化されたデプロイ	CodeDeployやCloudFormationと統合することで、アプリケーションコードを簡単に更新し、EC2やLambdaにデプロイすることができる。

◇管理要素

[情報を展開する]

チームのアクセス管理	・IAM によって開発者のアイデンティティ管理を実施。 ・アクセス管理は、「所有者 / コントリビューター/ ビューワー」などのさまざまなロールに対応する、簡単な組み込みのセキュリティポリシーにより、プロジェクトへのアクセスを簡単に保護する。
ホスト型の Git リポジトリ (Code Commitで安全管理)	・CodeStarでのアプリケーションコードはCodeCommit に保存。 ※独自の GitHub リポジトリにプロジェクトのソースコードを保存できる。 ・Git リポジトリをホストするために独自のインフラストラクチャを管理する必要がなくなる。
一元化されたプロジェクトダッシュボード	一元的にアプリケーションアクティビティの監視と、最近のコードのコミット、ビルド、デプロイなどの日常的な開発タスク全体の管理を容易に行える。
完全マネージド型ビルドサービス	CodeBuild を使用することで、コードのビルド、テスト、統合をより頻繁に実行できるよう になり、ソースコードのコンパイルとパッケージ化を行える。

CodePipeline
【流れの見える化】

●アーティファクトストア

パイプライン内で生成・受け渡しされる成果物（アーティファクト）を保存するための Amazon S3 バケットのこと。

【役割】

• アーティファクトとは？
  → ソースコード、ビルド成果物、テストレポート、デプロイパッケージなど、各ステージで生成されるファイル群。
• 保存場所：
  → CodePipeline は、これらのアーティファクトを S3 バケットに保存し、次のステージに受け渡す。
• 一元管理と履歴保持：
  → アーティファクトストアに保存することで、成果物の履歴を追跡でき、トラブルシューティングや再デプロイに役立ちます。

※CloudTrailと連携されている

【CI/CD】
実装 > テスト > デプロイ・リリース のフローを可能な限り自動化する（Code＞Build＞Test＞Deploy）

◇性能特徴

[情報を展開する]

パイプライン 【一連の処理の流れ】	ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造。各パイプラインは一連のステージで構成。 (※CloudFormationテンプレートのデプロイ、テストに利用できる。） (※パイプライン内の処理を定義するにはUIから手動で行うか、CloudformationでStackを定義して行う形になる)
ステージ 【処理を実行する環境の単位】	各ステージのアプリケーションアーティファクトに対して実行される複数アクションが含まれる。 (※各ステージ毎にコンテナを立ち上げて処理するイメージ) 各ステージは、連続または並列のアクションで構成されている。環境を分離し、その環境での同時変更の数を制限するために使用できる論理ユニット。
アクション 【実際に行われる処理の単位】	ソースコードを取ってきたり、テストしたり、デプロイしたりする。 アクションには[source / build / test / deploy / approval] というタイプがある。 パイプラインのステージに承認アクションを追加した箇所でパイプラインを停止することで、このアクションを主導で承認または拒否できる。

[※参考サイト]

◇承認アクション

[情報を展開する]

【承認アクションの概要】

• 承認アクションを使うことで、パイプラインの特定ステージにおいて手動承認を要求できる。
• 承認アクションは、CodePipeline のステージに承認アクションを追加した箇所でパイプラインを停止することで、このアクションを手動で承認または拒否できる。アクションが追加されると、承認が完了するまで次のステージに進まない。
• IAM（AWS Identity and Access Management）アクセス許可が必要。

【承認が必要になるタイミング】

• パイプラインの進行を一時停止し、指定されたユーザーの承認を待つ。
• 承認が拒否された場合、パイプラインは失敗として扱われる。

【有効なユースケース】

ユースケース	説明
コードレビュー	ステージ進行前にコードの内容を確認・承認する必要がある場合
リリース承認	本番環境へのデプロイ前にリリース責任者の承認が必要な場合
テスト結果の確認	自動テスト後に結果を人が確認してから次のステージへ進めたい場合

◇カスタムアクション

[情報を展開する]

企業独自のリリースフローや検証ステップをCodePipelineへ柔軟に統合可能にできる。

・CodePipelineは標準でビルド・テスト・デプロイなどの複数のアクションを提供する。
・標準アクションに含まれていない独自のビルドプロセスやテストスイートを統合する場合に、カスタムアクションが有効。

【実装方法】
①AWS CLIを使用して、パイプラインにカスタムアクションを作成・追加。
②作成されたカスタムアクションは、AWSアカウントに関連づけられたパイプラインに組み込まれる。

◇属性

[情報を展開する]

属性名	説明
パイプライン名	パイプラインの一意な識別名。
ステージ	ソース、ビルド、テスト、デプロイなどの処理単位。最低2つ必要（ソース＋ビルドまたはデプロイ）。
アクション	各ステージ内で実行される具体的な処理（例：CodeBuild、CodeDeploy、承認など）。
アーティファクト	ステージ間で受け渡される成果物（ZIPファイルやイメージなど）。S3に保存される。
トリガー	パイプラインの起動契機。EventBridge、Webhook、ポーリングなどが利用可能。
IAMロール	CodePipeline が他の AWS サービスにアクセスするための権限。
暗号化キー	アーティファクトの暗号化に使用される AWS KMS キー。
アーティファクトストア	アーティファクトを保存する S3 バケットの場所。
RunOrder	同一ステージ内でのアクションの実行順序。並列実行も可能。 ・デフォルト値は 1。 1以上の自然数のみ使用可能（0、負の数、分数などは無効）。 〇シリアル実行：アクションを順に実行するには、順番に大きい数値を割り当てる。 例：アクションA＝1、アクションB＝2、アクションC＝3。 〇並列実行：同じ runOrder 値を使うことで、同じステージ内の複数アクションを同時に実行可能。 例：アクションA＝1、アクションB＆C＝2 → BとCは同時に開始。
変数	パイプラインレベルで定義できるカスタム変数。V2 パイプラインで利用可能。

CodeArtifact
【共有リポジトリ】

【オペレーションのオーバーヘッドを削減する】
・アーティファクトリポジトリの管理に、必要なインフラストラクチャをセットアップして運用する必要がない。

・一般的に使用されるパッケージマネージャーや各種のビルドツール (Maven、Gradle、npm、yarn、twine、pip、NuGet) で動作するため、既存の開発ワークフローに簡単に統合できる。

◇構造

[情報を展開する]

（ドメイン＞リポジトリ＞アセット）

ドメイン	CodeArtifact の最上位のエンティティ。ドメイン配下に複数のリポジトリを持つことが出来る。
リポジトリ	各アセットのバージョンセットが保存される。1 つのリポジトリにはサポートされる全てのタイプのパッケージのエンドポイントを提供。
アセット	ドメイン内のアセット (パッケージ) は KMS の暗号化キーで暗号化される。すべてのアセットとメタデータはドメインに保存される為、複数のリポジトリに同じアセットが存在する場合、アセットはドメインに 1 つだけ保存される。

◇機能性

[情報を展開する]

パッケージ化したものを配布	PyPI（Python Package Index）, pip, npm, mavenなど
パッケージ管理	※ソフトウェア＝ソフトウェアパッケージ ・更新やサーバーの管理は不要。 ・ソフトウェアと依存関係をパブリックなアーティファクトリポジトリから自動的にフェッチできるため、デベロッパーに最新バージョンを提供できる。 ・管理者はソフトウェアを承認し、組織全体への配布を制御できる。 ・数回クリックするだけで、中央リポジトリをセットアップできる。 ・IAM をサポートしており、IT リーダーは AWS アカウント全体のさまざまなチームに適切なレベルのアクセス権を付与できる。

Code Commit
【ソースコード管理】

・AWS特有の完全マネージド型サービスなため、Gitをホスティングするサーバの構築は不要。

・CodeCommit リポジトリのトリガーを作成して、リポジトリのイベントから Lambda 関数を呼び出すことができる。

リポジトリ	ソースコードや構成ファイルなどのバージョン管理を行う中心的な場所。
機能ブランチ	別のパイプラインを作成し、テストされたコードを本番環境にマージする機能を支援する。
Git	ソースコードや設計書等のドキュメントの変更履歴を記録して管理する、オープンソースの分散型バージョン管理システム（対象ユーザは、主にソフトウェア開発者）
feature ブランチ	主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにfeature ブランチを作成し、作業を行う。

【仕様】

・共同でのソフトウェア開発向けに設計されている。

・コードのアップロード、履歴の確認,ソースのプレビュー、ブラウザ上での編集、プルリクエスト、ブラウザ上でレビューコメント、承認ルールの設定が可能。

・複数のファイルにわたる変更を一括管理でき、並行分岐化、（S3のみ）バージョン比較（diffing）を利用できる。

【セキュア性】

・CodeCommitにアクセスする際にAWSのユーザーIDとPWが求められる。

・CodeCommit リポジトリ内のデータは、転送中と不使用時のいずれも暗号化される。

・クラウド内のアセット（ドキュメント、ソースコード、バイナリファイルなど）を非公開で保存及び管理できる。

◇管理ポリシー

[情報を展開する]

ポリシーの目的	特定のブランチ（例：master）に対して変更を拒否するためのDenyポリシーの設定方法を紹介。

【ポリシーの目的】

• 特定のブランチ（例：master）に対して変更を拒否するためのDenyポリシーの設定方法を紹介。

【操作手順の概要】

• MyDemoRepoという名前のリポジトリを例に、masterブランチへのPushを拒否するポリシーを作成。
• AWS CodeCommitのコンソール画面から設定を行う流れが示されている。

【ポリシーの効果】
指定ブランチに対する意図しない変更やPushを防止でき、リポジトリの安定性・セキュリティを維持可能。

CodeBuild
【コードのテスト】

ソースコードを受け取り、それを仕様書（buildspec.ymlファイル）に基づいて、ビルド環境（イメージ）を構築し、問題がないかテストを行う。
※EFSファイルシステムをサポート

●ビルドバッジ
プロジェクトの最新のビルドのステータスを表示する。このイメージにアクセスするには、CodeBuild プロジェクトに対して生成されるパブリックアクセス可能な URL を使用する。そのため、誰でも CodeBuild プロジェクトのステータスを確認できる。ビルドバッジにはセキュリティ情報が含まれないため、認証は不要です。

【順序】
①ソースコードの編集とアップロード（CodeCommitにプッシュ）
②buildspec.ymlファイルの作成とアップ（CodeCommitにプッシュ）
③ビルドプロジェクトを作成（CodeBuild上で作成）
④ビルドを開始する（CodeBuild）

• BuildSpecファイル
  yaml形式で記述されたAWS CodeBuildの設定ファイル。
  ここで記述された設定がAWS CodeBuildによってビルドされる。この設定ファイルの問題を確認するには、AWS CodeBuildビルドをローカルで実行する。
  ローカルで実行することで、BuildSpecファイルで記述した設定がどのようにビルドされるかローカル環境でテストすることができる。これにより、BuildSpecファイルにおける問題をローカル環境で確認することができる。

【CodeBuild へアクセスする際は認証情報が必要】

• Amazon S3：ビルドアーティファクトの保存と取得
• Amazon CloudWatch Logs：ビルドのログ表示

◇プロパティ

[情報を展開する]

on-failure	フェーズ中に障害が発生した場合に実行するアクションを指定する。 ・ABORT：ビルドを中止する ・CONTINUE：次のステップに進む

◇テストレポート

[情報を展開する]

buildspec.yml によるテストレポート生成が可能。
・ビルド仕様ファイル（buildspec.yml）内でテスト実行後にサポート内の形式で結果を出力
・出力されたレポートを CodeBuild が自動的に読み取り、テストレポートグループを生成できる
・生成されたレポートは CodePipeline 上でビルドアーティファクトとともに簡単に確認可能

●レポートグループ
テスト結果の詳細な分析や、プロジェクトにおけるテストカバレッジの追跡に特化しており、開発チームがテスト結果をより効果的に評価し、アプリケーションの品質を改善するための洞察を提供する。

【サポートされるテストレポート形式】

• Cucumber JSON (.json)
• JUnit XML (.xml)
• NUnit XML (.xml)
• NUnit3 XML (.xml)
• TestNG XML (.xml)
• Visual Studio TRX (.trx)

◇キャッシュ機能

[情報を展開する]

プロジェクトのビルド時間を節約できる。キャッシュには、ビルド環境の再利用可能な部分を保存し、複数のビルドで使用できる。

AmazonS3またはローカルの2種類のキャッシュがある。

項目	Amazon S3 キャッシュ	ローカルキャッシュ
キャッシュ更新	Amazon S3(リモートストレージ)	CodeBuildのローカル環境（ビルドコンテナ付き）
データ取得方法	ネットワーク経由で取得	ローカルストレージから直接取得
転送速度	ネットワークの状態に依存	高速で安定している
依存関係取得時間への影響	転送時間がかかるため改善効果は限定的	取得時間を大幅に削減し、ビルドのパフォーマンスが向上
適用場面	低頻度のビルドやネットワークコストを重視する場合	頻繁なビルドや依存関係が多い場合に最適

CodeDeploy
【自動デプロイ】

ビルドした、EC2、オンプレミスインスタンス、サーバーレス Lambda 関数、または ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービス。
※インフラではなくアプリケーション向け

アプリケーションを構成している「ファイル群」をステージング環境や本番環境といった「グルーピングされたサーバー群」に定められた手順で自動配置するサービス。

【デプロイイベントのシーケンス】
[デプロイ] -> [テスト] -> (成功した場合) -> [手動の承認通知]

※CloudFormation のデプロイとテストのオプションを提供しない

• CodeDeploy エージェント
  インスタンスにインストールして設定すると、そのインスタンスを CodeDeploy デプロイで使用できるようにするソフトウェアパッケージ。

• デプロイグループ
  デプロイ中に使用される設定と構成が含まれる。
  ほとんどのデプロイグループ設定は、アプリケーションで使用されるコンピューティングプラットフォームによって異なる。ロールバック、トリガー、アラームなどの一部の設定は、どのコンピューティングプラットフォームのデプロイグループでも設定できる。

◇App Spec

[情報を展開する]

Lambdaのバージョンを管理することができる。

AppSpec file (Application Specification File)	CodeDeployがEC2インスタンスに対して、 S3 または GitHub にあるアプリケーションのリビジョンをどのようにインストールするか決定する、YAML フォーマットのファイル。 ※appspec.yml として、ルートディレクトリに配置される。 また同様に、デプロイの様々なライフサイクルイベントをフックして処理を実行するか決定する。 ・この要件を満たしていない場合、デプロイは失敗する。 ・AppSpec ファイルが既に存在する場合は、これを含めたデプロイ用のコンテンツを .zip (Windows Server 以外は .tar および .tar.gz も可能) 形式の圧縮ファイルにできる。
hooks (ライフサイクルフック) ※Lambda デプロイ向け	それぞれのフックは AppSpec ファイルで定義され、デプロイの特定タイミングで 1 回だけ実行される。 ・Before Allow Traffic デプロイされた Lambda のバージョンにトラフィックを流す「前」に呼び出される。 ・After Allow Traffic トラフィックをデプロイ済みバージョンに流した「後」に呼び出される。

〇デプロイ方法

[情報を展開する]

【インプレースデプロイ】
既存インスタンス上でアプリを停止して、直接デプロイ。
追加リソース不要。ダウンタイムが抑え、コストは低いが、可用性に注意。

デプロイ方式	概要	適用対象
OneAtATime （ローリング）	1台ずつ順番にデプロイ。最も安全、障害の影響を最小化。 ダウンタイムを抑えつつ徐々に更新。本番環境での慎重な更新に向いている。	EC2 / オンプレミス
HalfAtATime	インスタンスの半分ずつデプロイ。バランス型、安全性と速度の中間。 中規模な本番環境に向いている
All-at-once （一斉デプロイ）	全インスタンスに一度に新バージョンを展開。 シンプル・高速だが、失敗時の影響が大きい。（テスト環境や緊急修正）	EC2 / Lambda / ECS

【その他デプロイ方式】

デプロイ方式	概要	適用対象
Blue/Green （ブルーグリーン）	新環境（Green）を構築し、旧環境（Blue）から切り替える。本番稼働用トラフィックを送信する前にサービスの新しいデプロイをテストする。ダウンタイムなし、ロールバックが容易。	ECS / Lambda（疑似的）
Canary （カナリア）	一部ユーザーに新バージョンを提供し、検証後、段階的に拡大する。 影響を最小限に抑えつつ安全にリリース。	Lambda / ECS / ECS(Blue/Green)
Linear （線形）	トラフィックは毎回同じ間隔(分)の等しい増分で段階的に移行する。 安定したリリースが可能、時間はかかる。（例：10%ずつ5分ごとに移行） 増分ごとに移行するトラフィックの割合(％)と、増分間の間隔(分)を指定可能。	Lambda / ECS / ECS(Blue/Green)

[引用サイト]

〇ライフサイクルイベント

[情報を展開する]

フックして差し込む1つ以上のスクリプトを指定する。
hooks セクションは、何らかの処理を追加したい場合のみ指定する。

ApplicationStop	前回のリビジョンのシャットダウンが開始したとき(フック可能)。
DownloadBundle	AWS CodeDeploy Agent がリビジョンをCドライブの[Archiive]階層にコピーしたあと(フック不可能)。
BeforeInstall	AWS CodeDeploy が files セクションで指定された場所にファイルをコピーする前(フック可能)。ファイルの復号や現在のバージョンのバックアップの作成などの事前インストールタスクに使用。
Install	CodeDeploy が files セクションで指定された場所にファイルをコピーするとき(フック不可能)。
AfterInstall	CodeDeploy が files セクションで指定された場所にファイルをコピーした後(フック可能)。 アプリケーションの設定やファイルのアクセス権限の変更などのタスクに、このデプロイライフサイクルイベントを使用。
ApplicationStart	アプリケーションのリビジョンが開始する直前(フック可能)。
ValidateService	サービスの検証が終わった後(フック可能)。

◇環境変数

[情報を展開する]

環境変数名	説明
DEPLOYMENT_ID	現在のデプロイメントの一意なID
DEPLOYMENT_GROUP_NAME	実行中のデプロイメントグループ名（例：prod-group）
APPLICATION_NAME	デプロイ対象のアプリケーション名
LIFECYCLE_EVENT	実行中のライフサイクルイベント（例：BeforeInstall）
SCRIPT_NAME	実行中のスクリプト名
REVISION_DIR	アプリケーションのリビジョンが展開されたディレクトリ
DEPLOYMENT_TYPE	デプロイの種類（IN_PLACE または BLUE_GREEN）

GitHub関係

Webhook	GitHub上のイベント（例：push、pull request）を外部サービスに通知する仕組み。リポジトリで特定のイベントが発生したときに、指定した外部URLにHTTP POSTリクエストを自動送信する仕組みです。CI/CDやSlack通知、外部API連携などに非常に便利。
WebSocket	クライアントとサーバー間で双方向・常時接続の通信を可能にするプロトコル。

Device Farm

• 物理的なスマートフォンやタブレット（iOS・Android）**をクラウド上で利用可能。
• Webアプリケーションも複数のブラウザ環境でテストできる。
• エミュレータではなく、実機での動作検証が可能なため、より現実的なテストができる。

【主な機能】

• 自動テストの実行：Appium、Calabash、Espresso などのフレームワークに対応。
• 手動テスト（リモートアクセス）：ブラウザ上で実機を操作可能（スワイプ、ジェスチャーなど）。
• テスト結果の取得：動画、ログ、スクリーンショットなどを自動生成。
• CIツールとの統合：Jenkins や Android Studio などと連携可能。
• プライベートデバイスラボ：専用デバイスを予約して使用することも可能。

【利点】

利点	説明
実機での検証	顧客と同じ端末での動作確認が可能。OSやファームウェアの違いも考慮できる。
不具合の再現と修正	手動操作でバグを再現し、自動テストで修正サイクルを高速化。
ユーザー環境の再現	ネットワーク、位置情報、言語などを細かく設定して実環境をシミュレート。
テストの柔軟性	組み込みテストスイートまたはオープンソースフレームワークを選択可能。
スケーラブルな実行	複数のブラウザやデバイスで並列テストが可能。従量課金制でコスト最適化。

Signer

• 目的：コードの整合性と信頼性を保証するために、デジタル署名を付与するサービス。
• 対象：Lambda関数、IoTデバイス（Amazon FreeRTOS）、コンテナイメージなど。
• 仕組み：署名プロファイルを作成し、コードに署名。署名されたコードのみが実行可能になるよう制御できる。

【主な機能】

機能	説明
コード署名	LambdaやIoTデバイス向けのコードに署名を付与。
署名プロファイル	署名のルールや有効期限を定義。IAMロールで署名権限を制御。
CloudTrail連携	署名操作の監査ログを取得可能。
検証ポリシー	署名されていないコードの扱いを「警告（Warn）」または「拒否（Enforce）」で設定可能。

【メリット】

• セキュリティ強化：改ざんされたコードの実行を防止。
• コンプライアンス対応：署名履歴の監査が可能。
• 職務分離：管理者と開発者の権限を明確に分離。