断り書き：俺はN5レベルで日本語を勉強中です。間違いがあるかもしれないけど、頑張っています！
「配管地獄」とは #
分散システムはスケールしやすい。でも、開発者には大変なことが多い。
俺はこれを「配管地獄」と呼んでいる。一つのサービスをローカルで動かすために、Kafka、Postgres、Redis、他のマイクロサービスも全部必要になる。500行の docker-compose.yaml を書いたり、ノートPCでKubernetesを動かしたりする。APIの小さい変更をテストするだけなのに。
コードを書く時間より、ポートの設定やコンテナのネットワークのデバッグに時間を使っている。これは普通になってしまった。でも、これが普通でいいわけがない。
意図 vs 実装 #
一番の問題は、今のツールが 意図（何をしたいか）と 実装（どうやるか）を混ぜていることだ。
「Postgresが必要」と言ったら、手動でポートを設定したり、KubernetesのStatefulSetを書く必要はないはずだ。意図は分かりやすい。実装はツールの仕事であるべきだ。
これが bs を作る理由だ。
bs とは
#
The No Bullshit Build System。 Go言語で作っている、意図を中心にしたビルドツールだ。
考え方はシンプル：意図を書いて、システムに配管を任せる。bs.yaml にアーキテクチャを書くと、bs が Translator（翻訳者）として動く：
- ローカル開発： Docker APIを直接使って、ホットリロードできる軽い環境を作る。Kubernetesは不要。
- 本番： 同じ
bs.yamlからKubernetesマニフェストやHelmチャートを作る。
Docker Composeファイルを書かなくていい。環境ごとの設定ファイルも管理しなくていい。必要なものを書くだけで、Translatorが動かし方を決める。
設計で大事にしていること #
Translatorパターン #
bs はサービスの定義と実行を分ける。同じ bs.yaml が dev、test、prod で違う結果を出す。開発者の考え方は、どこで動いても同じだ。
自動設定とシークレット #
ローカル開発で一番面倒なのは、設定の管理だ。サービスAがデータベースを必要とする時、bs はURLだけじゃなく、環境変数、APIキー、TLS証明書も自動で用意する。.env をコピーしたり、シークレットをハードコードしなくていい。
全部がアーティファクト #
bs では、データベースもアーティファクトだ。スキーマを入れて、スナップショットを取って、キャッシュできる。ローカルの開発データベースが毎回同じ状態で使える。
今の状況 #
はっきり言うと、まだ完成していない。フェーズ1を作っている：
- コアCLI —
spf13/cobraを使っている - DAGエンジン — 並列実行と依存関係のグラフ
- Dockerアダプタ — Dockerクライアントと話すインターフェース
- ローカルストア — ビルドアーティファクト用のCAS（Content Addressable Store）
これは意図の表明だ。俺が毎日感じるマイクロサービス開発の問題を解決するために作っている。進捗があったら、ここに書くよ。
楽しみにしていてね。