Heroku è fantastico. Ma ogni volta che distribuisco, Heroku sembra voler riscaricare e ricostruire tutti i pacchetti. Con socket.io e mailparser ci vorranno circa 3 minuti.Accelerare la distribuzione su Heroku
C'è un modo per accelerare il processo di distribuzione? C'è un modo per dire a Heroku che può mettere in cache questi oggetti? O posso caricare preinstallato node_modules?
Sembra come ad oggi Heroku sta finalmente memorizzando nella cache la cartella node_modules!
-----> Eliminazione di 6 file corrispondenti a modelli .slugignore.
-----> Node.js app rilevato
-----> Gamma nodo richiesto: 0.10.x
-----> versione nodo Risolto: 0.10.22
-----> Download e installazione nodo
-----> Ripristino node_modules dalla cache
-----> Installazione dependen Cies
-----> potatura dipendenze inutili
-----> Caching node_modules directory per il futuro si basa
-----> Pulizia nodo-gyp e manufatti NPM
Il tempo di costruzione è come 3 secondi per me ora.
yup Ho avuto la stessa esperienza anche oggi. Lo memorizzerà sempre in cache o saprà quando si aggiornerà automaticamente ora? – Alexis
Non ho una fonte, ma immagino questo: se semplicemente copiano la cartella 'node_modules' nel progetto ed eseguono' npm update', aggiorneranno solo le parti che necessitano di un aggiornamento. Quindi, in pratica, npm lo gestisce già bene. Questa è la bellezza di npm, esegue il mapping dell'intero albero delle dipendenze al filesystem. – Prinzhorn
Dopo una settimana posso confermare che ogni volta che aggiorno una dipendenza del modulo e spingo a heroku che solo questo modulo viene scaricato dal registro di NPM. È molto più veloce di prima. – Prinzhorn
Una cosa che ho fatto per accelerare il processo è stata aggiungere il file .slugignore alla cartella principale e aggiungere tutti i file e le cartelle che non volevo eseguire l'app.
contenuti Esempio di file di .slugignore:
lavorano
mockup
* .psd
* .pdf
ho avuto la stessa domanda (vedi Avoid npm refresh after every deployment on Heroku).
Heroku forza un download/build/ecc. sequenza perché devono avviare un'app con una 'lavagna vuota': per pulire i file non eliminati precedenti, quando spostano la tua app su un altro server, quando assegni nuovi web dynos, ecc.
Il problema è chiaramente con i pacchetti nativi e ricompilazione. Per tutti i pacchetti js-only, li impegno con il mio progetto e li rimuovo da package.json. Guadagna qualche secondo, ma non così tanto.
Devo essere possibile precompilare e eseguire il commit di moduli nativi (eseguo con successo wkhtml2pdf su Heroku, ad esempio, con un binario compilato per linux-amd64), se si accede a una macchina Linux (o VM) con la stessa configurazione - ad oggi, Linux [...] 2.6.32-350-ec2 #57-Ubuntu SMP [...] x86_64 GNU/Linux.
Anche se non lo consiglierei come soluzione definitiva, poiché è probabile che si rompa un giorno - Non mi sembra che heroku garantisca la piattaforma su cui gira un'applicazione.
Ho riscontrato lo stesso problema.
Alcuni discussione qui circa la memorizzazione nella cache della cartella node_modules: https://github.com/heroku/heroku-buildpack-nodejs/pull/37
Un'altra idea: https://github.com/heroku/heroku-buildpack-nodejs/issues/25
Sto pensando di alcune soluzioni al momento.
Arrivo node_modules in un ramo separato: Il nucleo Node.JS manutentori effettivamente raccomandano verifica nella cartella node_modules nel controllo del codice sorgente (per le applicazioni, non libs). Non mi piace. Un modo per aggirarlo potrebbe essere quello di avere un ramo separato production con un diverso file .gitignore che non ignori node_modules. Quando si desidera eseguire l'implementazione, è sufficiente eseguire un rebase dal proprio master e verrà eseguito il check-in di node_modules. Almeno ciò mantiene il ramo principale libero dalle dipendenze.
aggiungere uno script preinstall-package.json per scaricare la dipendenza compresso zip: Si potrebbe anche aggiungere un gancio git pre-push per impacchettare le dipendenze e caricarli su S3. Questo probabilmente sarebbe troppo lento però.
Modificare il heroku-buildpack-nodejs: Integrare l'eccezionale richiesta di pull con node_modules caching:
heroku config:set BUILDPACK_URL=https://github.com/opdemand/buildpack-nodejs.git
sembra che c'è stato di recente corso al heroku-buildpack-nodejs.
Una volta che la richiesta di pull è fusa, è possibile aggiungere
heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs
al vostro heroku environment variables.
Per ora, repository biforcuta di David Dollar è disponibile a
https://github.com/ddollar/heroku-buildpack-nodejs
Con questo come i tuoi BUILDPACK_URL dovrebbe memorizzare nella cache i moduli NPM. L'ho provato con node.js 0.10.5a, versione npm: 1.3.5 e npm_modules in .gitignore. Tt sembra funzionare bene finora!
Partenza questo ramo della nuova buildpack Heroku Node.js, ora in versione beta, che supporta la memorizzazione nella cache node_modules tra costruisce:
https://github.com/heroku/heroku-buildpack-nodejs/tree/diet
usarlo:
heroku config:set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs#diet -a my-node-app
git commit -am "fakeout" --allow-empty
git push heroku
Il [build-pack] (https: // github.it/heroku/heroku-buildpack-nodejs) (che è un codice che trasforma il tuo codice sorgente in quello che viene distribuito su Heroku) dovrebbe già essere in cache 'node_modules' tra le build. Almeno lo dice nel README. Sei sicuro che questo è ciò che sta rallentando la tua build? – friism
@friism Immagino che utilizzino il caching NPM standard, quindi i moduli devono ancora essere decompressi, copiati e, soprattutto, ricompilati dopo ogni push. Se si dispone di moduli con una struttura di dipendenza promiscua o in base alle estensioni C++ (mongodb, socket.io, ecc.) È necessario un po 'di tempo. –