Bundlerの使い方そのものについては詳しく解説された良いサイトが多数存在しますので省略させて頂いて、ポイントだけ書いておこうと思います。プロジェクトをGitで管理していることも考慮に入れてます。
bundle install の際は --path vendor/bundle オプションをつける
--pathオプションをつけないとシステムデフォルトの位置にgemパッケージがインストールされます。しかしせっかくBundlerを使うのであれば、プロジェクトごとに個別にgemを管理したほうがよいですね。プロジェクトごとに違うバージョンを使うこともありえますし。ということでインストール先を指定するため--path vendor/bundleオプションをつけます。vendor/bundleという名前にするのは、後で出てくる--deployment オプションと統一するためです。
Gemfile と Gemfile.lock だけをGit管理対象とし、.bundle ディレクトリと vendor/bundle ディレクトリは .gitignore で無視する
上記の --path 指定をして bundle install を実行すると、.bundle/configという設定ファイルも自動的に生成されます。このファイルにはインストール先が記録してあって、次回から--path指定をしなくても済むようになります。しかし.bundleには環境固有の設定も入るようなので、Git管理対象にはしないほうが良さそうです。もちろん、gemパッケージのインストール先であるvendor/bundleディレクトリも管理対象から外します。
そのため、Gitをクローンした各開発者には個別にbundle install --path vendor/bundleを実行してもらう必要があります。(gemをアップデートした際には bundle update)
デプロイする際は --deployment オプションをつけて bundle install しておく
bundle install コマンドにはデプロイ用のオプション --deployment があります。これは、vendor/bundle 内に必要な依存gemパッケージを確実に揃えるとともに、その後Gemfileを変更してバージョンを変えられないようにします。デプロイをスクリプトで自動化している際には、どこかのタイミングでbundle install --deployment を行うようにしておくといいでしょう。
基本的に--path vendor/bundle を指定して bundle install を実行するとvendor/bundle 内に必要な依存gemパッケージは揃うと思うんですが、システム共通でインストールしたgemが既にあるとインストールしてくれないみたいbundle install --disable-shared-gems vendor/bundle とやればいいみたいですが、だったら固定操作まで一気にやってくれる--deployment使ったほうが楽でしょうとうことで。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。
0 件のコメント:
コメントを投稿