Metodologie di sviluppo quando centinaia di sviluppatori stanno lavorando su un'unica soluzione?

Dovresti certamente considerare suddividere il prodotto in moduli con i team di interfaccia che portano questi moduli costitutivi in un prodotto. Ciò a sua volta significherebbe suddividere i repository in modo che corrispondano al partizionamento e alla gerarchia dei moduli. Se sembra che tu non possa farlo, il progetto probabilmente si risolverà in un arresto indotto dall'unione considerando il numero di sviluppatori che contribuiscono.

Se hai intenzione di utilizzare Git per il controllo della versione, ti consigliamo di utilizzare un sistema di revisione del codice (come Gerrit ) per migliorare la trasparenza e garantire la qualità per ogni repository. In questo modo tutto il lavoro dovrebbe essere approvato prima di essere fuso in un qualsiasi repository autorevole. In questo scenario ha senso concedere ad alcune persone fidate le autorizzazioni per passare da un repository sotto un sistema di revisione del codice ad un altro repository (eventualmente anche con un sistema di revisione del codice). Se usato correttamente, questo dovrebbe essere un processo rapido e molto vantaggioso che non ostacoli il processo di sviluppo.

Per quanto riguarda la verifica della build, è necessario un server continuous integration (CI) il cui scopo è creare e verificare automaticamente il codice. Per codice di verifica intendo che il codice viene compilato correttamente e superato il test. Infatti Jenkins (Server CI) può essere collegato a Gerrit sistema di revisione del codice come parte della Gerrit fase di verifica, automatizzando completamente il processo.

Oltre a questi strumenti di integrazione è importante impegnarsi per un'integrazione frequente come parte della metodologia di sviluppo, per ridurre al minimo la fusione temporale.

Può valere la pena considerare un processo di sviluppo Agile come Scrum di chi scopo è quello di rompere un prodotto complesso in pezzi gestibili di incremento del prodotto (chiamato Sprint). Questi fornirebbero opportunità di integrazione tra i repository.

Chiaramente, con un team di sviluppo di 200 persone, è necessario disporre di una sorta di struttura gerarchica. Un individuo o un piccolo gruppo di persone prende decisioni sul design del prodotto software. Il tuo processo di sviluppo dovrebbe riflettere questo: hai bisogno di revisioni del codice e test in atto per assicurarti che il software che stai creando corrisponda effettivamente a quello che volevi creare (oltre che per scopi di qualità).

Anche i piccoli team hanno bisogno di leader per guidare i team e rivedere il loro lavoro mentre sviluppano i singoli componenti. Dovrebbero essere anche i processi di controllo della qualità a livello di squadra.

Quindi, sì, dovresti seguire una struttura gerarchica riguardo al repository. Questo è per abbinare la struttura gerarchica del progetto in generale.

I singoli componenti dovrebbero essere costruiti e testati ad un certo livello di adeguatezza prima ancora di pensare a metterli tutti insieme. Consentire a 200 persone di impegnarsi direttamente nel progetto principale sarebbe il caos. Dovresti avere aree separate per ogni gruppo in cui gli individui possono effettuare le modifiche quotidianamente, senza influire sulla build principale del progetto.

È molto positivo se "i cambiamenti hanno una lunga catena da scalare per entrare nel deposito principale" perché questa catena ti consente di garantire la qualità. Potrebbe sembrare più veloce se tutte le modifiche si applicano immediatamente al repository principale, ma in realtà questo sarà solo un enorme mal di testa, dato che avrai una build principale costantemente buggata e inutilizzabile del tuo software.

È anche una buona cosa che "se si verifica un conflitto di fusione, il problema arriva su un altro sviluppatore" - in particolare, uno sviluppatore di livello superiore dovrebbe essere quello che decide come risolvere un conflitto.

Quando hai qualcosa di grande e (di conseguenza) ingestibile, la via d'uscita la divide in pezzi più piccoli e gestibili.

Ci sono diversi passaggi che ti aiuteranno a mantenere meglio il team e il progetto:

