Amazon Web Services ブログ
Amazon CodeCatalyst による開発環境の管理
訳者注）このブログは CodeCatalyst の代表的な使い方を説明する全 5 回のブログ記事のうち 3 回目にあたります。最初の記事は「Amazon CodeCatalyst を用いたワークフローによるビルド、テスト、デプロイの実現」です。
Amazon CodeCatalyst 開発環境は、CodeCatalyst で利用できるクラウドベースの開発環境で、プロジェクトのソースリポジトリに保存されているコードに対してすばやく作業することができます。開発環境に含まれるプロジェクトツールとアプリケーションライブラリは、プロジェクトのソースリポジトリにある devfile によって定義されます。
はじめに
前回の CodeCatalyst の記事「Amazon CodeCatalyst を用いたチームコラボレーション」では、CodeCatalyst のコラボレーション機能と、それが The Unicorn Project の主人公とどのように関係しているかに焦点を当てました。第 2 章の冒頭で、Maxine は開発環境の設定に苦労しています。彼女は新しい仕事に就いて 2 日になりますが、まだアプリケーションコードを作成できません。彼女は不足している依存関係を 100 件以上特定しました。ドキュメントは古く、依存関係がどこに保存されているのか誰も知らないようです。私は Maxine に同情します。この投稿では、開発環境の管理に焦点を当てて、CodeCatalyst がワークロード固有の構成を管理する負担を軽減し、信頼性の高いオンデマンド開発環境を構築する方法を紹介します。
前提条件
このチュートリアルに沿って進めたい方は、以下のものが必要です。
- CodeCatalyst にサインインするための AWS Builder ID を持っていること。
- スペースに所属し、そのスペースの管理者ロールが自分に割り当てられていること。詳細は、「Amazon CodeCatalyst でのスペースの作成」、「スペースのメンバーの管理」、「スペース管理者ロール」を参照してください。
- スペースに関連付けられた AWS アカウントを持ち、そのアカウントで IAM ロールを持っていること。ロールとロールポリシーの詳細については、「CodeCatalyst サービスロールの作成」を参照してください。
チュートリアル
CodeCatalyst シリーズのこれまでの記事と同様に、Modern Three-tier Web Application ブループリントを使用します。ブループリントにはサンプルコードと CI/CD ワークフローが用意されているため、プログラミング言語とアーキテクチャのさまざまな組み合わせを簡単に開始できます。手順をたどるには、以前に作成したプロジェクトを再利用するか、ブループリントを使用してプロジェクトを作成する手順を説明したドキュメントを参照してください。
私が開発者として過ごした時間の中で最も困難だったのは、新しいプロジェクトにすばやく貢献する方法を見つけることでした。新しいプロジェクトに参加するときはいつも、実際にコードを書くことよりも、プロジェクトのコードベースに有意義に貢献できるようになることの方がずっと困難でした。この非効率性の主な原因は、ローカル開発環境を管理するプロセスが不足していたことです。今回は、CodeCatalyst がこの課題の解決にどのように役立つかを探ります。このチュートリアルでは、Amazon DynamoDB のローカルテストを可能にする新しいテストを追加したいと思います。これを実現するために、CodeCatalyst 開発環境を使用します。
CodeCatalyst 開発環境は、ソースリポジトリに保存されているコードにアクセスして変更するために使用できる、マネージドなクラウドベースの開発環境です。プロジェクト固有の開発環境を立ち上げて、プロジェクトのリポジトリのチェックアウトを自動化することも、空の環境を立ち上げてサードパーティのソースプロバイダーへのアクセスに使用することもできます。CodeCatalyst 開発環境の詳細については、CodeCatalyst ユーザーガイドをご覧ください。
図 1. 新しい開発環境を作成する
まず、ナビゲーションメニューの Code セクションにある Dev Environments ページに移動します。次に、Create Dev Environment を使用して、環境を起動します。この投稿では、AWS Cloud9 IDE を使用していますが、あなたが最も使いやすい IDE を使うこともできます。次の画面で、Work in New Branch を選択し、新しいブランチ名に local_testing を割り当て、main から分岐します。残りのデフォルトのオプションはそのままにして、Create を選択します。
図 2. 開発環境作成オプション
1 分も経たないうちに IDE が新しいタブに表示され、作業を開始する準備が整いました。開発環境で最初に表示されるのは、Dev Environment Settings に移動するかどうかを尋ねる情報ウィンドウです。自分だけでなく、このプロジェクトで共同作業する他の開発者のために DynamoDB のローカルテストを有効にする必要があるため、プロジェクトの devfile を更新する必要があります。設定タブに移動するのは、プロジェクトの devfile に関する情報が含まれていて、編集するファイルにアクセスできるからです。
図 3. ツールキットのウェルカムバナー
devfile を使用すると、開発環境の構成と依存関係をモデル化できるため、一貫した開発環境を再現でき、将来の環境を設定する際の手作業を減らすことができます。開発環境に含まれるツールとアプリケーションライブラリは、プロジェクトのソースリポジトリにある devfile によって定義されます。このプロジェクトはブループリントから作成されているため、devfile がひとつ用意されています。空白のプロジェクトの場合、環境を初めて起動したときにデフォルトの CodeCatalyst devfile が作成されます。devfile の詳細については、Devfile.io を参照してください。
設定タブの中に、設定されている devfile へのリンクがあります。編集ボタンをクリックすると、新しいファイルタブが開き、変更を加えることができます。まず、開発環境をホストするコンテナに env セクションを追加します。環境変数と値を追加すると、このプロジェクトのリポジトリから新しい開発環境が作成されるたびに、その環境変数が設定されます。次に、DynamoDB をローカルで実行する 2 つ目のコンテナを開発環境に追加します。これは、新しいコンテナコンポーネントを追加することで実現できます。私の環境では、Amazon の検証済み DynamoDB docker イメージを使用しています。追加のイメージをアタッチすることで、開発環境を拡張し、ローカルで利用できるツールやサービスを含めることができます。私の更新は、以下の緑色のセクションで強調されています。
図 4. devfile の例
変更を保存して、Dev Environment Settings タブに戻ります。変更が自動的に検出され、変更を有効にするために開発環境を再起動するように求められます。devfile を変更するには再起動が必要です。ツールキットまたは CodeCatalyst UI から開発環境を再起動できます。
図 5. 開発環境の設定
開発環境が再起動するのを数秒待った後、テストを書く準備ができました。IDE のファイルエクスプローラーを使用して、リポジトリの ./tests/unit フォルダを展開し、test_dynamodb.py というファイルを新規作成します。devfile で設定した IS_LOCAL 環境変数を使用して、Amazon の Python SDK ( Boto3 ) が DynamoDB サービスへの接続に使用するエンドポイントを設定する条件をテストに含めることができます。こうすることで、変更をプッシュする前にローカルでテストを実行しても、プロジェクトのワークフローでテストを正常に完了させることができます。私の完全なテストファイルは以下の通りです。
図 6. DynamoDB テストファイル
これで、devfile を使用して開発環境への変更を完了し、テストを追加したので、テストをローカルで実行して検証する準備ができました。変更をプッシュする前に、pytest を使ってテストがパスしていることを確認します。リポジトリのルートフォルダから、pip install-r requirements-dev.txt というコマンドを実行します。依存関係がインストールされたら、pytest -k unit というコマンドを実行します。すべてのテストが期待通りにパスしました。
図 7. Pytest のテスト結果
各環境に開発用の依存関係を手動でインストールする代わりに、devfile にコマンドを記述して、開発環境のライフサイクルイベント中にそれらのコマンドの実行を自動化することもできます。詳細については、コマンドとイベントのリンクを参照してください。
これで、変更を CodeCatalyst ソースリポジトリにプッシュする準備が整いました。Cloud9 の git 拡張機能を使用して変更を確認します。変更内容が期待通りであることを確認したら、git 拡張機能を使って新しいテストファイルと変更した devfile をステージング、コミット、プッシュし、他の共同作業者が私が行った改善を採用できるようにします。
図 8. CodeCatalyst Cloud9 の git 拡張機能でレビューされた変更点
クリーンアップ
このワークフローに従っている場合は、引き続き料金が発生しないように、デプロイしたリソースを削除する必要があります。まず、ブループリントを起動したときに関連付けた AWS アカウントの AWS CloudFormation コンソールを使用して CDK がデプロイした 2 つのスタックを削除します。これらのスタックには mysfitsXXXXXWebStack や mysfitsXXXXXAppStack などの名前が付けられます。次に、Project settings に移動し、Delete project を選択して、CodeCatalyst からプロジェクトを削除します。
まとめ
この投稿では、CodeCatalyst がどのように構成可能なオンデマンド開発環境を提供しているかを学びました。また、devfile が CodeCatalyst プロジェクト内での一貫した開発体験を定義するのにどのように役立つかについても学びました。CodeCatalyst が Maxine や他のビルダーの課題をどのように解決するかを引き続き探っていきますので、DevOps ブログチャンネルをフォローしてください。
この記事の著者について
この記事は Managing Dev Environments with Amazon CodeCatalyst を翻訳したものです。
翻訳は Solutions Architect の Ryotaro Tsuzuki が担当しました。