基本リソース (iam など)、データ ウェアハウジング、ラムダ、sns、mongodb などのほとんどのサーバーレス リソースで構成される分散型アプリを AWS で構築しています。
これを OTAP 経由でデプロイするために、AWS ツールを検討しています。
これは、CodeCommit の 1 つのリポジトリが CodePipeline をトリガーし、これらのコンポーネントが適切な場所に配置されることを意味します (順序制御を実現します)。
- CF スタックのデプロイ
- CodeBuild を使用して SAM リソースをパッケージ化 (AWS sam パッケージ) -> SAM リソースごとに 1 つ
- ビルドステップを使用して変更セットを作成 -> SAM リソースごとに 1 つ
- ビルドステップを使用して変更セットを実行 -> 変更セットごとに 1 つ
例として、そのラムダの .js ファイルの横にあるすべてのラムダに buildspec.yml が必要です。また、ラムダは SAM テンプレート (独自のテンプレートまたはグループ化されたテンプレート) で構築する必要があります。また、それぞれの build-change-set ステップと execute-change-set ステップ。
私の質問: この設定で、分散アプリ全体の 1 つのリポジトリに対して、多くのラムダのうちの 1 つのタイムアウトのような小さなばかげたことを 1 つ変更した場合、これはアプリのすべての要素を再デプロイして再構築しますか?
いいえの場合、神に感謝しますが、どのように機能しますか? CodeCommit は、変更のみではなく、すべてのソースの zip 全体を S3 に送信します。そのため、すべての要素がトリガーされ、スタック (CF または SAM) の展開中に、基盤となる技術がスマートになり、変更が必要なことだけを行うことができます。それでも、CodePipeline のすべての要素 (および多数の要素) がトリガーされますが、これはデプロイ全体をできるだけ早く完了することが目標である場合には非効率的です。
はいの場合、それはまずいので、CodeCommit API からのみ変更を抽出するパイプラインでカスタム コード (ラムダ) を使用して別のソリューションを見つけ、cretae-change-set を実行して実行します。aws sdk を使用する主な欠点は、オン オーダー制御に屈することと、「aws sam パッケージ」などのいくつかのものを sdk で使用できないことです。