The problem of checking in modules is when a module compile binaries and you have developers working on different OS, like Ubuntu and OSX.
On Thursday, March 20, 2014 10:57:10 AM UTC-3, Peter Rust wrote: > > I'm not really experienced in this area, but some in the node community > say that checking in your dependencies is better than using "npm > shrinkwrap": http://www.futurealoof.com/posts/nodemodules-in-git.html. > The Golang community has the same stance. > > Here's one relevant paragraph from the above article: > > Doesn’t checking in node_modules create a lot of noise in the source tree > that isn’t related to my app? > > No, you’re wrong, this code is used by your app, it’s part of your app, > pretending it’s not will get you in to trouble. You depend on other > people’s code and they are just as likely to write new bugs as you are, > probably more so. Checking all of that code in to source control gives you > a way to audit every line that ever changed in your application. It allows > you to use $ git bisect locally and be ensured that it’s the same as in > production and that every machine in production is identical. No more > tracking down unknown changes in dependencies, all the changes, in every > line, are viewable in source control. > > That said, I'm sure some (many?) disagree and prefer to use "npm > shrinkwrap". > > -- peter > > On Wednesday, March 19, 2014 7:32:34 AM UTC-7, Patrick Debois wrote: >> >> Hi group, >> >> I'd like to get some feedback on the following flow of publishing nodejs >> apps in a continuous delivery mode: >> >> The flow I imagine is described below. I'm wondering if: >> >> - it makes sense to use an internal npm as build artefact repository >> - it annoys me that I have to change the version of the package.json >> (the source) to change the version of the artifact >> - every commit will result in 2 extra build commits >> - I could use another artefact repository like create rpm/deb >> packages or use 2 separate npm internal registraties (one for test , one >> for prod) >> >> Sorry if this seems trivial , but I could only find example to deploy to >> prod but didn't really care on a reusable build artefacts. >> I'd love to hear how you've solved this dance :) >> >> Patrick >> ------------------------------- >> Steps in the nodejs continuous delivery mode: >> Check-in: >> >> 1. developer checks in his code for the app >> 2. post-commit hook to run some basic unit tests >> 3. does push to git >> 4. git commit triggers build >> >> Build stage: >> >> 1. in build stage, I'd run grunt tasks to create consolidated >> javascript files etc... and run unit tests >> 2. once finished and succesful, I want to archive the build >> 3. then I'd want to publish it to my artefact repo >> 1. in increase the version with prerelease tags (using >> grunt-release), so it's not installed by @latest >> 2. run `npm shrinkwrap` to lockdown the versions >> 4. commit the version change, new build js & shrinkwrap back to git >> (with a tag) but carefully avoid a new trigger of the CI with [ci skip] >> 5. i publish this version to npm using `npm publish --tag rc` (actually >> using publishConfig to avoid updating >> lates<https://github.com/npm/npm/issues/4837> >> t) >> 6. if success, go to next stage >> >> Integration testing: >> >> 1. deploy on a machine (using npm install myapp@rc) >> 2. run my integration tests >> 3. if success, go to next stage >> >> UAT testing: >> >> 1. deploy on a machine (using npm install myapp@rc) >> 2. run my integration tests >> 3. if success >> 1. increase version >> 2. `npm publish --tag` latest >> 3. commit the version change, new build js & shrinkwrap back to >> git (with a tag) but carefully avoid a new trigger of the CI with [ci >> skip] >> 4. if success, go to next stage >> >> Deployment: >> >> 1. now on each of the production do the loadbalancer dance >> 2. and run npm install@latest of the app. >> >> >> >> -- -- 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/d/optout.