1. divide la funzionalità in moduli. La funzionalità dovrebbe essere divisa in moduli massimamente indipendenti utilizzando i principi di alta coesione, basso accoppiamento e inversione di dipendenza. Il primo principio ti aiuterà a creare moduli logicamente coerenti. Il secondo aiuterà a mantenere questi moduli il più indipendenti possibile. Il terzo aiuterà a sviluppare moduli dipendenti simultaneamente (se il modulo A dipende dal modulo B, B dovrebbe fornire un'interfaccia che A possa usare anche quando B non è completamente pronto).

2. hanno una documentazione chiara. Quando ci sono così tante persone che lavorano insieme, le cose possono essere facilmente dimenticate o incomprese. Quindi è necessario prestare particolare attenzione a tutta la documentazione dai requisiti alle soluzioni architettoniche.

3. persone per le attività (mai attività per le persone). Dopo aver diviso la funzionalità in insiemi più piccoli, creare team per lavorare su questi set. Creare squadre sarà più facile in questa fase, perché sai già su cosa ogni squadra deve lavorare. E compiti come la revisione del codice dovrebbero essere fatti all'interno di ogni squadra.

4. sistema di compiti chiaro. Ciascuno dei 200 sviluppatori dovrebbe sapere chiaramente su cosa lavorare. Questo ti aiuterà a tenere traccia di ciò che è già stato fatto, su cosa sta lavorando ogni persona e su quanto lavoro è rimasto.

5. controllo del codice sorgente. (Penso che questo sia delineato in altre risposte abbastanza bene)))

Infine, cerca di creare una struttura il più semplice possibile di team e moduli. Non puoi permetterti la complessità con un progetto così enorme.

Oltre alle altre risposte che suggeriscono una struttura gerarchica: ciò implica che dovrai pianificare i punti di "integrazione" nel tempo in cui l'attenzione è interamente rivolta a spostare il codice nella gerarchia e "mettere tutto insieme". Questo non è molto diverso dai progetti più piccoli con una fase finale in cui non viene svolto altro lavoro che test e bug fixing, solo più frequentemente. Dal momento che lavori in un gruppo numeroso cercando di raggiungere standard elevati, la maggior parte di questo (stato d'animo) sarà probabilmente già in atto.

Oltre alla risposta di hotpotato (che è direttamente sul marchio IMHO), suggerirei anche l'implementazione di alcuni gate di controllo del codice sorgente, come suggerito. Quando abbiamo spostato una grande squadra e una base di codice da git per SCM, abbiamo deciso di utilizzare il cosiddetto metodo "dittatore benevolo", simile al modello che hai descritto.

In questo scenario ci sono molti rami del codice completo che vengono regolarmente aggiornati dal loro ramo sorgente, ma la responsabilità per la promozione del codice in aree più visibili / pubbliche si trova con una singola persona (o un piccolo gruppo di persone), ed è tipicamente legato a un processo di revisione del codice. Con una struttura ramificata ben organizzata, questo può funzionare VERAMENTE bene. Per ulteriori informazioni, consulta questo link .

Ho lavorato su un enorme sistema che aveva diverse centinaia di sviluppatori che lavoravano contemporaneamente a circa 150 milioni di SLOC. Questo era su un mainframe, quindi non stiamo parlando di Visual Studio, ma i principi possono ancora essere adottati.

Prima di tutto, se stai usando Java, direi sicuramente Maven. Se stai usando VS, potresti anche usare Nuget anche se non sono abbastanza sicuro se ci sia o meno ancora con Maven (è anche un po 'diverso). L'utilizzo di un sistema come questo ti consentirà di estrarre le tue dipendenze e consentire loro di funzionare individualmente. Avresti uno script di compilazione che estrae le dipendenze pertinenti e lo compili come un batch.

Dato che non stai facendo direttamente una domanda ma stai chiedendo una metodologia, ti dirò come l'ha gestita il mio precedente datore di lavoro.

Il sistema è stato suddiviso in cluster . I cluster hanno rappresentato aree di business e aree di infrastruttura di sistema. Non ho intenzione di nominarli, ma per una grande attività di vendita al dettaglio si potrebbe pensare a cose come marketing, operazioni al dettaglio, operazioni online, acquisti, distribuzione. L'infrastruttura di sistema rappresentava cose come clienti e sicurezza. All'interno di ciascun cluster, c'erano componenti . Utilizzando l'analogia precedente, è possibile prendere in considerazione componenti di sicurezza, ad esempio: single sign on, servizi di directory, controllo, reporting, ecc. Ogni componente ha le relative routine memorizzate al suo interno.

Come spazio dei nomi o pacchetto potresti avere Organisation.Security.DirectoryServices, ad esempio. Contenendo tutte le logiche nelle aree pertinenti, le squadre hanno lavorato in modo abbastanza autonomo. Ovviamente sono stati realizzati progetti di grandi dimensioni che richiedevano l'input da più team, ma erano operazioni in gran parte semplici.

Spero che questo aiuti.