Addestrare un'azienda per utilizzare un DVCS proveniente da una mentalità CVCS è così difficile come si potrebbe pensare?

Lavoro come consulente Mercurial e ho scoperto che non è troppo difficile spiegare DVCS ai nuovi utenti, a condizione che tu non confonderli Quindi quello che faccio è:

• Enfatizza i principi fondamentali. Il modello di cronologia in Mercurial è in realtà molto semplice e pulito. In particolare, trovo che i rami sono modellati meglio in Mercurial che in, ad esempio, Subversion. Parlate con gli utenti di come lavorare insieme dovrebbe funzionare in un mondo ideale: faccio un po 'di lavoro sulla mia macchina, fate un po' di lavoro sulla vostra macchina e successivamente riconciliamo (fondiamo) il nostro lavoro. Quindi mostra loro come Mercurial implementa esattamente questo modello.

• Enfatizza il flusso di lavoro centralizzato. Molte guide e tutorial mettono molta enfasi sull'aspetto distribuito di DVCS - la mia esperienza è che questo non è molto importante! Soprattutto non in un'organizzazione in cui si utilizza già un VCS centralizzato di grandi dimensioni. La parte importante sono i nuovi e migliorati flussi di lavoro.

• Enfatizza i casi di utilizzo semplice. Consenti agli utenti di sperimentare direttamente giocando con lo strumento. Prima si impegnano e spingono / tirano con un server centrale. In seguito puoi guidarli attraverso uno scenario più strutturato in cui creano un ramo di funzionalità, esegui alcune commit e uniscilo indietro.

Abbiamo creato materiale di formazione che chiamiamo Mercurial Kick-Start . L'ho usato più volte e normalmente ha abbastanza contenuti per due o tre giorni, a seconda di quanto parlo.

La cosa più importante è avere un'idea chiara di quale sarà il flusso di lavoro standard: come userete i rami e cosa verrà spinto nel repository centrale.

Un DVCS può essere utilizzato in molti modi, da un modello centralizzato a chiunque lavori su un singolo ramo per condividere le modifiche tra gli sviluppatori senza avere un server centrale. La documentazione di comando riflette questo, quindi è abbastanza confuso per i nuovi utenti.

Se hai un chiaro flusso di lavoro progettato puoi dare agli utenti un elenco di attività comuni invece di un elenco di comandi, e può essere semplice come quello a cui sono abituati nonostante sia completamente diverso.

Se hai a che fare con persone che sono veramente resistenti al cambiamento, puoi usare git-tfs o simili - in questo modo non hai bisogno di addestrare nessuno che non abbia visto quanto DVCS funzioni meglio per un progetto specifico.

Un elemento che considero è quello di esaminare i problemi di "stesso nome, funzionalità diverse". Uno di questi che ho sperimentato con un paradigma git (dvcs) -svn (cvs) è che la ramificazione è diversa. In svn si tende a ramificarsi di più, questo flusso di lavoro riflette in parte il fatto che non è possibile "commettere localmente". Quando svn gente si muove per git, ha bisogno di imparare quali rami significano in termini di flusso di lavoro in git e come sono spesso usati quando i collaboratori sono persone. Questo ha fatto inciampare più di una persona.