Come vengono utilizzati i DVCS in team di grandi dimensioni?

Question

Recentemente ho iniziato a entrare in Git su un progetto personale, e posso vedere come un DVCS potrebbe avvantaggiarci al lavoro (che è una grande azienda di software aziendale, attualmente in esecuzione Perforce). Il lavoro di feature nel mio team, ad esempio, consiste principalmente in sviluppatori che creano i propri rami; a volte questi sono condivisi tra piccoli team di sviluppatori. Penso che sarebbe più efficiente in questo caso utilizzare un DVCS.

Nel caso più generale, però, sarei interessato a sentire da persone che utilizzano un DVCS al lavoro, in team di medie o grandi dimensioni.

1. Come si gestiscono le unioni N-way? Questo è anche uno scenario comune? Mercurial supporta solo le unioni N-way facendo (N-1) le unioni a 2 vie (e read che questa è la soluzione preferita in altri DVCS), che suona come un processo molto laborioso anche per relativamente piccolo N.
2. utilizzare un singolo repository autorevole centrale o è veramente P2P?
3. Gli sviluppatori spesso spingono e trascinano il codice l'uno dall'altro, oppure tutto viene gestito tramite il repository centrale?

Answer 1

La mia squadra presso il mio precedente datore di lavoro ha utilizzato Git e ha funzionato bene per noi. Noi non erano tutto ciò che di grandi dimensioni (forse 16 o giù di lì, con forse 8 committer realmente attivi?), Ma non ho risposte alle tue domande: unioni

