デフォルトの「デプロイ」タスクがリモート マシンでアセットのプリコンパイルを行うことに気付きましたが、これには次のような悪影響があります。
- プリコンパイル中の奇妙なグリッチ アセット (ライブ サイト上)
- 構成のエラーにより、応答コード 500 でダウンタイムが発生する
- 長時間かかる作業
私はこれを見てきました。これは、プリコンパイルするものが何もないときにプリコンパイルを行わないようにすることで、問題を少し軽減します: Speed up assets: precompile with Rails 3.1/3.2 Capistrano deployment
しかし、より良い解決策があるはずです。
誰かがこれらを試しましたか：
- すべてをテストできる「ステージング」場所に常にデプロイしてから
cap enliven、Webサーバーのフロントエンドに他のポートの使用を開始するように何らかのタスクを追加しますか? （nginxを編集して再起動することでこれを手動で管理できます。次に、インクルードとキャップタスクを使用してそれをupstream少し自動化できます。）nginx.conf - ローカルでプリコンパイルしてから、rsync 経由でファイルをプッシュするだけです。私は #1 を好みますが、これはより小さなステップであり、おそらく現在の動作よりも優れたデフォルトとして機能します。
明らかな何かが欠けていますか？私は Rails アセット + Capistrano のデプロイは初めてですが、このデプロイのベスト プラクティスはそのままでは利用できないようです。