Come viene organizzata l'integrazione continua nelle grandi aziende?

È, fondamentalmente, un problema di ridimensionamento. Separa il tuo lavoro in moduli, che possono essere diversi progetti e / o diverse funzionalità del tuo prodotto.

Avresti team che coprono set di questi moduli. Ognuno di questi team avrebbe impostato i cicli CI per i propri ambiti e solo dopo il passaggio dei rispettivi cicli, il codice verrebbe inviato ai repository principali, dove verrebbe eseguito il ciclo di configurazione principale.

Molto probabilmente il ciclo CI principale differisce dai cicli CI a livello di squadra in questi aspetti:

• I cicli CI a livello di team non devono creare il codice di tutta l'azienda, solo i moduli di cui sono responsabili ei moduli dipendenti. Se ci sono due moduli completamente indipendenti e in team diversi, non faranno parte del ciclo CI degli altri team.
• I cicli CI a livello di team possono avere test automatizzati molto più dettagliati rispetto al ciclo CI principale. Il ciclo CI principale avrebbe avuto test di verifica della sanità e test di regressione che, a seconda delle dimensioni della soluzione master, sarebbero eseguiti giornalmente o anche settimanalmente, poiché a volte questi test possono richiedere più di 24 ore di esecuzione.

Ciò che devi fare con questo approccio è quello di fornire la spinta automatica dai repository locali al repository centrale una volta che il ciclo locale dell'IC passa, per evitare che gli sviluppatori impieghino enormi quantità di tempo per spingere il codice ai repository centrali.

Oltre a ciò che @Vladimir_Stokic ha detto, su alcuni team (il mio ha circa 150 sviluppatori), lo facciamo più spesso di ogni 24 ore. Ogni volta che si verifica un commit, iniziamo un timer di 5 minuti. Dopo che i 5 minuti sono scaduti, tutti i commit avvenuti durante l'intervallo di 5 minuti vengono combinati e costruiti. Generalmente la build è una build incrementale. Abbiamo un builder separato che esegue test unitari per ogni build che si verifica. Al termine della compilazione, se durante la creazione ci sono stati altri commit (che richiedono tra 1 e 45 minuti a seconda di cosa è cambiato), vengono apportate modifiche in sospeso e così via. Abbiamo anche una build notturna (pulita, completa), ma le build che si verificano su ogni commit (approssimativamente) ci dicono molto rapidamente se qualche test fallisce.