4

私は、アプリケーション開発/展開サイクルのさまざまな段階でいくつかの宝石を使用する単純な (またはそう思った) Sinatra アプリを使用しています。

  • 依存関係を管理するバンドラー
  • ビルドタスクのレーキ
  • アセットのプリコンパイル用スプロケット
  • テスト用のRSpec 2
  • 展開用のカピストラーノ

Gemfile はグループに含まrspectestます。

Rakefile は、assets:compileSass を CSS に、CoffeeScript を JavaScript に変換し、結果のファイルを連結するタスクを定義します。

Capistrano はbundle install --without development test、実稼働 (およびアセットのコンパイル) に必要な gem のみが実稼働サーバーにインストールされるように実行されます。また、最終的にサーバー上で実行される Cap タスクも実行bundle exec rake assets:compileします。

ここまでは順調ですが、RSpec Rake タスクを Rakefile に追加したいのですが、ここで問題が発生します。ローカルで実行すると問題なく動作しますが、実行するcap deployとサーバーでエラーが発生します: no such file to load -- rspec/core/rake_task.

これは理にかなっています。バンドルをインストールするときに RSpec はサーバーにインストールされず、spec タスクが実際にサーバーで実行されることはありません。タスクを定義しようとしただけでエラーが発生します。

これを処理するためのいくつかのオプションを考えることができますが、どれも私には適切ではないようです。

  • ブロックにラップrequire 'rspec/core/rake_task'してbegin...rescueエラーを無視する
  • rspecグループから外すtestか、強制的にサーバーにインストールする
  • assets:compileタスクのみを含む展開中に別の rakefile を使用する
  • spec呼び出されたときに RSpec のみを必要とする独自のタスクを定義する
  • サーバーではなくローカルでプリコンパイルを実行します (これらのオプションの中で私のお気に入り)

ここでのベストプラクティスは何ですか?

4

3 に答える 3

4

個人的には、サーバー上で Rake が呼び出されることはあまりないので、単純にして以下を使用しますrescue

begin
  require 'rspec/core/rake_take'
rescue LoadError
end

Railsでこれに遭遇したことがない理由はわかりません。

于 2013-05-31T09:05:02.450 に答える
1

私はこれを行うことで解決します

require 'rspec/core/rake_task' if defined?(RSpec)

理由は単純です。他のソリューションでもおそらく十分ですが、私の意見では、柔軟性よりも複雑さが増すと思います。将来、このようなケースがさらに発生する場合は、別の解決策を検討することを検討します.

于 2013-05-31T09:03:03.810 に答える
0

私はほとんど同じ問題を抱えていました。

これが「ベストプラクティス」かどうかはわかりませんが、Rakefileでこれを行うことになりました:

if (Rails.env.migration? || Rails.env.production?)
  # define rake tasks that depend on gems installed only in dev/test envs
end

(本番環境と同じデータベースを指す移行用の別の環境を使用しますが、スキーマの変更を行うために必要なより高いデータベース権限が必要です。)

于 2014-11-20T19:20:58.280 に答える