はじめに
最近、チームの開発環境のセットアップに mise を導入してみました。
元々、Node.js、Docker、AWS CLI、Terraform など、開発に必要なツールやそのバージョンは README に記載されており、運用として特に大きく困っていたわけではありません。
しかし、実際に開発を続けていく中で、
- 新しく参加した人が環境構築でつまずき、そのフォローに時間を取られる（参加メンバーも余計な時間を取られてしまう）
- README の更新が追いつかず、書いてある手順どおりに進めても動かない
といったことが、じわじわと増えてきました。
そこで、新規参加メンバーも気軽に環境を揃えられないかと考え、評判が良かった mise を導入してみました。今回は導入してみて感じた変化について記載します。
※ mise のインストール方法や使い方の詳細については本記事では触れないため、公式サイトや他の分かりやすい記事を参照してください。
mise とは？
mise は、開発環境のセットアップを一元管理するための CLI ツールです。
「mise-en-place」はフランス料理の用語で、「準備を整える」「すべてを所定の位置に置く」という意味があります。料理を始める前に道具や材料をすべて揃えておくという考え方を、開発環境に適用したツールのようです。
主に 3 つの機能が統合されています。
- Dev Tools: ツールのバージョン管理
- Environments: プロジェクト単位の環境変数管理
- Tasks: タスクランナー
asdf を使っている方であれば、「asdf + direnv + Makefile が担っていた役割を一つにまとめたもの」と考えると、イメージしやすいかもしれません。
mise 導入前の状態：README に必要な情報が集約されていた
ここでプロジェクトでの話に戻ります。
前述した通り、mise 導入前は環境構築に必要な以下のような情報はすべて README にまとめていました。
- 必要なツールの一覧
- 推奨バージョン
- インストール手順
- 起動方法
一見すると親切ですが、実際には次のような状態になっていました。
- 必要なものが文章として散らばっていて、全部読まないと重要な情報に気づけない
- エラーが出てから「あ、これも必要だったのか」と知る
- README の更新が漏れると、実態とズレる
特に、ツールやバージョンを更新した際に README の修正が漏れると、書いてある手順どおりに進めたのに動かない、どこが正しい情報なのか分からない、といった状況になりがちでした。
結果として、Node.js のバージョン違いで npm install が失敗したり、docker compose が入っておらず調べ直したり、といったことがオンボーディングのたびに発生していました。
致命的ではありませんが、「最初の一歩」が少しずつ重たくなっている感覚がありました。
mise 導入後に感じた一番大きな変化
mise を導入して最初に感じた変化は、環境構築時の手順や考えることが明らかに減ったことでした。
新しく参加した人には、「とりあえず mise をインストールして、mise run dev を実行してください！」と伝えるだけで、環境構築が一通り完了するようになりました。
これにより、次のような状態を作れるようになりました。
- README を最初から読んで環境構築を進める必要がない
- どんなツールやバージョンを入れるべきかを事前に把握しなくていい
- 「ツールが入っていない」「バージョンが違う」といった環境起因のエラーに遭遇しにくくなった
mise の何が良かったのか
必要なものを README ではなくコードで管理するようになった
mise を使うことで、プロジェクトに必要なツールを mise.toml にまとめて定義できるようになりました。
[tools]
node = "20"
docker-compose = "2"
aws-cli = "2"
このファイルを見るだけで、このプロジェクトで何が必要か、どのバージョンなのかが一目で分かります。
README から必要なツールを探す必要はなく、必要なものがコードとして定義されている状態になりました。
ツールのインストール順を意識しなくてよくなった
mise では、定義されたツールが未インストールでも、そのままコマンドを実行できます。必要なツールは実行時に自動でインストールされるため、何から入れるべきか、どの順番で入れるかを考える必要がなくなりました。
結果として、依存関係のあるツールのインストール漏れや、バージョン違いによるトラブルから解放されました。
起動手順も「覚えるもの」から「実行するもの」になった
mise のタスク機能を使うことで、プロジェクト起動時の依存関係も明示的に定義できるようになりました。
例えば、アプリを起動する前に docker compose を起動しておかないとエラーになるケースがあります。mise.toml に以下のようにタスクを定義すると、
[tasks.docker]
description = "🐳 Start local services"
run = "docker compose up -d"
[tasks.dev]
description = "🚀 Start app with local services"
depends = ["docker"]
run = "npm run dev"
dev タスクを実行するだけで、依存するタスクも含めて決まった順序で実行されるようになります。
mise run dev
「どう起動するんだっけ？」を覚える必要がなくなり、コマンドを1つ実行するだけで済むようになりました。npm scripts でも似たことはできますが、ツール管理と同じファイルで一元管理できるのが mise の良さだと感じています。
まとめ
mise を導入したことで、次のような効果が得られました。
- 環境構築にかかる時間が短縮された
- 「手順通りにやったのに動かない」がなくなった
- ツール更新のたびにREADMEを更新する必要がなくなった
環境構築まわりの負担を減らし、開発を始めるまでのハードルを下げたいと考えている方の参考になれば幸いです。