12

ヘロクは素晴らしいです。しかし、デプロイするたびに、Heroku はすべてのパッケージを再ダウンロードして再構築するのが好きなようです。これsocket.ioにmailparserは約 3 分かかります。

展開プロセスを高速化する方法はありますか? これらのアイテムをキャッシュできることを Heroku に伝える方法はありますか? または、事前に作成したものをアップロードできnode_modulesますか?

4

6 に答える 6

9

今日の時点で、Heroku はついにnode_modulesフォルダをキャッシュしているようです!

-----> .slugignore パターンに一致する 6 つのファイルを削除しています。

-----> Node.js アプリが検出されました

-----> 要求されたノード範囲: 0.10.x

-----> 解決されたノードのバージョン: 0.10.22

-----> ノードのダウンロードとインストール

-----> node_modules をキャッシュから復元する

-----> 依存関係のインストール

-----> 未使用の依存関係の削除

-----> 今後のビルドのために node_modules ディレクトリをキャッシュ

-----> node-gyp および npm アーティファクトのクリーンアップ

ビルド時間は、今では 3 秒ほどです。

于 2013-12-02T19:43:38.420 に答える
2

プロセスを高速化するために私が行ったことの 1 つは、.slugignore ファイルをメイン フォルダーに追加し、アプリを実行したくないすべてのファイルとフォルダーを追加することでした。

.slugignore ファイルのサンプル コンテンツ:
作業
モックアップ
*.psd
*.pdf

于 2013-02-27T13:02:31.127 に答える
2

私は同じ問題に直面しています。

node_modulesフォルダーのキャッシュに関するいくつかの議論: https://github.com/heroku/heroku-buildpack-nodejs/pull/37

別のアイデア: https://github.com/heroku/heroku-buildpack-nodejs/issues/25

現在、いくつかの解決策を考えています。

  1. node_modules別のブランチにチェックインする: コア Node.js メンテナーは、node_modulesフォルダーをソース管理 (ライブラリではなくアプリ用) にチェックインすることを実際に推奨しています。私はこれが好きではありません。ただし、それを回避する方法は、無視しない別のファイルを持つ別productionのブランチを持つことです。デプロイしたい場合は、マスターからリベースを実行するだけでチェックインされます。少なくともこれにより、マスター ブランチが依存関係から解放されます。.gitignorenode_modulesnode_modules

  2. preinstallスクリプトを追加して、package.json圧縮された依存関係 zip をダウンロードします。依存関係をバンドルして S3 にアップロードするために、事前プッシュ git フックを追加することもできます。ただし、これはおそらく遅すぎるでしょう。

  3. 以下を変更しheroku-buildpack-nodejsます: 未処理のプル リクエストをnode_modulesキャッシュと統合します。

    heroku config:set BUILDPACK_URL=https://github.com/opdemand/buildpack-nodejs.git

于 2013-07-11T11:11:24.753 に答える
1

heroku-buildpack-nodejsで最近進歩があったようです。

プルリクエストがマージされたら、追加できます

heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs

あなたのheroku環境変数に。

今のところ、David Dollar のフォークされたリポジトリは次の場所にあります。

https://github.com/ddollar/heroku-buildpack-nodejs

これを使用するBUILDPACK_URLと、npm モジュールをキャッシュする必要があります。node.js 0.10.5a、npm version: 1.3.5、npm_modules in で試してみました.gitignore。Tt は今のところ問題なく動作しているようです。

于 2013-08-30T14:43:01.147 に答える
1

同じ質問がありました ( Heroku にデプロイするたびに npm の更新を回避するを参照)。

Heroku はダウンロード/ビルドなどを強制します。アプリを「白紙の状態」で開始する必要があるため、以前の削除されていないファイルを消去する必要があるため、アプリを別のサーバーに移動するとき、新しい Web dyno を割り当てるときなどです。

問題は明らかにネイティブ パッケージと再コンパイルにあります。すべての js のみのパッケージについては、自分のプロジェクトでコミットし、package.json から削除します。数秒は増えますが、それほどではありません。

同じ構成のLinuxボックス（またはVM）にアクセスできる場合、ネイティブモジュールをプリコンパイルしてコミットできるはずです（たとえば、Linux-amd64用にコンパイルされたバイナリを使用して、Herokuでwkhtml2pdfを正常に実行できます）。 - 本日現在、Linux [...] 2.6.32-350-ec2 #57-Ubuntu SMP [...] x86_64 GNU/Linux.

いつか壊れる可能性があるため、決定的な解決策としてはお勧めしませんが、アプリが実行されるプラットフォームをherokuが保証しているとは思えません。

于 2013-05-03T14:27:24.517 に答える