When a package goes to a production system, it should be ready to drop in. You should have versionized binary artifacts stored that can be dropped anywhere. The binaries should be literally identical across all similar systems. Otherwise reliable deploy and support are nearly impossible, and small variants can mean your tests ran against a non-identical binary, making deploy unreliable.
I consult on business ops in tech, deploying anything that isn't 100% binary identical across all instances is big trouble (which, of course, led to some good consulting revenue for me to fix :-) ). However, if you have CI with a compilation stage, your best practice might be: a) Do not include node_modules, just package.json in version control. b) Do not deploy to production, but rather to your CI system, which does the build and creates a packaged up artifact, versionizes and stores it, and runs all your integration tests. c) Deploy to prod (or dev or UAT or whatever) from the artifact, so you are guaranteed identical. The problem is many devs on a small scale (which is what most startups are) build locally and then push directly to your PaaS via git, jitsu, etc. I don't have an easy solution for the above, although some of those CI offerings (circleci, etc.) are reasonable solutions. Personally, I think how those PaaS use your package.json to rebuild node_modules is bad practice. On Wed, Nov 6, 2013 at 4:43 PM, Alex Kocharin <[email protected]> wrote: > > Why do you think compilation on deploy is a horrible idea? Is it because > of a big compilation time, or are you unsure that compilation will produce > the same results on all hosts? > > > > 06.11.2013, 15:34, "Brian Lalor" <[email protected]>: > > On Nov 5, 2013, at 11:25 PM, Will <[email protected]> wrote: > > For the Googlers of the future that reach this thread: the answer depends > on the nature of your project. > > - *Do** track* `node_modules` in your repo if you are deploying an app. > > > This is not as solved a problem as Mikeal and others would like to think. > From an operations perspective, doing *any* compilation on deploy is a > terrible idea. It’s a HORRIBLE idea. It’s a product of developers who are > ignorant of deploying applications repeatably and at scale. The only thing > you should be deploying is binary packages, compiled for the target you’re > deploying to, preferably in a system package (deb, rpm). Your production > systems shouldn’t even *have* gcc on them, and that’s required if you have > to run “npm rebuild” for a deployment step. > > npm’s dependency resolution and loading model is excellent, but if “npm > shrinkwrap” — the only tool in the suite that’s supposed to help solve the > floating transitive dependency problem — doesn’t do the job, then it needs > to be fixed. Checking dependencies into source control is a hack. > > npm’s model has greatly simplified the way I do deployments. Ruby’s gems > suck, Python’s less onerous but still kind of a pain. It’s amusing and > painful to watch the Fedora folks try to bend node dependency model to fit > their archaic packaging standards (do yourself a favor and just don’t use > anything node-related from EPEL). npm needs to adopt the Maven central > repository’s roach motel contract: packages check in, but they never check > out. This combined with a reliable way to lock down dependency versions > and and compile-once binary deployment packages means never having to run > “npm install” or “npm rebuild” on a production box, no matter how old your > application is. > > -- > Brian Lalor > [email protected] > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/mqVj8f47P_U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
