> That said, I'm sure some (many?) disagree and prefer to use "npm shrinkwrap".
Yes.
Keeping node_modules in git is extremely noisy. I strongly believe that git should not have anything machine-generated in it. If something is generated automatically, it should not be in git. Since modules are installed using npm from an external source, they should not be in git.
Checking in node_modules have just one advantage: "git blame" across all dependencies. But even then I usually prefer to have two git repositories, one for development and one for deployment / CI.
20.03.2014, 17:57, "Peter Rust" <[email protected]>:
--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:
- developer checks in his code for the app
- post-commit hook to run some basic unit tests
- does push to git
- git commit triggers build
Build stage:
- in build stage, I'd run grunt tasks to create consolidated _javascript_ files etc... and run unit tests
- once finished and succesful, I want to archive the build
- then I'd want to publish it to my artefact repo
- in increase the version with prerelease tags (using grunt-release), so it's not installed by @latest
- run `npm shrinkwrap` to lockdown the versions
- 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]
- i publish this version to npm using `npm publish --tag rc` (actually using publishConfig to avoid updating latest)
- if success, go to next stage
Integration testing:
- deploy on a machine (using npm install myapp@rc)
- run my integration tests
- if success, go to next stage
UAT testing:Deployment:
- deploy on a machine (using npm install myapp@rc)
- run my integration tests
- if success
- increase version
- `npm publish --tag` latest
- 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]
- if success, go to next stage
- now on each of the production do the loadbalancer dance
- 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.
--
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.
