CIを整備してメンテナンスを生成AIに任せる

by Hazumi Ichijo

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Copyright © Henry, Inc. All rights reserved. メンテし続けているツール: issue-creator ● issue-creator ○ GitHubのissue/discussionをテンプレートissueを元に定期的に作るくん ○ GitHub Actionsで利用可能 ○ 日付・過去issueのリンク・etc.. が埋め込める ○ 週の振り返りなどで利用（マネーフォワードさんでも利用） ■ https://moneyforward-dev.jp/entry/2022/07/21/start-wit h-github-discussion/#GitHub-Actions

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright © Henry, Inc. All rights reserved. メンテし続けているツール: giro ● giro ○ gRPCでReflectionが実装されていない言語でもJSONを使ってAPI Callできるくん ○ 構成要素 ■ protoc plugin: .protoファイルからReflectionサーバを生成 ■ CLI: ReflectionサーバとAPIサーバが別でもリクエストできるようにするくん

Slide 7

Slide 7 text

Copyright © Henry, Inc. All rights reserved. 疑問 ● 僕の要求: これらのツールを「動かし続ける」ことができる ● 動かし続ける: 以下の2つを満たせる ○ 実行結果が変わらない ○ 依存ライブラリで脆弱性が発覚・対応された後に、1週間程度で対応できるこの要求は、僕がメンテせずとも生成AIで達成できるのでは？ ● 利用者に提供している機能が明確（=> CLIで入出力のパターンが少ない） ● 実装がオープンになっている（=> 情報管理を考えなくて良い）

Slide 8

Slide 8 text

Copyright © Henry, Inc. All rights reserved. アプローチ CI: 落ちていた CI: 通っていた実際: 壊れていた陽性偽陰性実際: 壊れていなかった偽陽性陰性基本CIですべてチェックするようにし、偽陰性を減らし、偽陽性は許容 ● 偽陰性: ツールの利用者（人間）の時間を奪うので守る ● 偽陽性: 壊れたものをリリースするよりマシ。対応コストは生成AIが払う ○ Flaky Testは許容する。Retryなどの管理は生成AIに任せる

Slide 9

Slide 9 text

Copyright © Henry, Inc. All rights reserved. アプローチフェーズを以下に分けて進めた 1. CIの整備。人間が開発し、手元で確認・CIの確認しマージ ● E2Eテスト・設定ファイルのバリデーションを整備 2. CIの品質の確認。Renovateで依存ライブラリを上げ、手元で確認・CIの確認しマージ ● 偽陽性: 人間が対応 / 偽陰性: 人間が検知し、人間がテストケースを追加 3. コードを書く主体を生成AIに。Renovate/生成AIに変更させ、CIで確認。見逃したとしてもリリース後1週間以内に問題に気づける体制 ● 偽陽性: 生成AIが対応 / 偽陰性: 人間が検知し、人間/生成AIがテストケースを追加

Slide 10

Slide 10 text

Copyright © Henry, Inc. All rights reserved. Tips ● テストケースも読む手間を減らしたいので、人間の可読性に振る ● 偽陰性を見つけたいので、できるだけ広くE2Eテストに振る ● 例: ○ issue-creator: 実際のGitHub APIでテストする。テストケースをGitHubの issueに追加 ○ giro: gRPCサーバを立ててテストする。テストケースを google/go-cmdtestで記述

Slide 11

Slide 11 text

Copyright © Henry, Inc. All rights reserved. Tips $ giro host rerost.giro.v1.TestService localhost:5000 $ giro call rerost.giro.v1.TestService/Echo {"message":"Test"} --metadata=key1:val1:key2:val2 {"message":"Test", "metadata":{"metadata":{":authority":{"value":["localhost:5000"]}, "content-type":{"value":["application/grpc"]}, "key1":{"value":["val1"]}, "key2":{"value":["val2"]}, "user-agent":{"value":["grpc-go/1.73.0"]}}}} google/go-cmdtest を使ったテストケース（スナップショットテスト）

Slide 12

Slide 12 text

Copyright © Henry, Inc. All rights reserved. 人間の残りやること ● 原因が不明なケースの調査・対応 ○ 例: CIが依存しているライブラリの最新がリリースされかつ壊れていた ○ https://github.com/rerost/issue-creator/pull/218 ● 問題の切り分け・マネジメント ○ 生成AIがドツボにハマらないように、解けるサイズに問題を落としたり ● 生成AIのセットアップ・管理 ○ 例: DevinからClaude Codeへの切り替え。ActionsのためのMCPを設定 ○ https://zenn.dev/rerost/scraps/4acd95326df6ad ● テストケースの追加 ○ https://github.com/rerost/giro/pull/155/ﬁles#diﬀ-74e3dd07433d99a4b0c 15aa4f1ed17c16ee5b9535108410c2e48d35c125e6a8f