git - What is the best approach for deploying a sails.js application? -

i developing web application using sails.js back-end. app used different schools , first approach deploy each school instance of application.

example:

school1.application.com having instance of sails app on school.application.com:8080 school2.application.com having instance of sails app on school.application.com:8081

each instance have bitbucket repository (or branch) , source updated using git.

for maintenance purpose, thinking of using dashboard connected git repository , manage push there.

on other hand, more manageable have 1 instance school how used separate database each 1 ? using 1 db not risky when having 20 schools ?

using second approach, if application down, schools affected opposed first one.

i hope clear in explanations.

thank insights.

where sails app hosted? you? i.e. nodejitsu, amazon, etc. or app deploy on school server?

1. approach: if you'll host app, can make 1 app , deploy once. add schools models , create relationship between users. i.e.:

   // student.js model    module.exports = {      attributes: {        name : { type: 'string' },        lastname : {           type : 'string'       },       // school student belongs      school : {        model : 'school'      } 

and way make 1 api rule them all, , give customers 1 single url logging access. can use mongo or sql because waterline don't care db, build relationship between models. check waterline , models docs: https://github.com/balderdashy/waterline-docs/blob/master/associations.md

1. approach: can make deploy independently every school, , use 1 db rule them all, sure avoid risk wipe data every time deploy, sails ask if want wipe de data in db or alter data (be careful because experimental feature).

2. approach: deploy branch independently own db (if school host app best approach), , change config/connections.js every deploy. approach best if don't want shutdown users when need maintenance or implement customs features, you'll need work more, because you'll going maintenance 20 instances separately.

i recommend 1st approach.