Come è organizzata l'integrazione continua nelle grandi aziende?

Nella mia azienda, è comune non fare alcun build intermedio per verificare come ogni ramo feature / bugfix viene unito in dev. Esiste solo build giornaliera, che provoca sempre molti test falliti e errori di compilazione. Mi è stato detto che è irragionevole fare build per ogni unione per oltre 1000 sviluppatori.

Così ho cercato come è organizzata la CI in aziende che hanno così tanti sviluppatori o più (Microsoft, Facebook) e non ho trovato nulla. Forse, gli addetti ai lavori possono dirmi allora?

development-process continuous-integration large-scale-project

— Megamozg
fonte

vedi Perché non siamo supporto clienti per [la tua azienda preferita]

— moscerino

@gnat Sei adeguato? Come è correlato? Ho chiesto un'esperienza privilegiata e ho indicato aziende ad esempio. Non ho chiesto assistenza clienti.

— Megamozg,

@gnat Non vedo come sia correlato a quello. Megamozg: CI è organizzato per modulo di progetti, non esiste un modulo con 1000 sviluppatori. Quindi, se ci sono troppe persone, riduci il tuo progetto / modulo in una parte più piccola.

— Walfrat,

@Walfrat è totalmente correlato. Questo sito non è destinato a effettuare sondaggi / sondaggi di esperti di grandi aziende su come le loro aziende fanno varie cose. Se uno è curioso di cose del genere, dovrebbe usare i canali di supporto di queste compagnie

— moscerino

@gnat Non vedo davvero come si è applicato il link che hai fornito, specialmente con il commento che hai fornito in risposta a Walfrat. Sulla base di quel commento, questo IMHO sarebbe il collegamento corretto (la parte relativa alle domande sul tipo di sondaggio) softwareengineering.meta.stackexchange.com/a/6490

— Newtopian,

Risposte:

Fondamentalmente è un problema di ridimensionamento. Separate il vostro lavoro in moduli, che possono essere diversi progetti e / o diverse funzionalità del vostro prodotto.

Avresti squadre che coprono set di quei moduli. Ognuno di quei team avrebbe impostato i cicli CI per i loro ambiti, e solo dopo che i loro rispettivi cicli sarebbero passati, il codice sarebbe stato inviato ai repository master, dove sarebbe stato eseguito il ciclo CI principale.

Il ciclo CI principale differirà molto probabilmente dai cicli CI a livello di team in questi aspetti:

I cicli CI a livello di team non devono costruire il codice dell'intera azienda, ma solo i moduli di cui sono responsabili e i moduli dipendenti. Se ci sono due moduli che sono completamente indipendenti e in team diversi, non farebbero parte del ciclo CI dell'altro team.
I cicli CI a livello di team possono avere test automatici molto più dettagliati rispetto al ciclo CI principale. Il ciclo CI principale prevede test di controllo di integrità e test di regressione che, a seconda delle dimensioni della soluzione master, verrebbero eseguiti giornalmente o anche settimanalmente, poiché a volte l'esecuzione di questi test può richiedere più di 24 ore.

Quello che devi fare con questo approccio è fornire push automatizzati dai repository locali ai repository centrali una volta che il ciclo CI locale passa, affinché gli sviluppatori non impieghino enormi quantità di tempo per inviare il codice ai repository centrali.

— Vladimir Stokic
fonte

Oltre a quanto affermato da @Vladimir_Stokic, su alcuni team (il mio ha ~ 150 sviluppatori), costruiamo più frequentemente di ogni 24 ore. Ogni volta che si verifica un commit, si avvia un timer di 5 minuti. Al termine dei 5 minuti, tutti i commit eseguiti durante l'intervallo di 5 minuti vengono combinati e creati. La build è in genere una build incrementale. Abbiamo un costruttore separato che esegue unit test per ogni build che si verifica. Al termine della compilazione, se durante la compilazione sono stati eseguiti altri commit (che richiedono tra 1 e 45 minuti a seconda della modifica), vengono create le eventuali modifiche in sospeso e così via. Abbiamo anche una build notturna (pulita, completa), ma le build che si verificano ad ogni commit (approssimativamente) ci dicono molto rapidamente se i test falliscono.

— user1118321
fonte