Amazon CodeCatalyst を用いたワークフローによるビルド、テスト、デプロイの実現

(この記事は Using Workflows to Build, Test, and Deploy with Amazon CodeCatalyst を翻訳したものです。)

Amazon CodeCatalyst ワークフローは、アプリケーションのビルド、テスト、デプロイを容易に行うことができる継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインです。CodeCatalyst は re:Invent 2022 で発表され、現在（2023年2月17日）プレビュー版となっています。

はじめに

最近、Gene Kim のベストセラータイトル「The Phoenix Project」の続編である「The Unicorn Project」を読みました。アマゾンで数年働いた後、私はいくつかの会社でどのようにソフトウェアが書かれているかを忘れていましたが、読んでいるうちにすべてが蘇ってきました。この本の中で、主人公の Maxine は、新しいチームに参加した後、複雑なソフトウェア開発ライフサイクル（SLDC）に苦しめられます。彼女が遭遇する課題には、次のようなものがあります。

• 高品質なアップデートを継続的に提供することは複雑で時間がかかる
• 他者との効率的なコラボレーションが難しい
• アプリケーション環境の管理は複雑さを増していく
• 新しいプロジェクトの立ち上げに時間がかかる

Amazon CodeCatalyst は、これらの問題すべてを支援することができます。CodeCatalyst は、開発チームが AWS 上でアプリケーションを迅速に構築し、提供することを容易にする、統合された DevOps サービスです。今後数週間にわたり、私と同僚は、CodeCatalyst の個々の機能と、それらがどのように The Unicorn Project で Maxine が遭遇した課題の克服に役立つかを説明する一連のブログ記事を公開する予定です。この最初の投稿では、ワークフローに焦点を当て、上記の箇条書きの最初にある「高品質なアップデートを継続的に提供することは複雑で時間がかかる」を取り上げます。

CodeCatalyst のワークフローは、高品質なアプリケーションの更新を頻繁に、素早く、安全に配信することを可能にします。CodeCatalyst は、ビジュアルエディタ（または YAML）を使用して、CI/CD パイプライン、テストレポートの作成、その他の手動プロセスを自動化するワークフローをすばやく組み立て、設定することができます。ワークフローは柔軟性を犠牲にすることなく簡単に拡張することができるよう、プロビジョニングされたコンピュート、Lambda、カスタムコンテナイメージ、ビルドのためのマネージドサービスを使用します。

前提条件

このチュートリアルに沿って進めたい方は、以下のものが必要です。

• CodeCatalyst にサインインするための AWS Builder ID を持っていること。
• スペースに所属し、そのスペースの管理者ロールが自分に割り当てられていること。詳細は、「Amazon CodeCatalyst でのスペースの作成」、「スペースのメンバーの管理」、「スペース管理者ロール」を参照してください。
• スペースに関連付けられた AWS アカウントを持ち、そのアカウントで IAM ロールを持っていること。ロールとロールポリシーの詳細については、「CodeCatalyst サービスロールの作成」を参照してください。

チュートリアル

このチュートリアルでは、Modern 3-tier Web Application ブループリントを使用します。CodeCatalyst ブループリントは、新しいプロジェクトのテンプレートを提供します。以下に沿って進める場合、「Amazon CodeCatalyst でのスペースの作成」で説明されているとおり、ブループリントを起動することができます。 これにより、以下に示すアーキテクチャがデプロイされます。

図1. プレゼンテーション層、アプリケーション層、データ層を含むモダン3層ウェブアプリケーションアーキテクチャ

新しいプロジェクトを立ち上げたら、CI/CD > Workflows に移動します。2 つのワークフローが表示されているのがわかると思います。ApplicationDeploymentPipeline をクリックすると、下の写真のようなワークフローが表示されます。ワークフローは6つのアクションで構成されています。1) CDK がアカウントに設定されていることを確認し、2) Python で書かれたバックエンドをユニットテストを含めてビルドし、3) プロジェクトを立ち上げたときに選択した AWS Lambda または AWS Fargate にバックエンドをデプロイし、4) デプロイしたバックエンドで一連の統合テストを実行し、5) Vue で書かれたフロントエンドをユニットテストを含めてビルドし、最後に6) Amazon Simple Storage Service (Amazon S3) および Amazon CloudFront にフロントエンドをデプロイします。

図2. 前項で説明した6ステップのワークフロー

