Al momento sto giocando con l'idea di lanciare DSCM alla direzione della mia azienda. Al momento utilizziamo lo stack TFS verticale completo (SCM, Bug Tracking, Project Management, ecc.), Tuttavia desidero mirare specificamente al controllo del codice sorgente (poiché non ritengo possibile riqualificare il QA con qualcosa come Redmine).
Probabilmente il problema più grande qui è la riqualificazione di una grande quantità di sviluppatori per usare il nuovo SCM (e questo include il treno di pensiero distribuito) - che probabilmente non è affatto fattibile. Deve esserci una qualche forma di migrazione delle competenze con il nuovo sistema: è qui che il GIT fallisce in modo orribile, poiché ci vorranno mesi per prendere piede (e non siamo un piccolo punto vendita - questa è un'azienda molto grande con impegni reali).
Il prossimo problema è il fatto che al momento richiediamo che i check-in siano associati a un bug o un'attività reale (oggetto di lavoro) - dubito che la gestione morderebbe se non potessimo controllarlo. Idealmente le macchine sviluppatrici dovrebbero essere a zero-configurazione, cioè dovrebbe impedire le spinte 'illegali' anche se si è appena installato il client SCM barebone. Essere in grado di aggiornare gli oggetti di lavoro TFS sarebbe anche un grande vantaggio, anche se dovessi scrivere codice personalizzato, ma ancora una volta dovrebbe essere controllato dal repository centrale e non sui computer degli sviluppatori.
So che a lungo termine il DSCM allevia molti dei problemi che affrontiamo quotidianamente, ma non possiamo permetterci il tempo in cui gli sviluppatori hanno problemi di fusione o simili. Ad esempio, il mio primo GIT merge mi ha portato a ben 2 giorni per capire, perché ero così abituato alla mentalità TFS. Questo non è accettabile quando vengono prese in considerazione scadenze reali.
Gli strumenti sono una grande preoccupazione: è incredibilmente facile inserire un file di markup di unione direttamente nel controllo del codice sorgente; il che risulterebbe in un errore di compilazione: TFS non ti permette di fare qualcosa di stupido come questo.
Infine, avere "belle cose" da mostrare probabilmente aiuterebbe il campo. Abbiamo un processo di revisione, mostrando GitHub FI Commenti di commit sarebbe un strong esempio del perché questa roba potrebbe essere migliore - tuttavia, come affermato , GIT è probabilmente la strada sbagliata da percorrere.
TLDR; ho trovato che la maggior parte dei DSCM sono strumenti e non framework (ad esempio, GIT è progettato per essere questo); ti permette di spararti facilmente nel piede - TFS è un framework e questo è qualcosa di prezioso in compagnia.
Qualcuno ha mai affrontato questi tipi di problemi durante la migrazione a DSCM? Quali piattaforme DSCM hai usato? Quali sfide hai affrontato? Avete qualche idea su come questo processo potrebbe essere snellito e quasi reso indolore?