Hi Patrick,
 
 
It definitely makes sense, that's what I'm using usually.
 
"latest" tag is kinda buggy, I'm using "production" tag instead. Also, "npm upgrade" doesn't work very well, so in some cases you have to do "rm -rf node_modules && npm install" instead. But other than that, this flow works pretty well.
 
--
Regards,
alex
 
19.03.2014, 18:32, "Patrick Debois" <[email protected]>:
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 latest)
  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.

--
--
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.

Reply via email to