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

Siamo un'organizzazione composta da circa 200 sviluppatori che lavorano continuamente su un singolo prodotto (utilizzando il controllo di revisione Git) che dovrebbe essere rilasciato a una certa data.

A causa dell'enorme numero di sviluppatori, stiamo cercando di creare team "interfunzionali" con circa 10 sviluppatori in ciascun team, ottenendo circa 20 team di sviluppo nell'organizzazione.

Dal momento che vorremmo mantenere uno "standard elevato" continuo (ovvero quando lo sviluppatore fa un pull, il prodotto dovrebbe almeno essere compilabile, ecc.) Del prodotto nel repository principale, vorremmo usare una sorta di gate di qualità.

Non sono sicuro di come formulare la domanda, ma mi chiedo se potrei ottenere qualche consiglio sulle metodologie di sviluppo per un gruppo così vasto di sviluppatori che lavorano su un singolo prodotto.

A nostro avviso, un'estremità dello spettro è quella di consentire a ciascuno sviluppatore di impegnarsi direttamente nel repository principale, tuttavia temiamo che, a causa dell'elevato numero di sviluppatori / commit, il "repository principale" potrebbe essere costantemente in una fase interrotta, a causa non possiamo avere un "cancello di qualità" esigente per ogni commit.

L'altra estremità dello spettro potrebbe essere come (pensiamo che Linus Torvalds / Linux lo faccia) un albero o una struttura piramidale, in cui il "repository principale" ha solo tre fonti pull, queste tre hanno solo una manciata di fonti pull fidate, ecc. Tuttavia, riteniamo che con una struttura del genere i cambiamenti abbiano una lunga catena da scalare per entrare nel "repository principale". Inoltre, se si verifica un conflitto di unione, il problema si verifica su un altro sviluppatore rispetto allo "sviluppatore originale".

Con tutte queste informazioni di base e opinioni dichiarate, come possiamo imparare e leggere le metodologie di sviluppo consigliate per così tanti sviluppatori? In che modo le grandi organizzazioni (Microsoft, Facebook, Ubuntu, ecc.) Strutturano il loro sviluppo?

Dovresti certamente considerare di dividere il prodotto in moduli con i team di interfaccia che riuniscono quei moduli costituenti 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 non puoi farlo, il progetto probabilmente si fermerà a causa di un arresto indotto dalla fusione considerando il numero di sviluppatori che contribuiscono.

Se stai pianificando di utilizzare Git per il controllo della versione, consiglierei di utilizzare un sistema di revisione del codice (come Gerrit ) per migliorare la trasparenza e garantire la qualità per ciascun repository. In questo modo tutto il lavoro dovrebbe essere approvato prima di essere unito in qualsiasi repository autorevole. In questo scenario ha senso concedere a determinate persone fidate le autorizzazioni per passare da un repository in un sistema di revisione del codice a un altro repository (anche possibilmente in un sistema di revisione del codice). Se usato correttamente, questo dovrebbe essere un processo rapido e molto utile che non ostacola il processo di sviluppo.

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

Oltre a questi strumenti di integrazione, è importante cercare un'integrazione frequente come parte della metodologia di sviluppo, per ridurre al minimo i tempi di fusione.

Potrebbe valere la pena considerare un processo di sviluppo Agile come Scrum il cui scopo è quello di suddividere un prodotto complesso in blocchi gestibili di incremento del prodotto (chiamati Sprint). Ciò fornirebbe opportunità di integrazione tra i repository.

Chiaramente, con un team di sviluppo di 200 persone, devi avere una sorta di struttura gerarchica. Un individuo o un piccolo gruppo di persone sta prendendo decisioni sulla progettazione 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 creato corrisponda effettivamente a ciò che desideri 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 processi di controllo della qualità a livello di squadra.

Quindi, sì, dovresti seguire una struttura gerarchica per quanto riguarda il repository. Questo deve corrispondere alla struttura gerarchica del progetto in generale.

