Develop Reference

NodeJS server side application deployment cosiderations

I am writing a nodejs application with Angular as my front end.
For this I am having Git as my code management server.
For client, I am doing minification and it is ready for production.
But I am not sure, how to prepare server side files for production.
Do we need to just copy all the Git folders into production server?.
Let me know the best way to deploy nodejs server application.

You could use pm2 as your daemon to keep your nodejs app up all the time.
Try not to include node_modules in the repo, cause different machines have different setups/installations, you cannot tell if one package would work before you run it unless you npm install them.
If you are familiar with Docker, use it, pre-bundle all (include node_modules) files into the docker image, and you do not need pm2 here, Docker itself can restart automatically. This is the ideal approach.

It really depends on how you (or your company) want to organize the workflow and the size of the project.
Sometimes I too use a GIT repository, because then is really simple to update: just a git pull and (if server files got edits) a pm2 restart N command.
In this way, you dont have to install the whole development stack in order to compile (and minify) the bundles - I guess you work on your local machine where all the development tools are installed.
Keep in mind to use the --dev flag while installing packages that are only required in development mode, so you can keep the production server as slim as possible.
A good practice I found is to add some random tokens inside the final bundle filename (both for js and css) that get then injected inside the final html static files, to avoid the refresh the page loop.
Once you have the bundle files on your dev machine, just upload them to the server (ftp, git, rsync, sshfs mount, whatever you like) and (if server files got edits) restart/reload the node process (Im using pm2 for this, its really great). If you only edited client files, no reload is needed.
Starting from here, there a lot of ways more or less sophisticated to do the job, like git pipelines for example.. but depends on the situation.
Edit: this is a good article about task runner (gulp vs grunt vs vanilla npm), while may be a little off topic, it analyze some aspect of the common deployment process

Build for js environment without npm?

We are currently building our frontend js codebase (angularjs) using nodejs with grunt, which seems to be a popular setup, but we are not happy with this solution. Does anyone have suggestions for a build setup for e.g. linting, minimizing our js, running less, etc (in addition to some custom steps for angular in general and for our application specifically) without using nodejs at all?
I would leave it at that to avoid starting a flamewar, but here are, for context, some of the shortcomings of the current setup in our view:
grunt does not have even the basic functionality of a 1970s build system, like automatically re-building only files that have been modified based on file modification time
npm is causing constant headaches running on our build servers at every build

If grunt does not have even the basic functionality of a 1970s build system, why won't you use a 1970s build system then?
Just use make if that's what you're happy with. It still works fine. There's no reason not to use it if it you're satisfied with how it works.

What are npm, bower, gulp, Yeoman, and grunt good for?

I'm a backend developer, and slightly confused by npm, bower, gulp, grunt, and Yeoman. Whenever I ask someone what their purpose is, the answer tends to boil down to dependency manager - for all of them. Surely, we don't need four different tools that all do the same?
Can someone please explain what each of these is good for in as few sentences as possible - if possible just one per tool, using language a five year old (with development skills) could understand?
For example:
SVN stores, manages, and keeps track of changes to our source code
I have used maven, Jenkins, nexus and ant in the past; maybe you could compare the tools above to these?
Also feel free to add other front-end tools to the list.
Here is what I have found out so far - not sure it's correct, though:
bower dependency manager for front-end development/JS libraries, uses a flat dependency list
npm dependency manager for node.js server, can resolve transitive dependencies/dependency trees
grunt runs tasks, much like Jenkins, but locality on the command line
Yeoman provided scaffolding, i.e skeleton projects
gulp same as grunt, but written in js only
node.js server for js apps?
git decentralized SCM/VCS, counterpart to svn/cvs
Am I close? :)

You are close!
Welcome to JavaScript :)
Let me give you a short description and one feature that most developers spend some time with.
bower
Focuses on packages that are used in the browser. Each bower install <packagename> points to exactly one file to be included for (more can be downloaded). Due to the success of webpack, browserify and babel it's mostly obsolete as a first class dependency manager.
2018 Update: bower is mostly deprecated in favour of NPM
npm
Historically focuses on NodeJS code but has overthrown bower for browser modules. Don't let anyone fool you: NPM is huge. NPM also loads MANY files into your project and a fresh npm install is always a good reason to brew a new cup of coffee. NPM is easy to use but can break your app when changing environments due to the loose way of referencing versions and the arbitrariness of module publishing. Research Shrink Wrap and npm install --save-exact
2018 Update: NPM grew up! Lot's of improvements regarding safety and reproducibility have been implemented.
grunt
Facilitates task automation. Gulps older and somewhat more sluggish brother. The JavaScript community used to hang out with him in 2014 a lot. Grunt is already considered legacy in some places but there is still a great amount of really powerful automation to be found. Configuration can be a nightmare for larger use-cases. There is a grunt module for that though.
2018 Update: grunt is mostly obsolete. Easy to write webpack configurations have killed it.
gulp
Does the same thing as grunt but is faster.
npm run-script
You might not need task runners at all. NodeJS scripts are really easy to write so most use-cases allow for customizedtask-automation workflow. Run scripts from the context of your package.json file using npm run-script
webpack
Don't miss out on webpack. Especially if you feel lost on the many ways of writing JavaScript into coherent modular code. Webpack packages .js files into modules and does so splendidly. Webpack is highly extensible and offers a good development environment too: webpack-dev-server
Use in conjunction with babel for the best possible JavaScript experience to date.
Yeoman
Scaffolding. Extremly valuable for teams with different backgrounds as it provides a controllable common ground for your projects architecture. There even is a scaffolding for scaffolds.

