3

TL;DR: assets:precompile を実行すると、非本番環境用に生成されたアセットに本番アセット ホストが挿入されます。

背景: Rails アプリをデプロイする現在の方法は、CI サーバーが成功した各ビルドを統合環境に tarball としてデプロイすることです。そして、この tarball は prod env まで昇格し続けます。しかし、アプリを tar して別の環境にプロモートする前であっても、実行します。

rake assets:precompile

このコマンドが tar 化の前に実行されると、コンパイル済みのアセットが tarball の一部になり、これにより個々の環境の展開時間が節約されます (プリコンパイルは低速です)。

問題: この配置は、運用環境に asset_host プロパティを導入するまで問題なく機能していました。assets:precompile はデフォルトで Production env で実行され、sass ファイルは image-url タグを使用してイメージ アセットを参照するため、アセット ホストがプリコンパイルによって取得され始め、生成されたアセットがプロダクションへの直接 URL 参照を持ち始めました。 asset_host のサーバー。明らかにこれは受け入れられません。

インターネットで検索すると、このGithub Issueが発生しました。これは、私が抱えている問題をかなり詳しく説明しています。gem メンテナーの反応を見ると、assess:precompile を PER 環境で 1 回ではなく、すべての環境で 1 回実行するのは悪い考えのように思えます。しかし、プリコンパイル時間が遅いことを考えると、それが私たちにとって唯一の方法のようです。

では、他の Rails デプロイメントはこの問題にどのように対処しているのでしょうか?

4

2 に答える 2

0

public/assets/manifest.yml をソース管理にチェックインします

于 2013-04-05T09:21:26.737 に答える
0

私は非常によく似た問題を解決していました。私たちの解決策は、個々の環境ごとに事前コンパイルを実行することでした。この場合は、ステージング環境と本番環境でした。理由は同じで、異なるアセット ホストです。

可能であれば、プリコンパイルが必要で、アセットが本当に必要な環境でのみプリコンパイルを実行してください。

capistrano-extカピストラーノを使用して、 gemとともにデプロイを行います。これにより、さまざまなステージを指定し、各ステージの設定とステージ (またはステージ == 環境の場合は環境) に固有のメソッドを指定できます。

于 2012-10-25T20:19:26.510 に答える