1. N-Way non sono terribilmente comune. Abbiamo elaborato alcune convenzioni sulla denominazione delle filiali che ci hanno consentito di scrivere script che facilitavano il processo di "release engineering" (uso citazioni di paura perché non avevamo un tecnico di rilascio) e le persone creavano rami di funzionalità private, ma raramente ha avuto un problema con la fusione di più di due rami (vedi il prossimo).
2. (e # 3).Abbiamo avuto un repository centrale su un server di sviluppo per tre motivi: (a) La macchina di sviluppo aveva un backup RAID5 (più tollerante ai guasti) e notturni (le workstation di sviluppo non erano notturne), (b) le versioni di produzione erano state create sul server di sviluppo, e (c) avere uno script semplificato di repository centrale. Di conseguenza, la fusione N-way semplicemente non è mai avvenuta. La cosa più simile a N-way era quando qualcuno si fondeva lateralmente e si univa verticalmente.

Git per noi è stata una grande opportunità per il suo alto grado di flessibilità; tuttavia, abbiamo dovuto stabilire alcune convenzioni (nomi di branch e tag, posizioni dei repository, script, ecc.) o potrebbe essere stato un po 'caotico. Una volta che abbiamo stabilito le convenzioni, la flessibilità che avevamo era semplicemente fantastica.

Aggiornamento: le nostre convenzioni in fondo erano dunque:

• una directory sul nostro server NFS che ospitava tutti i repository centrali
• abbiamo avuto diversi progetti che i componenti condivisi, così li abbiamo scoppiata in librerie, in sostanza, con i propri repository, ei progetti deliverable li hanno appena inclusi come sottomoduli git.
• c'erano stringhe di versione e rilasciare nomi imposti su di noi dall'alto, quindi abbiamo usato un varianti di essi, come nomi di filiali
• allo stesso modo, per i tag, hanno seguito i nomi di rilascio al processo dettata
• progetti consegnabili contenuti un file di proprietà che ho letto negli script della shell, e che mi ha permesso di scrivere un singolo script per gestire il processo di rilascio per tutti i progetti, anche se ognuno aveva delle leggere variazioni sul processo - le variazioni erano spiegate in quei file di proprietà
• Ho scritto script per ricostruire un pacchetto disponibile da qualsiasi tag
• utilizzando git al ci ha spinto a controllare l'accesso usando PAM e/o le normali autorizzazioni utente (ssh, ecc.)
• C'erano altre convenzioni che sono più difficili da inserire in un elenco puntato, come quando devono avvenire le unioni. Davvero, io e un altro ragazzo eravamo dei "guru guru" interni, e abbiamo aiutato tutti a capire come usare i rami e quando unire.
• convincere le persone a impegnarsi in piccoli pezzi e non far cadere le bombe a diff nel ramo principale era una sfida. Un tizio ha abbandonato circa due settimane di lavoro in un unico impegno, e alla fine abbiamo dovuto sbrogliare tutto. A enorme sprecare tempo e frustrante per tutti.
• commenti informativi e dettagliati per andare con impegna

C'erano altre cose che si impara come la tua squadra ottiene con esperienza e impara a lavorare con l'altro, ma questo era sufficiente per noi iniziato.

Aggiornamento: chi segue queste cose ormai già lo sa, ma Vincent Dreissen ha scritto un solido e abbastanza completa (ma non esaustivo) take on branching and release engineering using Git. Altamente incoraggiare usando il suo processo come punto di partenza, perché per due motivi:

• un sacco di squadre di farlo in questo modo o stanno utilizzando alcuni variante simile (compreso Linux, Git, e molti altri team di progetto OSS), che significa che questo metodo è stato testato e ottimizzato per avere successo nella maggior parte delle circostanze. È molto improbabile che affronti un problema che non è stato affrontato e risolto nei limiti di questo modello.
• a causa di quanto sopra, quasi tutti gli ingegneri con esperienza Git capiranno cosa sta succedendo. Non dovrai scrivere una documentazione dettagliata sulla natura fondamentale della tua procedura di rilascio; dovrai solo documentare cose specifiche solo per il tuo progetto o team.

Answer 2

Ecco un esempio (da non significa un "universale")

Abbiamo VCS centrali (ClearCase o di eversione, a seconda dei diversi progetti), e li stiamo usando per gli sviluppi "ufficiali" sforzi (dev, patch, correzioni), in cui il numero di rami è limitato e ben identificato.

Tuttavia, per gli sviluppi di refactoring che coinvolgono un sacco di stato intermedio, dove non funziona nulla, e dove molti sviluppatori ha bisogno di avere il proprio ramo di attività di base o rami, alcuni repository Git sono istituiti tra gli sviluppatori, in un Modo P2P.
Una volta che il lavoro raggiunge una sorta di stabilità a 0,1 e le fusioni vengono ridotte, viene reimportato nel VCS, dove il lavoro può continuare in modo "ordinato" centralmente.

Dal Git on Windows works well (MSysGit), riusciamo a fare rapidamente piccoli sviluppi iniziali sul lato in questo modo.

Stiamo ancora valutando Git per uno sviluppo di progetti su vasta scala.

Answer 3

Probabilmente è meglio esaminare come funzionano gli sviluppatori del kernel linux. Hanno un flusso di lavoro piuttosto complesso in cui le modifiche vengono inviate da molte fonti, quindi gli sviluppatori fidati per ciascun sottosistema (chiamati tenenti) inseriscono le modifiche e, quando sono felici, le inoltrano a Linus, che alla fine le trascina nel suo albero o li rifiuta. Ovviamente è più complesso di così, ma questa è una panoramica generale.

Answer 4

Ho lavorato per diversi anni con il team Glasgow Haskell Compiler utilizzando Darcs. Ho recentemente (diversi mesi) iniziato a utilizzare git per la mia copia del repository, sia per le prestazioni che per migliorare la mia formazione.

1. Come si gestiscono le unioni N-way?

   Non ci sono unioni N-way. Ogni sviluppatore genera un flusso di patch e gli stream vengono uniti uno alla volta in ciascun repository. Quindi, se gli sviluppatori N apportano modifiche simultaneamente, vengono uniti a coppie.

2. Si utilizza un singolo repository centrale autorevole?

   Assolutamente. È l'unico modo per dire cos'è il GHC e cosa no.

3. Gli sviluppatori spesso spingono e trascinano il codice da e verso l'altro, oppure fa tutto tramite il repository centrale?

   Penso che dipenda dagli sviluppatori e dal VCS che si sta utilizzando. Nel progetto GHC quasi tutti i pull e push che vedo passano attraverso il repository centrale. Ma c'è un portiere pesante (autogestito) su push al repository centrale, e se un collega ha una correzione di bug ho bisogno di ora, lo prendo direttamente dal suo repository. Con i Darcs è molto facile tirare solo una singola patch (piuttosto che l'intero stato come in git), e so che i miei amici sviluppatori, che hanno più esperienza con le freccette, usano questa caratteristica molto più di me --- e a loro piace molto.

   Con git, quando sto lavorando a stretto contatto con un altro sviluppatore, creerò spesso una nuova filiale solo allo scopo di condividerla con un'altra persona. Quel ramo non colpirà mai il repository centrale.

Answer 5

Il abbastanza famoso "Tech Talk: Linus Torvalds su git", spiega come viene utilizzato per Linux (circa grande come squadra come mi viene in mente)

Se ricordo bene, il suo uso è stato paragonato a una catena di comando militare - ogni modulo ha un manutentore, che gestisce le richieste di pull dagli sviluppatori, poi ci sono alcune persone "più fidate" che si occupano di estrarre i dati dai manutentori del modulo nel repository git ufficiale di kernel.org.

"Linux: Managing the Kernel Source With 'git'" spiega anche che, anche se ancora una volta non è certo una spiegazione concisa .. schema

Answer 6

Work-flow da whygitisbetterthanx:

alt git work-flow with integration manager http://whygitisbetterthanx.com/images/workflow-b.png

Per scalare questo fino a ancora di più gli sviluppatori, è sufficiente aggiungere un altro strato di "fidati luogotenenti" tra il gestore dell'integrazione e gli sviluppatori.