So, Since you have a good idea what each is, I will give you a simple workflow.
I use yeoman to scaffold a basic skeleton.
I am using node as the runtime for my application. ie. run node appname
I use npm to install node modules for helping me write the application in node
I might need some component from bower like front-end libraries so use bower to fetch these.
Now to do some repetitive task I will use grunt or gulp to write some tasks. So everytime I want to repeat it, say minimify my js files I call grunt/gulp and make them do it. Difference you ask, Gulp is stream based while grunt is task based.
I do version control using git to keep track of changes

Gulp vs Grunt: Gulp provides more flexibility with task automation, Grunt comes built in with a lot of functionality as per the common development practices. There are two main differences between Grunt and Gulp:
Grunt focuses on configuration, while Gulp focuses on code
Grunt was built around a set of built-in, and commonly used tasks, while Gulp came around with the idea of enforcing nothing, but how community-developed micro-tasks should connect to each other Read here
NodeJS: It is a Non-blocking server-side scripting language. Which means operations won't block further execution until current operation finishes.
Git: As you mentioned it is an SCM tool, a widely used one. As per the GitHub docs it is different from other SCM tools as data is never deleted.
Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
Read More
Bower vs NPM : Bower and NPM are dependency managers but Bower modules are for front-end development. NPM is a huge collection of modules to be used with NodeJS backend. This SO answer covers it better

I added some details:
npm is a package manager for javascript, npm is nodejs's package ecosystem, but it can be used only for front-end projects.
grunt & gulp are useful to separate and automate tasks like minification, compilation, unit testing on command line, it's a way lighter solution than (for example) visual studio as the process is only a separated (and usually lightweight) command line/process.
Regarding the differences between gulp, grunt and bower there is already a ticket: What are the differences between Grunt, Gulp.js and Bower? Why & when to use them?
Nodejs is more a javascript runtime. Node.js allows the creation of web servers and networking tools using js and a collection of "modules" that handle various core functionality and other core functions. Source
This ticket resumes the differences between Git and Subversion: Why is Git better than Subversion?

Why build a MEAN app on the server?

My question is more on the lines of strategy than actual implementation.
And basically I'm wondering why do we build our MEAN apps on the server? And by build I mean getting components (npm install && bower install) and doing all the concat and minify stuff.
I'm trying to create my build system, and up until now I've been using a version of John Papa's build system, but my build is taking longer and longer on the server. So doesn't it make sense to just build everything locally and deploy it to the server? Or am I missing something?
Thanks

The build shouldn't happen on runtime. You have it partially right, build upfront, than deploy created artifact.
But the crucial idea is to have Continuous Integration in place. Meaning build server that is not on your local machine, which takes the code from SCM, builds it, run the tests, create deployable artifact and store it in some artifact repository (e.g. npm registry).
If you take it further and you also automatically deploy artifact into non-PROD envs, you are starting to dig into Continuous Delivery space.
If this build and deploy pipeline installs the artifact into PROD every commit, you are having Continuous Deployment working.
EDIT - reaction on comment:
The main idea is to have it continuous. Meaning, the full build is kicked off on regular basis, optimally every commit/git push.
If this is configured on you local machine and you are one man shop, that is probably fine. But as I played in my free time with various projects, I found that build on every commit may be resource intensive for my local machine and it was convenient to leave this responsibility for some third party service (especially when it's free).
There are plenty of online solutions for CI servers.
I used with success http://codeship.com and http://drone.io. http://cloudbees.com gives you hosted Jenkins. For open source projects they are free.
If you projects are not open source you will need to spend some bucks on it, but it should be cheap for one man projects.

What happened to Node.js builds for Raspberry Pi

Using these instructions I was able to easily install node.js on RPi. The problem was that since build v0.10.29 node.js has not included a build for the RPi. The current build is v0.10.31.
Does anyone know why node.js stopped including the RPi build with their new versions?
Is there a way to get the latest RPi build from another source?
This is my first question on SO, so hopefully I haven't mucked it up too much.

I took a look at the google group Zlatko suggested. I found that Nathan Rajlich compiles the RPi builds, but has run into an issue since v0.10.29.
Currently, however, v0.10.29 and v0.10.30 are failing to compile on ARM out-of-the-box. Follow this issue for updates on that: https://github.com/joyent/node/issues/8062.
It seems there is some hacking around to deal with the errors cropping up. It is beyond me, which is why I liked the node.js build for the RPi in the first place. I will continue with the old node.js build and hope for a RPi build in the future.

Follow these instructions here:https://github.com/audstanley/Node-MongoDb-Pi
You'll get nodejs v5.3.0 and MongoDb on the pi view the read me on how to install. Only four lines of code you'll need to copy paste into your CLi, and you'll have nodejs and MongoDb up in about five hours. (Mongodb takes quite some time to compile).