Sviluppo Ruby / RoR: desktop o server [chiuso]

Hai bisogno di un server di sviluppo, se il team ha più di 3 membri. Per 2 sviluppatori: le macchine locali sono sufficienti. Il processo di sviluppo va sempre su macchina locale e sul server di sviluppo - gli sviluppatori controllano, se il progetto è pronto per il test.

Server di test solitamente utilizzato per le modifiche di revisione da parte di tester / clienti / gestori.

E dopo aver esaminato il prodotto sul server di prova, puoi inviarlo alla produzione.

In altre parole, se uno sviluppatore, sviluppando un progetto per se stesso, non ha bisogno di entrambi i server di sviluppo e di test. Solo macchine e produzione locali. Se ha un client, ha bisogno anche di un server di test. E se ha altri giocatori della squadra, hanno bisogno di un server di sviluppo.

Quali benefici otterrai sullo sviluppo su un server di prova? Non riesco a immaginare nessuno. Ciò renderebbe quasi impossibile lo sviluppo simultaneo di diversi sviluppatori. Renderebbe anche impossibile eseguire test durante lo sviluppo.

Quello che vuoi fare è che tutti si sviluppino sulla propria macchina. Dopo ogni commit al controllo della versione, si dispone del server di Continuous Integration che controlla il codice, esegue test e lo distribuisce al server di test. CI-server e test server potrebbero essere uguali probabilmente. "Ci-Server" potrebbe essere semplice come uno script programmato che esegue il polling del controllo di versione e che esegue le tue attività rake, ma impostando qualcosa come Jenkins è così facile che non mi preoccuperei.

Dipende ...
Nella mia azienda abbiamo sviluppatori, architetti e project manager. Per ogni progetto abbiamo una definizione di Fatto che dice:

• Prima del commit, gli sviluppatori dovrebbero testare le loro modifiche localmente per assicurarsi che tutto funzioni correttamente nelle versioni più recenti di IE, FF, Chrome e Opera.
• Se tutto è a posto, commuta le modifiche su SVN
• Lo script CI distribuirà automaticamente le modifiche al server di prova
• Quando User Story è contrassegnato come risolto, il tester QA (o PM nel nostro caso) verifica l'applicazione a livello User Story
• Se tutto è a posto, PM contrassegna la User Story mentre viene verificato il controllo qualità e il client viene informato
• Il client verifica l'applicazione e, se tutto è a posto, approva le modifiche per consentirne la distribuzione al termine dello sprint

A volte il server di test non è sufficiente, quindi abbiamo anche il server di staging. Il motivo è che non vogliamo interrompere il nostro sviluppo mentre il client sta testando la nostra applicazione.