Formerò un team remoto , e voglio essere in grado di usare degli script (o qualcosa del genere) per rendere sicuro che il codice delle persone sia controllato ogni notte. Attualmente uso alcuni script BASH che sono kindky e non sono facilmente personalizzabili.
Qualcuno ha strumenti, suggerimenti o risorse utili per questo?
Ci sono delle insidie nel fare ciò che non vedo, o posso farlo meglio in un altro modo?
Perché vuoi essere sicuro che il codice di tutti venga verificato durante la notte?
Non vuoi che la tua build fallisca e avere per controllare il codice implica che uno dovrà impegnarsi con un codice che non necessariamente avrà ragione.
Questo porta a domande più ampie su quali strumenti di controllo della versione stai utilizzando e la tua "filosofia" generale per il controllo della versione.
Sicuramente vuoi assicurarti che i tuoi sviluppatori funzionino, e quasi certamente vorrai che comincino a fare modifiche presto e spesso, ma ugualmente vuoi, no, hai bisogno di un server di build e quindi vuoi impegnarti codice da compilare (e superare i test).
Gran parte della risposta potrebbe provenire dall'utilizzo di un VCS distribuito (o dal teaming DVCS locale con un sistema basato su server centrale) in quanto è possibile richiedere commit "locali" (inviati a un mirror per il backup), quindi è necessario maggiori dettagli o più domande ...
Perché vuoi forzare le persone a controllare il codice? Non mi sembra una buona idea; se lo sviluppatore non è pronto a commettere modifiche, probabilmente c'è una buona ragione.
Qual è il vantaggio che si ottiene dall'essere costretti a controllare ogni giorno?
Ho cose per metà costruite che non vorrei augurare a nessuno.
Si presume che ogni luogo in cui ho lavorato il codice archiviato funzioni o abbia superato test e compilazioni correttamente ecc.
Avrei impostato un server di integrazione continuo, hudson , in combinazione con subversion o cvs.
(il backup dovrebbe essere diverso dal check-in, imho)
Non esiste un vero motivo per non utilizzare il controllo di revisione come forma di backup, purché si disponga di un piano di backup per il proprio repository.
Se desideri educare i tuoi sviluppatori e amministrare il sistema di controllo di revisione che preferisci, puoi utilizzare tag e / o rami per gestire il problema del codice non funzionante.
In effetti, penso che il tagging (o la ramificazione) del codice di rilascio, beta e alfa sia il modo migliore per andare. In questo modo richiede una decisione attiva per rovinare il prodotto rilasciato invece di un momento "oh merda" da parte di uno sviluppatore.
Leggi altre domande sui tag version-control team scripting