この度、cd-toolsというライブラリをリリースしました。 まだMVP段階ですが、これほど腰を入れてOSSを個人(ほぼClaude Code)で開発したのは初めてだったので、振り返り的記事を書いてみます。
また、別の記事で、ライブラリの使い方を詳細に説明しています。よければそちらもぜひご覧ください。
この記事では、以下の内容について話します。
- cd-toolsの概要
- 開発の動機
- 振り返り
- 今後の展望
cd-toolsの概要
表題の通り、cd-toolsはモノレポで複数言語&複数レジストリ対応の柔軟バージョニングデプロイを自動化するライブラリです。
このライブラリの特徴はただ1点。極めて高い柔軟性。これに尽きます。
例えば、前述では「cd-toolsはモノレポで複数言語&複数レジストリ対応の柔軟バージョニングデプロイを自動化するライブラリ」と書いていますが、モノレポ以外でも運用できます。モノレポ以外というか、独立した単一リポジトリですかね。
実際、cd-tools自体は独立した単一リポジトリですが、cd-tools自体を使ってリリースしています。
また、極論、cd-toolsが提供しているのはGithub Actionsのworkflow ymlに過ぎません(もちろんそんなことはないのですが)。
cd-toolsは現状init,start-pr,push-pr,end-prのコマンドが提供されていますが、これらが行っていることは補助的なことが大部分です。
具体的には、初回のみ必要なファイルを生成。その後ブランチを作成し、ファイルを少し書き換えて、PRを作成するといった程度です。CDに関することは何もしていません。強いて言うならバージョンファイル書き換えですが、同じことは手動で出来ます。
つまり、CDに関することはinitコマンド最初にGithub Actionsのワークフロー定義ymlと小さなshell scriptを生成して以降、cd-toolsは何も関与しません。
これが意味することは、生成したCD関係のファイルはユーザーの自由に編集できるということです。現状、デフォルトではnpmレジストリとGitHub Container Registryしか対応していません。しかし、なんとymlを数行変えるだけでjsrやGitHub npm registry, docker hubにも対応可能なのです。
言語についても、生成されたファイルを少し書き換えたら他言語のサポートもある程度は可能になります。ライブラリのサポートを十全に受けようとするとライブラリ側の修正は必要にはなりますが、修正する箇所は限られています。
各言語用のバージョン管理フィールド更新関数を実装するだけです(とても簡単！！！)。他で自分が知っているもので言うと、Goならgit tagのクロールで公開されるので、これすら不要でしょうか。
つまり、至極簡単に他言語対応も可能です！ぜひContributeを！
開発の動機
自分は個人でのOSS開発が初めてではあるものの、ここ1年ほど業務で組織内のプライベートライブラリを開発していました。
その際用いていたのが最初の方にも言及したcs-toolsです。そのプロジェクトには途中から参戦したので、release-itやsemantic-releaseなどのメジャーなCDツールに触れないまま、最初から入っていたcs-toolsをそのまま使っていました。
ただ、改めて今(cd-toolsを除外して)CDツールとして何を使うかと問われてもcs-toolsと答えます。それくらい自分のユースケースにハマっていました。
理由は主に以下の通りです。
- 導入、運用が簡単
- これが特大メリット。release-itやsemantic-releaseは自分のユースケースに対して設定が複雑すぎた。気軽に導入したい。
- CDのGithub Actionsの自動生成(cd-toolsの概要で述べたのと同じメリット)
- CLIによるversion up commitのpush
- version up commitをGitHub Actionsなどで実行するCDツールがそこそこあるが、protected branchへのcommit pushなどでややこしいことが多い。
ただ、ある時そのプロジェクトで大幅リファクタリング(というかリアーキテクチャ)をすることになりました。その際リポジトリのモノレポ移行も決定したのですが、cs-toolsはモノレポに対応していませんでした。
ついでに、alpha,rcなどの複数タグにも対応したかったのですが、cs-toolsはrcタグしか使えませんでした。
とりあえずの突貫工事としてCDは自作スクリプトを利用することで何とかしました。しかし、cs-toolsの使い心地をどうしても忘れることができませんでした。
と、いうことで一念発起して作成したのがこのcd-toolsです。
振り返り
vibe codingをしてみよう
まず、実装方法としてvibe codingをするというのは自分の中で決定事項でした。楽しそうだし。
vibe codingのためにも、最低限要件は決めなければいけません。要件というか、溢れ出てくる自分の欲望なのですが、それを実現するための手法を考えました。ChatGPTくんと壁打ちしながら1週間くらい考えました。と言っても時間換算では10時間くらいです。
何はともあれ、1週間の熟考の末要件を決定してvibe codingを行いました。もちろんツールはClaude Code(Max)のdangerously-skip-permissions(container-use環境)。
最初の10分くらいは監視してそれなりに良い感じだったのでひと眠り。起きた時には実装は完了していました。
vibe codingの悲惨な結末
起きた時には惨状が広がっていました。
要件は軽く見た感じ5割も実装できていない。実装が無駄に複雑、車輪の再発明、…。
複雑な要件には耐えられないという前評判は聞いていたものの、簡単な要件のvibe codingは手抜きプロンプトでもかなり上手く作ってくれていたので、もう少し上手くやってくれるのを期待していました。
結構要件詰めてのこの結果なら仕方ない、とvibe codingは諦めることにしました。
副操縦士になろう
少し考えた結果、vibe codingの結果を修正する方が難しいと判断し、一度差分は全消しして次は副操縦士となることにしました。
vibe codingの時以上に要件を詰め、1つ1つ修正を確認しながらAIに実装を委ねる方針です。
最終的な要件はTODO.mdのようになり、これをもとにClaude Code(dangerousじゃないほう)に実装を依頼しました。
結果、要件を達成はしたものの、8割くらい介入しました。
途中で人力実装も1割くらいしました。
リファクタの余地も山ほどあります。
副操縦士の回顧
やはり入力が悪かったのかな…と思っています。
コンテキストエンジニアリングとは解空間を明示すること、とどこかで聞いた覚えがありますが、解空間を限定しきれなかったのだろうなというのが率直な感想です。
TODO.mdについて、自分としてはかなり解空間を限定させた認識でした。しかし、重箱の隅を突つかれに突つかれまくったのです。(もちろんClaude Code暴走してるだけやんこれ。というのも時折ありましたが)
ただ、そういった面はありつつも、副操縦士に移ってからの実装時間は12時間ほどでした。これを自力で実装しようと思ったらぶっ続けでやっても2,3日はかかっていたと思われるのでやはりコーディングエージェントは偉大だなと感じました。まぁ品質を考えるとトントンかなという気はしますが、もう少し手を離せば並列でタスクは回せますし、MVPをとりあえず作る、という点でいうと最適だと感じましたね。
コーディングエージェントの話で言うと、最近はkiroの話題をよく聞きますね。スペック駆動開発ということで、今回の悩みにベストマッチしそうです。
出遅れて自分はまだwait listですが、kiroのようなツールを使った今回のような要件のスペック駆動開発では今回のケースとどのような違いを発見できるのかとても気になりますね。
今後の展望
cd-toolsは今後、以下のような修正、追加機能を予定しています。
- リファクタ祭り
- CI整備
- Release Note生成機能
- conventional commits対応
- 他の主要言語対応
- モノレポ以外も対応可能だが、モノレポに偏りすぎているので、モノレポ以外のUXを向上させる
-
config.jsonのjsonschema対応
おまけ
cd-tools開発期間のccusage
Discussion