個人的Rails開発環境構築20242024/03/17に公開2024/09/081件RailsRubytech新規でRailsプロジェクトを始める時の個人的な環境構築についてまとめる。前提とする条件等は下記。シーン的に「思い立ったらすぐアプリの開発ができる」という感じの運用がしたい。セットアップで悩みたくないから必要なミドルウェアなどは全部Dockerでインストールできるようにして立ち上げれば終わり、の環境を作る。gなどでRailsアプリを作成していく。この辺のRailsの初期セットアップの手間を出来るだけ省きたいのでtemplateとなるリポジトリを作成し、そこからcloneしてくるだけでOKにする。フロントエンドはReactなどを使わずをRails標準のerbとHotwireを軸に開発する。開発時はHMRの恩恵を受けたいのでその辺の設定は頑張る。あとはLinter/Formatterの設定やCIの初期設定あたりをちゃんとやっておく感じで。先に上記の要望を満たすために作成した環境の使い方を書いておく。テンプレートリポジトリをcloneする。sample-projectVSCodeを開いてDevContainersを実行し数分待つ。これで下記の開発環境が基本的には整う。dbやmigrateあたりのDB作成をしてbin/devすればlocalhost:3000でアプリが動く。format/lintの設定やviteによるHMRな設定がすでにできているのであまり考えることなくフロントエンド開発に入れるはず。以下では上記の技術選択をした理由やセットアップの方法などについて簡単に書いていく。VSCode/BaseコンテナVSCodeを使うのはエディタとして便利なのもあるが何よりDevContainersが便利。プロジェクトをVSCodeで開いたらそのプロジェクト専用の開発環境がコンテナで整うという体験はローカルに複数のRailsアプリ環境を持つ必要のある自分のような人間には個人的には楽。VSCodeを使ってる人であれば特に指示しなくてもDevContainerを使ってくれれば同じ環境を共有できるというのも良い。DevContainerで立ち上げるBaseコンテナとしてはYuheiNakasaka/docker-rails-basisを使っている。Martians流Docker+Ruby/Rails開発環境構築(更新翻訳)で紹介されている環境を元に自分用にまとめただけ。Baseコンテナの中身は.dockerdev/Dockerfileにある。内容的には基本的な依存ミドルウェア(Ruby,PostgreSQL,Redis,Node.js等)を入れたもの。一応あると便利なのでcurlとかvimとかも入ってる。拡張機能の利用は自由だけど一応下記をデフォルトで入れてる。AI無しじゃ生きていけない体になっている。Ruby3.3/Rails7.1一応2024/3月現在の最新。DevContainersを開く前(というかbaseコンテナのビルド前)にdocker-compose.ymlの方でRUBY_VERSIONに好きなバージョンを設定するとそれが入る。Railsに関してはGemfileの方に好きなバージョンを設定すれば良い。PostgreSQLDBに関しては好きなものを使えば良いと思う。PostgreSQLは個人的にも世間的にも今はRailsで使ってるとこ多そうなのでこれにしただけ。servicesの中で顧客の環境で動かすだけとか小規模ならSQLiteでもええやんみたいな話をしてたのを思い出したが一理ある。Redisメールの送信や外部APIとやりとりするための非同期処理なんかを書くことはほぼ必須な気がしてるからSidekiqもデフォルトで入れてしまうことも考えたがデフォルト環境としてはちょっとやりすぎかなと思いやめた。キャッシュやセッション管理とかでRedisは使うでしょと思ったので入れてある。ERB/Hotwire/Vite/TypeScript/TailwindCSSフロントエンドをどうするか。ここは割と意見が分かれると思うが標準に乗るのが一番楽だとは思う。https://railsguides.jp/v7.0/working_with_javascript_in_rails.htmlRails7ではHotwireとimportmapがデフォルトになっているからJavascriptで十分で特にこだわりがないならこれを使えば良い。設定とかほぼいらないし。あと標準ではimportmapの他にjsbundling-railsというgemが導入されてESBuildなどのバンドラを使った管理も可能。自分はTypeScriptを使いたかったりHMRやらのフロント側のエコシステム管理をシンプルにしたかったのでViteを使うことにした。Rubyというgemを使うと簡単。これを使うとvite.config.tsをいじるだけでいつものように管理できるようになる。assets:precompileと自動で統合されてるからデプロイも楽だしPluginも必要なものが揃っているからrails側のviewとjsの変更を検知してViteの高速なHMRを導入するのも楽々。基本的なフロントエンドのコードはERBで書く。SlimとかHamlは無駄に標準から外れる気がするしあんまり使ってて嬉しかったことがない。Railsでもそんなこと言ってたような。フォームでの更新やフロントエンドの書き換えは基本Hotwireでやっちゃうからサーバーサイドレンダリングになる。JSはいつ書くのか?となるがこれまでの経験上、なんだかんだ運用していくとStimulusでDOMをいじらないといけない要件が出てくる。いうコードこそ面倒な処理で膨れ上がったりするので最初からTSで書けるようにしてある。Viteの導入とかの手順はここに書くと煩雑になるから書かないが、雑だけどこっちの作業メモを見ると参考になるかも。https://scrapbox.io/razokulover-tech-memo/Rails+Stimulus+Vite+TypeScript+Biome+αruby-lsp/Rubocop/BiomeLinterとFormatterについて。Ruby側とJS側で設定が必要。RubyのLSPはruby-lspを使い、Linter/FormatterはRubocopを使っている。昔はrebornix.rubyを使っていたけど非推奨になったのでShopify製のLSPにした。業務でも使ってみてるけど特に問題はなさそう。JS側はBiomeを導入した。ESLint/Prettierが多く使われている印象だがBiomeならLintもFormattingも両方を管理してくれるし標準設定が優秀だから複雑な設定もほぼ不要で楽。RSpec/Capybara/PlaywrightテストはRSpecを使ってる。minitestでもいいんだけどこれについては標準といえど設定含めて慣れてるRspecを入れちゃっている。テストデータはfactory_botを使う。SystemテストはCapybaraとPlaywrightを使っている。SeleniumよりPlaywrightの方が安定している(諸説ある)傾向があるのでこちらを導入した。あと知らなかったんだけどPlaywrightがRails7.1以降で標準で使えるようになるらしいのでその意味でも使ってみた。https://note.com/dev_onecareer/n/n67d25088b100E2Eテスト、設定が面倒だったり処理時間が遅かったりして忌避されることもあるが個人的にE2Eテストは結構重要だと思っている。エンドユーザーにとっては最終的なアウトプットが正しく想定通り動いていないと意味なくて、これをE2Eテストによってある程度は保証できる。不安定でCIが遅くなるのは確かだし全ての仕様を漏れなく記述しようとしたりするとコードがどんどん肥大化する。どのくらいの粒度で書くのかは難しい。目安としては実際にユーザーやクライアントにアプリのURLを渡してやりそうな振る舞いから順に網羅していく感じ。このスライドが結構好き。Actions)CIでは一応LintとTestの実行を回してる。Actionsで設定してるだけ。特別なことはしてない。管理するのかというのは一つの悩みどころである。Credentialsが挙がる。実際に一部のプロジェクトで使ってもいる。秘匿情報を暗号化されたファイルとしてリポジトリに入れて置けるのでmasterキーさえちゃんと管理すれば複数人開発でも楽だよねという機能。微妙ポイントとしては秘匿情報をリポジトリ管理にしてるから秘匿情報の変更時にいちいちアプリのデプロイが必要になるという点。Appで設定はコードから分離しろと言ってるしそもそも時代に逆行してる感もある。いうわけで普通に環境変数を使えば良いよな...となったので開発時の環境変数設定用にdotenvを入れている。Storeを使うのが王道。どこにするかという問題も悩みどころなので少し書いておく。基本はコストを抑える/インフラ管理を極力したくないあたりの理由から初手PaaS次点で大手クラウド、みたいな優先順位になっている。VPSで全て管理というのはある程度スケールさせ安定運用させるには中々面倒なので個人サービスや転送コストがえげつないサービスとか特別な用途以外では業務で採用しない。スケール性と安定性を重視した本番環境を構築するならAWS/GCPのクラウドサービスを選択する。Runのサーバレス環境でアプリを動かす感じ。業務アプリならこの選択が基本。仮にどこかに引き継ぐとしてもやりやすいはず。した環境なら今だと最低でも月1万円以上コストがかかるので個人サービスやPoCとかには向かない。AWS/GCPを使う場合の面倒ポイントとしてインフラ設定をコード化したりデプロイや監視などの諸々の構築や運用がある。この辺は特に個人サービスやスタートアップの立ち上げ時なんかだと影響がでかいのでPaaSを使うという選択を取る。昔はHeroku一択だったけどOAuthトークン流出やSkebのゴタゴタとか最近はあんまり良い印象がない。個人的にはKoyebやRenderあたりを使う。Regionがあるのも良い(Renderは近くだとSingaporeしかない)。Pushのデプロイかコンテナデプロイが選べるが、前者はPushするだけでいいので楽だし後者は仮にAWS/GCPへ移行する際にスムーズにできそうというそれぞれのメリットがある。難点としてはKoyeb自体がスタートアップなので継続性に不安はある。いえばFly.ioも触ってみたりしたけどだいぶ使いにくかった印象で使っていない。どこのインフラを使うにしても重要なのは一つのプラットフォームで完結させること。アプリはWorkersでDBはPlanetScaleで〜みたいにインフラを複数社で色々使い分けないといけないのは運用がだるすぎる。個人レベルなら良いが自分以外が今後メンテする可能性もあるし業務では使いたくない。まとめ個人的なRails開発環境について書いた。今回紹介したRails環境のテンプレは下記にある。https://github.com/YuheiNakasaka/rails-templateこういうテンプレを作っておくといざ開発に取り掛かろうと思った時にすぐ着手できるようになるので良い。今時Railsで新規開発するんか?みたいな声も聞くけど受託開発系だと普通に全然あるので気にするな。scrapbox.io/razokulover-tech-memo/バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。