これらのアクションのいくつかを見てみましょう。各アクションをクリックすると、ワークフローの実行に関する詳細が表示されます。例えば、build_backend をクリックしてみましょう。logs タブで、build アクションが一連のステップを実行するのがわかります。この例では、pip が要件をインストールし、pytest と coverage が一連のユニットテストを実行しています。もしこれが Java や .NET のようなコンパイル型言語であれば、同様にビルドステップがあります。

図3. pip、pytest、coverage を含むビルドアクションからのログ

レポートタブに切り替えると、単体テストの結果だけでなく、コードカバレッジとブランチカバレッジも表示されます。それぞれのケースでテストの結果はグラフの黒い棒で示された合格基準を超えています。もしそうでなければ、ビルドは失敗しています。

図4. コードカバレッジとブランチカバレッジを含むユニットテストの結果

次に、画面右上の「Edit」ボタンをクリックして、ワークフローがどのように定義されているかを検証してみましょう。エディタが YAML モードで開いた場合、コードの上にあるトグルを使って Visual モードに切り替えます。WorkflowSource をクリックすると、ワークフローはメインブランチへのプッシュがトリガーになっていることがわかります。さらにトリガーを追加することもできます。CodeCatalyst は、Push または Pull Request によるトリガーをサポートしています。さらに、ワイルドカード（例："release-."）を含む複数のブランチをトリガーすることができます。最後に、リポジトリ内の一部のファイルだけが変更されたときにブランチをトリガーすることもできます（例："src/."）。

図5. 様々なオプションを表示したトリガー設定

では、build_and_test_frontend アクションを見てみましょう。これはビルドアクションで、先ほど見た build_backend アクションと同じです。Configuration タブには、ビルド中に実行される Shell commands が表示されます。フロントエンドは Vue を使って書かれています。ここでは、依存関係をインストールするために npm install が、テストを実行するために npm run test:unit が、そして最後にシングルページアプリケーション (SPA) をビルドするために npm run build-only が使用されているのがわかります。できあがった成果物は、ワークフロー内の後続のアクションに渡されます。

図6 ビルドアクションで実行する Shell commands

次に、integration_tests アクションを見てみましょう。テストアクションはビルドアクションに非常に似ていて、実行する一連のコマンドを定義するようになっています。configuration タブ（表示されていません）で、このアクションが再び pytest を実行していることがわかります。Outputs タブに切り替えると、CodeCatalyst は pytest や他のテストフレームワークによって生成されたテストレポートを自動的に検出するように構成されていることがわかります。さらに、成功率の基準を 100% と定義しています。これは、統合テストのいずれかが失敗した場合、ワークフローが失敗することを意味します。

図 7. 成功基準を含むテストレポート設定ダイアログ

最後に、Deploy_Frontend アクションを調べてみましょう。これまで見てきたすべてのアクションは、その設定に実行する一連のコマンドを含んでいることに注意してください。これらのアクションは非常に柔軟性がありますが、CodeCatalyst は他にも様々なアクションもサポートしています。例えば、cdk-deploy アクションはその一例です。その名の通り、このアクションは AWS Cloud Development Kit (CDK) のリソースをデプロイするものです。ビルドアクションのシェルコマンドから cdk deploy を呼び出してもいいのですが、cdk-deploy アクションを使う方が簡単です。CodeCatalyst は AWS だけでなく、サードパーティが開発した多くのアクションをサポートしています。画面左上の + をクリックすると、いくつかの例を確認することができます。さらに、CodeCatalyst は GitHub Actions もサポートしていますが、これについては別の記事で紹介します。

クリーンアップ

このチュートリアルに従っていた場合、引き続き料金が発生しないように、デプロイしたリソースを削除する必要があります（詳細は価格ページを参照してください）。まず、ブループリントを起動したときに関連付けた AWS アカウントで、CDK が AWS CloudFormation コンソールを使用してデプロイした 2 つのスタックを削除します。これらのスタックは、mysfitsXXXXXWebStack や mysfitsXXXXXAppStack のような名前を持っています。次に、Project settings に移動して Delete project ボタンをクリックし、CodeCatalyst からプロジェクトを削除します。

まとめ

この記事では、ビルド済みのアクションを CI/CD パイプラインに構成することで、CodeCatalyst が自動化ワークフローを迅速に構築するのに役立つことを学びました。フロントエンドとバックエンドのアプリケーションをビルド、テスト、デプロイするためのアクションを確認しました。今後の記事では、Maxine が The Unicorn Project で遭遇した残りの課題に CodeCatalyst がどのように対処できるかを説明します。

この記事の著者について

翻訳はパートナーソリューションアーキテクト田中（創）が担当しました。原文はこちらです。