00:00
本番環境に変更を反映したいときは、デベロップからメインへまとめてマージするという運用です。 僕はいつも、推奨タスクは一周を切ってと依頼します。月が変わるまでの間は、常に擬音枠が足りないというエラーになります。
こんにちは、超実践AI論のたいちです。 今回は、現役エンジニアがAIを使ったアプリ開発の流れとブランチ戦略を解説というテーマでお話しします。
前回の動画で、Webコンテンツ分析アプリの要件定義書作成まで完了しました。 この動画を含むクロードコードを使ったアプリ開発の全工程は動画コースにしているので、全体を知りたい方は概要欄のリンクから見てみてください。
今回は、アプリの実装計画を基にアプリの基盤を整え、現役エンジニアの僕がどのようにブランチを運用しアプリ開発を進めていくのか、その流れを解説します。
では早速、前回作成したPR分割計画に則ってアプリを開発していきます。 最初のPR1番ではアプリの基盤を整えます。
ざっくり言うと、アプリで使うツールやプログラムのインストール、それからAgents.mdなどのAI向けの指示ファイルを整備します。
まずは、Cloudアプリを開いてCloudコードのモードにし、モデルはオーパス5.5、思考レベルは最大にします。
そして今回のフォルダを開いて、アットマークで先ほどのアプリの計画書にメンションします。
続けてこの計画書のPR1番に対応してという指示をします。
30分ほど経ってCloudコードの作業が完了したようなので早速見ていきましょう。
まずはCloudコードが解説しているやった作業の概要を眺めていきます。
特にここに書いてある主な判断や手元に影響する変更など、何かしらCloudが独自に決めたところは注意深く目を通します。
今回は特に問題なさそうです。次にPRを確認してみます。
PRの説明欄にもやった作業の内容が書かれているので目を通していきます。
PRの説明欄も一通り問題なさそうです。
僕はほぼ内容がわかっているので特に質問はしませんが、アプリ開発の初心者の場合は、
このMeansが何なのかとか、CIでPRが走るとはどういう意味なのかなど、
わからないことは一通りAIに質問して理解しておいたほうがいいです。
なぜならAIの作業内容を理解できないと、その作業が適切かどうかも判断できないからです。
PRの説明欄も問題なかったら次はPRの差分を見ていきます。
この差分には今回の作業でAIが対応したすべての修正が含まれます。
例えば最初のci.yamlというファイルはGitHub上でテストを実行するための設定です。
プロジェクト内の.githubワークフローズの中にyamlファイルを作成すると、
それがGitHubで動かすプログラムの設定ファイルになります。
このGitHubで動かすプログラムのことをGitHub Actionsと言います。
このGitHub Actionsの内容をざっくり説明すると、まずオンで実行条件が書かれます。
これはプルリクエストが作成されたら、このプログラムがGitHub上で動くという意味です。
そしてPermissionsで権限の許可設定を書きます。
03:02
今回の設定はReadなので読み取りのみ許可され、編集は許可されていません。
そしてこの部分はGitHub Actionsの実行中に新しいプッシュをされたら、
前の実行分はキャンセルするという設定です。
そしてその後GitHub上でプログラムを動かすために必要なツールをインストールし、
最後にツールやアプリのテストを一括で実行する流れです。
今回このGitHub Actionsの設定ファイルが追加されたので、
このPR上でもGitHub Actionsが実行されています。
具体的にはPRのトップ画面の下のところでGitHub Actionsの実行履歴を見ることができます。
このように先ほどファイルで書かれていたGitHub Actionsが1分で成功していることがわかります。
もしエラーなどがあればここに×が表示されます。
このようにPR上でGitHub Actionsを使ってテストが自動実行されるようにしておけば、
AIがバグを作ってもGitHub Actionsがエラーになるのですぐに気づくことができます。
今回はGitHub Actionsの実行に1分かかりましたが、
プライベートリポジトリではGitHub Actionsは月2000分まで無料で使うことができます。
2000分を超えた場合は追加の従量課金か、
有料PRに契約しなければ月が変わるまでの間は常に利用枠が足りないというエラーになります。
GitHub Actionsの話はこの辺にして、
先ほどの続きでファイルの差分を見ていきます。
次のファイルでは冒頭に1行空行が足されています。
これはフォーマッターによる修正です。
フォーマッターとはファイルの中身を決まったルールに従って整理してくれるツールです。
例えば今回のこの1行の空行追加は、
マークダウンファイルで見出し行の手前には必ず空行を入れるというフォーマッターのルールを適用したものです。
他にもフォーマッターは様々なルールでファイルの書き方を揃えてくれます。
例えば先ほど見た読むファイルには文章の先頭にスペースが入っています。
このスペースを半画何個にするか、もしくはタブ何個にするかといったルールもフォーマッターが一律に決めて自動で整形してくれます。
このようにフォーマッターがファイルの書き方を一律で自動整形してくれることで、
AIや人はここにはから行を入れるべきなのか、
この部分の字下げは半画スペースもしくはタブ何個分なのかといったファイルの見た目を整える作業から解放されます。
フォーマッターのツールにはいろいろありますが、このプロジェクトで使っているのは最もメジャーなPrettierというツールです。
フォーマッターの解説が終わったので、引き続きファイルの差分を見ていきます。
マークダウンファイルの修正はフォーマッターによるものなので飛ばします。
このgitkeepというファイルは空のフォルダをgit管理するために使うファイルです。
空のフォルダはgitにコミットできないので、gitkeepというファイルを入れてコミットします。
フォルダの中に何かファイルを作ったらgitkeepは削除します。
ソースコードの変更はコメント部分をざっと読んでおかしなところがないか確認します。
gitignoreにはgit管理したくないファイルを定義します。
例えばMacの中で自動生成されるファイルや、プログラムやツールの実体のファイル、
APIキーや秘密鍵などの機密情報、ログファイルなどはgitに入れたくないのでgitignoreに定義しておきます。
06:05
そしてPrettierによる整形を適用しないファイルや、データベースを操作するSQLの書き方の設定ファイルなどが続きます。
次にagents.mdでAIエンジェント向けにこのプロジェクトの説明を書いてあります。
例えばこのプロジェクトが何のアプリに関するものなのか、どこにどんな資料があるのか、
また開発ではどんなツールを使うのかといったことが書いてあります。
クロードコードから使うcloud.mdはagents.mdを参照する一文だけが書いてあります。
この後も様々な設定ファイルの修正が続きますが、アプリによって最適な設定は異なるので説明は省略します。
サブを一通りチェックして問題ないことが確認できたら、prをメインにマージします。
そしてメインにマージしたブランチはもう不要なので、デリートブランチで削除します。
次にGitFetchでGitHubの最新情報を取得して、メインブランチに切り替えます。
そしてGitPullでメインから最新を取得します。
これでパソコン内にも先ほどマージしたメインの内容が反映されました。
今回はコマンドでやりましたが、クロードコードでメインをマージしてフル指定のように指示すれば同じことができます。
また今回はクロードコードが自分でメインから作業用のブランチを切って作業しましたが、
ブランチは本番用ブランチ、開発用ブランチ、それから作業用ブランチを分けたいです。
なので次はブランチ運用を見直します。
クロードアプリを開いて新しい会話に切り替えます。
そして思考レベルを再び最大にします。
その後このような指示を貼り付けます。
これは僕が普段やっているブランチ運用を構築するための指示です。
GitHubにはデフォルトブランチという概念があります。
デフォルトブランチとはGitHubの中で標準の参照先として設定されるブランチです。
例えばGitHubでリポジトリを開くとデフォルトブランチが選択された状態で開きます。
他にもプルリクエストを作るときはマージ先としてまず最初にデフォルトブランチが設定されます。
なので普段最もよく動かすブランチをデフォルトブランチにするのが一般的です。
僕の普段のブランチ運用はデベロップという開発ブランチからさまざまな作業ブランチを切って都度マージしていき、
本番環境に変更を反映したいときはデベロップからメインへまとめてマージするという運用です。
そしてAIに複数の作業を並列で任せたいので、GitWorks3を自動作成するスクリプトも作ってもらいます。
ただ環境変数などのGit管理外のフォルダはGitWorks3を作るときにリポジトリから持ってこれないので、
一箇所にまとめて各Works3から参照することにしています。
加えてブランチのマージ、削除、Works3の削除もまとめて行うスクリプトも作ってもらいます。
09:01
このブランチ運用も最初はGrill with DocsでAIと壁打ちしながら決めましたが、
今は使いやすいブランチ運用が言語化できるので、今回のようにまとめてAIに指示して作ってもらいます。
早速このブランチに関する指示をクロードコードに投げます。
ブランチ運用に関する作業が終わったようなので早速見ていきます。
作業内容は特に問題なさそうです。
そして自分でテストもしてスクリプトがうまく動くかを確かめてくれています。
今回のPRをマージしたらこのコマンドを実行してくれと言っているので後で実行します。
また作業中に別のリポジトリのフワイを見つけたので、それを推奨タスクとして出してくれています。
このような推奨タスクが出たときは新しい会話で作業してほしいので、
僕はいつも推奨タスクは一周を切ってと依頼します。
今回の推奨タスクは別リポジトリに関するものなので、その別リポジトリ名を指定して依頼しておきます。
一周作成が完了しました。一周はGitHubのリポジトリ画面に作成されます。
一周とはGitHubのシンプルなタスク管理ツールです。
GitHubリポジトリのこの一周ボタンから見ることができます。
この中に作成した一周がどんどん溜まっていきます。
今回作成した一周がこの一番上のものになります。
このようにタイトルや問題、対応内容などをマークダウンで書くことができます。
この一周をAIに対応させたいときはこのリンクをコピーして、
例えばクロードコードなどにこのように以下の一周に対応してといった感じで指示するだけです。
なので先ほどのようにクロードコードが新しい推奨タスクを出してきたときは、
一旦一周にしてもらって、新しい会話に切り替えてから対応させるようにしています。
そしてブランチューン用に話を戻すと、もう作業は完了しているので、
今回の作業のPRを見てみます。
一つ前のPRと同じように作業内容をざっと見て、差分にも目を通していきます。
問題なさそうなのでPRをメインにマージします。
そしてクロードコードがこの2つのコマンドを実行してくれと言っているので実行します。
もう一つのコマンドも続けて実行します。
はい、正常に実行が完了しました。
ブランチューン用の仕組み化までできたので、今回の動画の作業は一旦ここまでにします。
ここで一つお知らせです。無料メルマガで今回話したような実践的なAI活用法を配信しています。
1分ほどで登録できるので概要欄のリンクから見てみてください。
あなたもぜひ今回実践してみせたAIに作業をさせて、その作業内容をGitHub上で確認し、
メインにマージして取り込むという流れをやってみてください。
またメインを本番用ブランチ、デベロップをデフォルトブランチの開発用ブランチとして、
作業用ブランチは常にデベロップから切り、本番反映するときだけメインにマージするというブランチューン用も便利なのでぜひ活用してみてください。
12:03
AIで並列作業をしたかったら、GitWorks 3の作成と削除のスクリプトも作っておきましょう。
次回は引き続きこのアプリを作りながら、コードをきれいに保つリンターやフォーマッター、セキュリティ周りの対応などを進めていきます。
概要欄にも今回の内容を解説した記事を貼っておきます。
それでは今日はこのへんで。