I singoli componenti dovrebbero essere costruiti e testati a 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. È necessario disporre di aree separate per ciascun gruppo in cui le persone possono eseguire le modifiche quotidianamente, senza influire sulla struttura principale del progetto.

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

È anche positivo che "se si verifica un conflitto di unione, il problema si ripercuote su un altro sviluppatore" - nello specifico, uno sviluppatore di livello superiore dovrebbe essere quello che decide come risolvere un conflitto.

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

Esistono diversi passaggi che potrebbero aiutarti a mantenere meglio il team e il progetto:

1. dividere la funzionalità in moduli. La funzionalità dovrebbe essere suddivisa in moduli indipendenti al massimo 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 contemporaneamente moduli dipendenti (se il modulo A dipende dal modulo B, B dovrebbe fornire un'interfaccia che A può usare anche quando B non è completamente pronto).

2. avere 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 attività (mai attività per persone). Dopo aver diviso la funzionalità in set più piccoli, creare team per lavorare su questi set. La creazione di squadre sarà più semplice in questa fase, perché sai già su cosa deve lavorare ogni squadra. E attività come la revisione del codice sarebbero svolte all'interno di ogni squadra.

4. chiaro sistema di compiti. Ognuno 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 quanto lavoro resta.

5. controllo della fonte. (Penso che questo sia delineato abbastanza bene in altre risposte)))

E infine, prova a creare una struttura il più semplice possibile di team e moduli. Non puoi permetterti la complessità con un progetto così grande.

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 allo spostamento del codice nella gerarchia e al "mettere tutto insieme". Questo non è molto diverso dai progetti più piccoli con una fase finale in cui non viene fatto altro che test e correzione di errori, solo più frequentemente. Dal momento che stai lavorando in un grande gruppo alla ricerca di standard elevati, la maggior parte di ciò (stato d'animo) probabilmente sarà già in atto.

Oltre alla risposta di hotpotato (che è direttamente sul marchio IMHO), suggerirei anche di implementare alcune porte di controllo del codice sorgente, come suggerisci. Quando abbiamo spostato una grande squadra e una base di codice in git per SCM, abbiamo deciso di utilizzare quello che viene chiamato il metodo "dittatore benevolo", simile al modello che hai descritto.

In questo scenario ci sono molte varie filiali della base di codice completa che vengono regolarmente aggiornate dalla loro filiale di origine, ma la responsabilità di promuovere il codice in aree più visibili / pubbliche spetta a una sola persona (o piccolo gruppo di persone), ed è in genere legato a un processo di revisione del codice. Con una struttura di ramificazione ben organizzata, può funzionare DAVVERO bene. Per ulteriori informazioni, consulta questo link .

Ho lavorato su un enorme sistema su cui diverse centinaia di sviluppatori ci lavoravano contemporaneamente con 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 di usare Maven. Se stai usando VS, potresti anche usare Nuget anche se non sono del tutto sicuro che sia ancora presente con Maven (è anche un po 'diverso). L'uso di un sistema come questo ti consentirà di estrarre le tue dipendenze e di farle funzionare individualmente. Avresti uno script di build che tira le dipendenze rilevanti e costruisce come un batch.

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

Il sistema è stato suddiviso in gruppi . I cluster rappresentavano aree di business e aree di infrastruttura di sistema. Non li nominerò, ma per un'enorme attività di vendita al dettaglio potresti pensare a cose come marketing, operazioni al dettaglio, operazioni online, approvvigionamento, 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 della sicurezza, ad esempio accesso singolo, servizi di directory, controllo, reportistica, ecc. Ogni componente aveva le relative routine memorizzate al suo interno.

Come spazio dei nomi o pacchetto avresti ad esempio Organisation.Security.DirectoryServices. Contenendo tutta la logica nelle aree pertinenti, i team hanno lavorato in modo abbastanza autonomo. Ovviamente si sono verificati grandi progetti che richiedono il contributo di più team, ma sono state operazioni in gran parte fluide.

Spero che questo possa essere d'aiuto.