Transcript
00:00:00Readmeの記述は嘘だ。「5分でセットアップ完了」とあっても、Nodeのバージョンは違うし、Pythonも違う。
00:00:07Postgresはないし、Dockerはいつまで経っても立ち上がらない。結局、始める前からデバッグに追われることになる。
00:00:13開発環境をReadmeに頼ってはいけない。Gitで管理すべきだ。それが「Devbox」の役割だ。
00:00:20devbox.jsonファイル一つと、コマンド一つ。devbox shellを使えば、グローバル環境を汚さず、全員が同じ環境で作業できる。
00:00:28Nixの知識も不要だ。実際に見てみよう。
00:00:30最初はDevboxがシンプルすぎて拍子抜けするかもしれない。devbox.jsonを作り、プロジェクトに必要なツールをリストアップするだけだ。
00:00:42Node、Go、Python、Postgresなど、スタックに必要なものを書く。そのファイルをコミットすれば、他のメンバーもすぐに使える。
00:00:50「devbox shell」を実行するだけで、同じバージョン、ツール、スクリプトが手に入る。グローバルインストールは不要だ。
00:00:58「まず8つインストールして」とか「数年前のHomebrewの状態が原因」といったトラブルとは無縁になる。
00:01:03セットアップ方法が個人の記憶に依存せず、リポジトリに明記されるようになる。小さなことのようだが、
00:01:09開発環境のトラブルで半日無駄にした経験があるなら、これがどれほど重要か分かるはずだ。作業効率を上げるツールが好きなら、
00:01:16ぜひチャンネル登録してほしい。役立つ動画を常に配信している。
00:01:20では、空のプロジェクトから始めてみよう。新しいフォルダーを作成して、
00:01:25名前は「devbox-demo」にする。フォルダーに移動して、Devboxがインストールされていれば、
00:01:31「devbox init」を実行するだけだ。Devboxがdevbox.jsonというファイルを作成する。中身は基本的に空の
00:01:39テンプレートだ。では、必要なツールを追加しよう。ツールを追加するには、
00:01:45「devbox add」でGo、Node.js、Pythonなどをインストールする。ここで
00:01:52重要なのは、これらをグローバル環境にはインストールしていないということだ。システム標準のNodeや
00:02:00Pythonには一切触れない。これらのツールはこのプロジェクト専用だ。「devbox shell」で環境に入ると、クリーンな
00:02:09プロジェクト環境が構築される。この環境内でバージョンを確認してみよう。Goや
00:02:14Node、Pythonのバージョンを確認すれば、すべて正しく動いていることが分かる。これこそが最大のメリットだ。
00:02:19プロジェクトが求めた特定のツールが、Devboxによって用意された。次にスクリプトを追加しよう。devbox.json内で
00:02:27テストコマンドを定義できる。試しにテスト実行中と表示させ、Nodeと
00:02:34Goのバージョンを出力させる。「devbox run test」を実行すれば、誰でも同じコマンドで同じ結果を得られる。
00:02:42同じスクリプト、同じツール、同じ環境だ。環境を抜けるには「exit」と入力するだけでいい。
00:02:48環境から抜けると、いつものPC環境に戻る。すごく単純だろう？
00:02:53Devboxは何をしているのか？Devboxの裏側では「Nix」が動いている。Nixは
00:03:00再現性に優れている。その時の最新版をインストールするのではなく、
00:03:06プロジェクトが必要とする厳密なバージョンのツールを固定できる。これが良いところだ。ただ、
00:03:12Nixは全く新しい世界のように感じられ、学習コストが高い。単に
00:03:18正しいNodeのバージョンを使いたいだけなのに、少しハードルが高い。Devboxはそれを変える。
00:03:23再現性はそのままに、ワークフローを「普通」にする。つまり、
00:03:29Nixの式を書く代わりに、add、search、shell、run、servicesといったコマンドを使う。どれも
00:03:37ずっとシンプルだ。プロジェクトにはJSONと
00:03:44lockファイルができる。devbox.jsonは環境の定義、lockファイルは依存関係を
00:03:52正確に固定するためのものだ。両方をコミットすれば、環境は単なるReadmeの記述ではなく、
00:03:58プロジェクトの一部になる。DevboxはmacOS、Linux、WSLで動作する。VS Codeとの連携や、
00:04:06スクリプト定義、データベース等のサービス管理も可能だ。必要であれば、
00:04:12DockerやDev Containers、CIワークフローへのエクスポートもできる。価値は「クールなツール」であることではなく、「単純なツール」であることだ。
00:04:19価値は「時間」にある。最初の問題はReadmeだ。Readmeには何でも書ける。
00:04:26「Node 18をインストールせよ」とあっても、実際にはNode 20が必要かもしれない。次に
00:04:32このツールが役立つのはオンボーディングだ。入社初日にスムーズに作業を始めるのは難しいが、
00:04:37Devboxがあれば、「どのNodeのバージョンが必要？」と聞いたり、
00:04:43「どのPythonのバージョン？」「Postgresは必要？」といちいち確認する必要がなくなる。
00:04:48一部の人だけ動く、なんてこともなくなる。リポジトリをクローンして、シェルに入って、
00:04:52実行すればいい。何か問題が起きても、全員が同じ環境からスタートできる。問題は
00:04:58グローバル環境が汚れることだ。実験のためにPCを壊したくはないだろう。プロジェクトごとにGo 1.22が必要なら追加すればいい。
00:05:06別のプロジェクトでNode 20が必要でも問題ない。ツールはプロジェクトごとに管理され、
00:05:13システムはクリーンなままだ。Devboxなら、環境定義をローカル開発と
00:05:18自動化ツールで共有できる。すべてのCI問題を解決できるわけではないが、
00:05:26馬鹿げたトラブルの多くを排除できる。そして、馬鹿げた問題こそが、
00:05:32最も我々を苦しめるのだ。最後に、ローカルでのDockerワークフローが重いという問題がある。
00:05:40コンテナが必要ならDockerを使うのが一番だが、単にツールを管理するためだけに
00:05:46Dockerを使っているチームも多い。Devboxのワークフローは単純だ。add、shell、runするだけ。
00:05:52学ぶことは少ない。環境自体がプロジェクトの一部になり、リポジトリの
00:05:57実ファイルとして管理される。全員が同じバージョンを使えば、デバッグも楽になる。
00:06:03すごくシンプルだ。不満な点は、初回実行時にダウンロード時間がかかることだ。
00:06:09最初だけなので問題ない。JSONはシンプルだが、追加しすぎると
00:06:15複雑になる。スクリプトが複雑なら、巨大なシェルコマンドをJSONに書かず、
00:06:22.shファイルに書き出して呼び出すようにすればいい。DevboxはクラウドIDEではない。
00:06:30ブラウザベースのコーディングや即時プレビューが必要なら、CodeSpacesなどが良いかもしれない。
00:06:36Devboxはローカル環境とCIの再現性に最適だ。開発のあらゆる問題を
00:06:42解決するわけではないが、最も面倒な「プロジェクトが動かない」という
00:06:46問題を解決できる。複数の言語やツールを使っているプロジェクトなら、
00:06:51試す価値はあるだろう。こういったツールが好きなら、Better Stackチャンネルを
00:06:56ぜひ登録してくれ。また次の動画で会おう。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video