はじめに
今回は、昨年11月28日に発表された、Amazon CodeCatalyst での Amazon Q (プレビュー) の機能開発機能を試してみました。
Announcing feature development capability of Amazon Q (Preview) in Amazon CodeCatalyst
上のリリース本文を翻訳したものがこちら↓です。
本日、Amazon CodeCatalyst で Amazon Q の機能開発機能のプレビュー版が利用可能になったことをお知らせします。
この新機能により、開発者は CodeCatalyst の問題を Amazon Q に割り当てることができ、
Q は人間のプロンプトを実行可能な計画に変換するという面倒な作業を実行し、コードの変更とリクエスタに割り当てられたプルリクエストを完了します。
その後、Q は関連するワークフローを監視し、問題の修正を試みます。
ユーザーはコードの変更をプレビューし、プルリクエストをマージできます。
開発チームは、IDE に入らなくても、この新機能を Amazon CodeCatalyst 内のエンドツーエンドの合理化されたエクスペリエンスとして利用できます。
・・・！？
IssueをAmazon Qに割り当てたらコードを自動変更してプルリクエストを作成・・・？
最初聞いたときは何を言っているんだ？という気持ちでしたが、試してみたい魔力があります。
環境が準備できたのでまずは体験してみます。
前提条件
- Amazon CodeCatalystのAmazon Q統合は現在オレゴンリージョンのみ利用できます。
- CodeCatalystの料金プランがStandard Tier以上で利用できます。（月4ドル/人掛かります。）
- 1人あたり、月15回まで料金プラン枠内でAmazon Q統合を試せるようです。
事前準備
事前にWorkflowsの画面から、git pushしたらcdk deployをするワークフローを作成しておきます。
Issue 1
cdk-sampleという名前のリポジトリ内にcdk initで作成したコードを利用し、そこにアカウント内のS3バケットの一覧を取得するLambda関数を作成してみます。
Issue 1:指示出し
Amazon Qは現時点では日本語に対応していないため、Issueも英語で書きます。
今回は下記のようなタイトル・本文を記載しました。
| 言語 | 日本語 | 英語 |
|---|---|---|
| タイトル | Lambda関数を作成 | Create Lambda function |
| 本文 | アカウント内のS3バケットの一覧を取得するLambda関数を作成してください。 言語：Python リポジトリ：cdk-sample スタック：SampleAppStack内 |
Create a Lambda function that retrieves the list of S3 buckets in your account. Language: Python Repository: cdk-sample Stack: Inside SampleAppStack |
Issue 1:Amazon Qを担当者に設定
以下のようなIssueを作成します。
Amazon Qにアサインするには、Assigneesの「＋Assign to Amazon Q」をクリックします。
Assign to Amazon Qを押した後はこのように、Amazon Qにアサインされます。
Issueができました！右下に、Amazon Qにアサインされていることを示すマークが出ていますね。
Issue 1:Amazon Qから問い合わせが
Issue作成して2分ほどで、Amazon Qからコメントが来ました。
※長いので和訳版を記載します。原文は和訳の下に折りたたみで記載します。
和訳表示
原文
これは定型的な質問のようです。以下のような内容ですね。
- 対話的に行うために各ステップで止めることがあるけど良い？
- ワークフローのファイルの変更権限はある？
- リポジトリはどれ？（今回、この環境に2つのリポジトリがあるせいだと思います。）
リポジトリを正しく選び、ほかは「はい」で進めます。
Issue 1:数分待ったら、また確認が
指示したLambda関数作成についての修正方針を提案してくれています。
和訳表示
原文
簡潔にまとめると下記のような修正を行うようです。
- 1.スタックの修正
- 必要なライブラリのimport
- Lambda関数を定義
- 2.Lambda関数自体の作成
- 3.テストコードの作成
- 4.1で定義したLambda関数に情報付加
非常に丁寧ですね。これは期待できそう。
Proceed（進む）を押すことで、その後の修正処理を開始します。
Issue 1:プルリク作成！（わずか6分で）
プルリクが来ました！本当にIssueだけでコード修正がなされるとは・・・
右の方 Pull Requestのところにプルリクがオープンされていることが確認できます。
プルリクの本文は先程出た修正方針と同じ模様です。
コードが修正されてます！
今回はテストなのでAmazon Qを信じて承認・マージしてみましょう。
Mergeを押下
右下のMergeを押下
Issue 1:ワークフローが起動
リポジトリにマージされたので、先に定義しておいたワークフローが起動しました。
Issue 1:ワークフローでエラー発生
おっと、デプロイでエラーが発生しました。
インポートエラーが複数出ております。
Cloud9でコードを見てみます。
確かにlambdaやiamのインポートがなく、エラーが出ております。
LambdaとIAMのimportが無いとのこと。
修正方針を改めて読むとS3しかインポートしてませんね。これはいけません。
では、せっかくなのでこのエラーをトリガーに新しいIssueを作成して修正してもらいましょう。
Issue 2
先程出たパイプラインのエラーコードをそのまま記載し、
下記のインポートエラーを解決してくださいというタイトル・本文でIssueを起票します。
Issue 2:修正方針の確定
今回の指示範囲外の修正が入っていたのでそこはやらなくて良いという指示をReplyで出しました。
対話的に変更できるのは良いですね。
アプローチを再検討してくれて、最終的に下記のような編集方針となりました。
- 1.スタックにLambdaとIAMのインポートを追加します
- 2.testのsample-app-stackは変更しません
- 3.新しい関数は追加されません。IAMなども再利用します
- 4.新しいテストは追加しません
今回指示したimportのみ直してもらいます。
Issue 2:diff
数分後、プルリクが作成されました。指摘通りインポートが追加されています。
Issue 2:承認してデプロイへ
プルリクの承認によって自動的にパイプラインが起動します。
Issue 2:結果
Lambda関数が作成されました！
バケット一覧を取得するコードが書かれています。
無事、実行もできました！凄い！
ここまでのまとめ
- importの不備はありましたが、指定したLambda関数を作成するという大枠は作成されていたので凄いですね。
- 簡単な例とはいえ、人間には6分やそこらでこれだけのコード・説明を書いてプルリクまで上げるなんて困難なので、この効率化の効果は計り知れないですね。
Issue3
では、もっと大規模な修正ならどうなのでしょうか？
ちょっと無茶ですが、下記のような依頼を出してみます。
Lambda関数の実行に関連するリソースを大量に作成してもらいます。
| 言語 | 日本語 | 英語 |
|---|---|---|
| タイトル | Lambda実行用の監視とバックアップを作成 | Create Monitoring and Backup for Lambda Execution |
| 本文 | 以下の対応を行ってください。 ・getBucketsFunctionのLambda関数名をGetBucketsFunctionと設定 ・getBucketsFunctionの実行時ログ用のロググループ（/aws/lambda/GetBucketsFunction）を作成 ・getBucketsFunctionの実行時エラーをCloudwatchのメトリクスフィルタで検知し、Cloudwatch Alarmを発報。 ・Cloudwatch Alarmの宛先としてすでに作成されているSampleAppTopicを指定 ・上で作ったGetBucketsFunctionのログをKinesis Data Firehoseを利用してS3にバックアップ。バッファは900秒 ・S3は今回新しく作成すること(バケット名：amazon-q-kinesis-test-bucket) ・これらすべての対応をSampleAppStack内に作成する |
Please take the following actions. ・Set the Lambda function name of getBucketsFunction as GetBucketsFunction ・Create a log group (/aws/lambda/GetBucketsFunction) for the runtime log of getBucketsFunction ・Detect runtime errors in getBucketsFunction using Cloudwatch's metrics filter and issue a Cloudwatch Alarm. ・Specify the already created SampleAppTopic as the destination of Cloudwatch Alarm ・Back up the GetBucketsFunction log created above to S3 using Kinesis Data Firehose. Buffer is 900 seconds ・Create a new S3 this time (bucket name: amazon-q-kinesis-test-bucket) ・Create all these correspondences in SampleAppStack |
Issue 3:修正方針の確定
修正方針が作成されました。
和訳表示
原文
方向性は概ね問題ないですね。
初回同様、方針時点でimportがあったりなかったりするので嫌な予感が・・・
- 1.Lambda関数名の変更
- 2.MetricFilterの作成
- 3.Kinesis Firehoseによるバックアップ設定
- 4.S3バケットの作成
- 5.テストコードの追加
とりあえず進めてみましょう
Issue 3:技術的な問題
技術的な問題と出てきました。流石に1つのIssueの中で要求しすぎたでしょうか・・・
2回技術的な問題で失敗しましたが、その後数分待っていたら無事プルリクができました。
Issue 3:diff
全体的にはそれっぽくリソースが作られている気がしますが、
またimportが無いですね
テストコードは枠だけ。中身がないですね。
ダメそうなのはわかっていますが一応マージしてみると、やはりデプロイで失敗しました。
Issue4
今回もデプロイ時エラーを修正させてみましょう。
ついでに、テストコードについても一緒に依頼します。
| 言語 | 日本語 | 英語 |
|---|---|---|
| タイトル | インポートエラー | * Import Errors |
| 本文 |
インポートエラー（中略） テストコードの中身が書かれていません。テストコードを書いてください。 |
Import Errors TSError: ⨯ Unable to compile TypeScript: 401lib/sample-app-stack.ts(23,11): error TS7022: 'getBucketsFunction' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer. 402lib/sample-app-stack.ts(27,5): error TS2345: Argument of type '{ runtime: lambda.Runtime; code: lambda.AssetCode; handler: string; logGroupName: string; const: any; new: any; getBucketsFunction: any; "": any; }' is not assignable to parameter of type 'FunctionProps'. 403Object literal may only specify known properties, and 'logGroupName' does not exist in type 'FunctionProps'. 404lib/sample-app-stack.ts(29,9): error TS2304: Cannot find name 'metricFilter'. 405lib/sample-app-stack.ts(29,28): error TS2304: Cannot find name 'cloudwatch'. 406lib/sample-app-stack.ts(30,15): error TS2448: Block-scoped variable 'getBucketsFunction' used before its declaration. 407lib/sample-app-stack.ts(41,7): error TS2304: Cannot find name 'cloudwatch'. 408lib/sample-app-stack.ts(42,13): error TS2304: Cannot find name 'metricFilter'. 409lib/sample-app-stack.ts(48,9): error TS2304: Cannot find name 'firehose'. 410lib/sample-app-stack.ts(48,24): error TS2304: Cannot find name 'firehose'. 411lib/sample-app-stack.ts(51,18): error TS2304: Cannot find name 's3Bucket'. 412lib/sample-app-stack.ts(58,9): error TS2304: Cannot find name 's3Bucket'. 413lib/sample-app-stack.ts(58,24): error TS2304: Cannot find name 's3'. 414lib/sample-app-stack.ts(62,3): error TS2448: Block-scoped variable 'getBucketsFunction' used before its declaration. 415lib/sample-app-stack.ts(71,3): error TS2448: Block-scoped variable 'getBucketsFunction' used before its declaration. 416lib/sample-app-stack.ts(75,21): error TS2304: Cannot find name 'firehose'. 417lib/sample-app-stack.ts(29,3): error TS1005: ',' expected. 418lib/sample-app-stack.ts(29,9): error TS1005: ':' expected. 419lib/sample-app-stack.ts(39,5): error TS1005: ',' expected. 420lib/sample-app-stack.ts(41,7): error TS1005: ':' expected. 421lib/sample-app-stack.ts(46,5): error TS1005: ',' expected. 422lib/sample-app-stack.ts(48,9): error TS1005: ':' expected. 423lib/sample-app-stack.ts(56,5): error TS1005: ',' expected. 424lib/sample-app-stack.ts(58,9): error TS1005: ':' expected. 425lib/sample-app-stack.ts(60,5): error TS1005: ',' expected. 426lib/sample-app-stack.ts(62,21): error TS1005: ',' expected. 427lib/sample-app-stack.ts(69,6): error TS1005: ',' expected. 428lib/sample-app-stack.ts(71,21): error TS1005: ',' expected. 429lib/sample-app-stack.ts(78,6): error TS1005: ',' expected. The content of the test code is not written. Please write the test code. |
Issue4: 結果
途中経過はカットしますが、修正後でもこのように赤線だらけでした。
流石に一度に大量に要求しすぎたので反省です。これは手作業で魔改造が必要ですね。
テストコードもあまりうまく書かれていなかったので省略。
やってみてわかった良い点と課題
- 良い点
- コードの構成を理解して修正＋プルリク起票までしてくれるのはやはり驚き。
- 実験ケースではわずか6分ほどでコード修正まで完了。
- 最初に修正方針を出してくれるので自分の考える修正案と差異がないかチェック可能。
- 修正方針に対して返信を行い対応方法を変えてもらうことも可能。
- リポジトリの全体像を理解した上での修正案なのが凄い。
- プルリク上にも修正方針が記載されているので後から見やすい。
- コードの構成を理解して修正＋プルリク起票までしてくれるのはやはり驚き。
- 課題
- モジュールのインポートを忘れがち。
- あったりなかったりするので確認して指摘が必要。
- テストを書こうとはしているのにテストコードの中身をなかなか書いてくれない。
- 今回はすべてtestの枠だけになってしまった。
- テストコードを書いてくれたとしても、実行結果OKまでできてるかは不明。
- あくまで起票されるのはプルリクであるので、今回は実験のためそのままマージしてしてしまったが通常通りコードレビューは必須。
- プルリク上ではなく、Cloud9やVSCode上でのチェックをしたほうが良い。
- プルリク後の再修正はやってくれない模様。
- プルリクまで行くと担当者の割り当てからAmazon Qが外れ、その後返信によるやり取りができない模様。
- 今回は別Issueを起票することで対応。
- 現在プレビュー中のため月間の実行数制限（1ユーザーあたり15～20）がある。GA後は別課金になる模様。
- ワークフローの修正権限があるかを確認はしてくるが、今回の実験では特に修正されなかった。
- 日本語化を切望。（Amazon Q全体）
- モジュールのインポートを忘れがち。
おわりに
今回はAmazon CodeCatalystのAmazon Q連携を利用し、Issueからプルリクを作成してもらう操作を実際にやってみました。
Issueによるちょっとの依頼文だけでプルリクまで起票されるのは本当に驚きました。
修正内容には一部不備がありましたが、事前に提示された大まかな修正方針通りコードが修正され、
その後のプルリクエストの作成が自動化されるなど、効率的な開発が可能でした。
しかし、大規模な修正や要求はさすがに難しく、「技術的な問題」が発生するなどの珍しい？トラブルも体験できました。
とはいえ仕組みは素晴らしく、溜め込みがちなIssueを即対応に移せるのは長所であり、使い方次第で大きく化ける可能性を秘めている機能だと思います。
今後はまず小さなプロジェクトで開発環境をCodeCatalystに移してみて、どの程度活用を進められるか確認したいと思います。