Esistono strumenti eccellenti per consentire la collaborazione di team di piccole o grandi dimensioni, quali strumenti si scelgono dipendono dalle dimensioni del team, dalle dimensioni del progetto, ...
Un obiettivo è avere comunicazione costante con il tuo team. Per questo consiglio:
-
Rimani connesso, usa IRC (e registralo)! Usa skype / video / gmail o qualsiasi altra cosa per la comunicazione 1 a 1, ma per i team IRC consente un tipo di comunicazione che gli altri in qualche modo non soddisfano. Dovresti essere comunque su IRC se sei uno sviluppatore e puoi integrare altri strumenti per inviare notifiche al tuo canale (commit, test)
-
Utilizza un sistema di tracciamento dei bug, tra cui scegliere.
-
Utilizzare qualsiasi tipo di sistema di gestione dei progetti, strumenti come redmine, agilezen.com o un foglio Excel. fai la tua scelta.
Un altro obiettivo è che tutti gli sviluppatori abbiano lo stesso ambiente di sviluppo e tipo di dati , in modo riproducibile e automatico. Per questo è possibile una combinazione di strumenti:
- vagabondo + provisioner (provy, chef, burattino) + tessuto
- usa dispositivi fissi, app di dati fittizie, generatori di dispositivi casuali per i tuoi dati e simula servizi di terze parti in modo da poterli riprodurre e dipendere.
L'uso programmato delle macchine virtuali consente anche di sviluppare molto da vicino l'ambiente di distribuzione, senza che tutti i membri del team debbano installarli e configurarli localmente, senza perdere la flessibilità e senza i grattacapi che la condivisione delle risorse può apportare (specialmente se la squadra è geograficamente a parte).
Un altro obiettivo è che i membri del team non si calpestino a vicenda . Non solo non infrange il codice dei tuoi colleghi, ma include anche evitare sforzi duplicati. Alcune cose che puoi usare:
-
usa un DVCS con un server centralizzato (ad es. bitbucket) con un flusso di lavoro di commit coerente che include anche la distribuzione. "Ad esempio, git-flow come i flussi di lavoro o distribuisci sempre i flussi di lavoro"
-
configura un server di Continuos Integration (jenkins o teamcity i.e.) e scrivi test come pazzi. Tieni traccia della copertura del tuo codice e ti impegni a mantenere il tuo codice con la massima copertura possibile. Utilizza le unittests, ma usa anche il test del browser, ad esempio il selenio (mi piace usare il selenio per test di tipo generale più generale, e unittests per operazioni a basso livello, e il selenio ti permette di testare le interazioni del backend e del codice di frontend)
-
contratto di commit: chiedi al tuo team di utilizzare le filiali per lo sviluppo e invia il codice al ramo principale quando passano tutti i test.
-
automatizza la tua implementazione, configura un server di staging (che può / dovrebbe essere fornito con gli stessi script della tua casella vagrant) e collega il tuo server CI per distribuirlo almeno una volta al giorno quando tutti i test sono verdi dal ramo principale. Dopo la distribuzione automatizzata, esegui test sul server, inclusi i test di carico, (ad esempio con funkload, o selenio, ecc.) E esegui il grafo utilizzando la grafite!
-
Usa un sistema di bugtracking. È una perdita di tempo se due membri del tuo team stanno rintracciando lo stesso bug e stanno cercando di risolverlo allo stesso tempo senza saperlo.
Non è necessario impostare tutto dall'inizio e potrebbe non essere necessario utilizzare tutti gli strumenti. Tieni d'occhio quei momenti in cui inizi a averne bisogno.