Thanks Patrick, this is just what I was looking for!  It never occurred to 
me that npm would cover all this, although now it sure seems obvious.

Thanks for the sinopia recommendation too.  A good internal npm registry 
has been on my list of tools to find.


On Sunday, May 25, 2014 2:27:45 PM UTC-5, Patrick Debois wrote:
>
>  Hi Jake, 
>
> the question is do you want repeatable and fast deploys to production:
>
> - running npm install on each of the server will potentionally install 
> different version (have fun debugging that)
> - minizing, hashing, uploading to the CDN should be done only once, not 
> per server
>
> On your testing you install all your devdependencies, grunt tasks, pull 
> things from github if needed
>
> After testing a version, you package the app version:
>
>    - `npm prune` (remove dev dependencies) 
>    - add all dependencies left as bundledDependencies (basically 
>    vendoring) (see npm instal bundle-deps) 
>    - `npm shrinkwrap` (lock versions) 
>
> You can then use:
>
>    - `npm pack` (to create a local tarball) and put it somewhere on s3 
>    - or `use npm publish` (with a private repo like sinopia) 
>
> Then we tag the version with `npm tag app@VERSION pre-prod`
>  
> Then you install it to pre-prod however you like: 
>  
> We use sinopia as a distribution of the artefact (for the meta 
> information) and curl the tar ball directly
>  
>  NAME='app'
> TAG='pre-prod'
> VER=`npm view $NAME@$TAG dist-tags.$TAG`
>
>
> URL=`npm view $NAME@$TAG dist.tarball`curl $URL -u $USER:$PASSWORD -o 
> $NAME-$VER.tgz
>
>
>
>
>
>
>  
> The only thing left is to run `npm rebuild` to eventually recompile your 
> native libraries (if your test system does not have the same)
>
> If that works you only need to tag this version to production `npm tag 
> app@VERSION production`
>  
> Tagging the source repo is usually not enough: image you have to create a 
> new build because a dependency changed. There are now two version of the 
> same source version.  Unless you add all vendored versions to git as well - 
> but we find this confusing (but some like it this way)
>  
> Some Notes:
> - npm shrinkwrap does not play with some versions of npm (we use 1.4.5 for 
> now)
> - npm install is slow for big npm packages, curl does not have that issue
> - tagging with npm publish --tag (always adds latest), adding the tag to 
> the publishConfig in package.json does NOT add it to latest
>  
>
> After using this process, our builds became reliable, without dependencies 
> of (git, npmjs) while deploying/scaling new servers. Also less tools are 
> needed on the server so the initial machine creation is very fast. Same for 
> updates, just curl the new version, unpack it, switch the version in nginx.
>  
>  So my vote is: 
>  
>    - YES build all things in test 
>    - package it so you're working on the same artifact in test, pre-prod, 
>    prod 
>    - use a repo just a matter of convenience
>     
>
> hope this helps.
>
> On 25/05/14 14:32, Jake wrote:
>  
>  I'd like to know what people have done for node.js application 
> deployments.
>  
>  Coming from a compiled-language background, I'm used to compiling 
> things, packing them up into some artifact, and deploying that to a server. 
>  This seems unnecessary in node though.  
>
>  A few questions on this:
>  
>    1. Have you seen any benefit to packing up (perhaps just a zip file) 
>    all the files from a node application and putting that in an artifact 
>    repository?
>     2. Is there any reason not to just tag the source repo and copy 
>    (rsync, scp, etc) the files to the servers from there?
>     3. Is there any benefit to publishing the application to an internal 
>    npm repository and deploying from there?
>     
>  -- 
> Job board: http://jobs.nodejs.org/
> New group rules: 
> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
> Old group rules: 
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/nodejs/e8700c10-dd53-48a4-9bc0-0919675d3f0c%40googlegroups.com<https://groups.google.com/d/msgid/nodejs/e8700c10-dd53-48a4-9bc0-0919675d3f0c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  

-- 
Job board: http://jobs.nodejs.org/
New group rules: 
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/nodejs/b135f376-308e-4a81-b03c-6d27479a9465%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to