¿Cómo se organiza la integración continua en grandes empresas?

En mi empresa, es común no hacer ninguna compilación intermedia para verificar cómo se fusiona cada rama de característica / corrección de errores en dev. Solo hay una compilación diaria, que siempre provoca muchas fallas de prueba y errores de compilación. Me han dicho que no es razonable construir para cada fusión para más de 1000 desarrolladores.

Así que busqué cómo CI está organizada en empresas que tienen tantos desarrolladores o más (Microsoft, Facebook), y no encontré nada. Tal vez, los expertos pueden decirme entonces?

Es, básicamente, un problema de escala. Separa su trabajo en módulos, que pueden ser diferentes proyectos y / o diferentes funcionalidades de su producto.

Tendría equipos que cubren conjuntos de esos módulos. Cada uno de esos equipos tendría ciclos CI configurados para sus alcances, y solo después de que sus respectivos ciclos pasaran, el código sería empujado a repositorios maestros, donde se ejecutaría el ciclo maestro CI.

El ciclo maestro de CI probablemente diferirá de los ciclos de CI de nivel de equipo en estos aspectos:

• Los ciclos de CI a nivel de equipo no tienen que construir el código de toda la compañía, solo aquellos módulos de los que son responsables y los módulos dependientes. Si hay dos módulos que son completamente independientes y en equipos diferentes, no serían parte del ciclo de CI del otro equipo.
• Los ciclos de CI a nivel de equipo pueden tener pruebas automatizadas mucho más detalladas que el ciclo de CI maestro. El ciclo Master CI tendría pruebas de verificación de cordura y pruebas de regresión que, dependiendo del tamaño de la solución maestra, se ejecutarían diariamente o incluso semanalmente, ya que estas pruebas a veces pueden tardar más de 24 horas en ejecutarse.

Lo que debe hacer con este enfoque es proporcionar un impulso automatizado desde los repositorios locales al repositorio central una vez que pase el ciclo de CI local, para que sus desarrolladores no gasten enormes cantidades de tiempo para empujar el código a los repositorios centrales.

Además de lo que dijo @Vladimir_Stokic, en algunos equipos (el mío tiene ~ 150 desarrolladores), hacemos compilaciones con más frecuencia que cada 24 horas. Cada vez que ocurre una confirmación, comenzamos un temporizador de 5 minutos. Una vez transcurridos los 5 minutos, se combinan y se crean todas las confirmaciones que ocurrieron durante el intervalo de 5 minutos. La construcción suele ser una construcción incremental. Tenemos un generador separado que ejecuta pruebas unitarias para cada compilación que ocurre. Una vez finalizada la compilación, si hubo más confirmaciones durante la compilación (que demora entre 1 y 45 minutos, dependiendo de lo que haya cambiado), se generarán los cambios pendientes, y así sucesivamente. También tenemos una compilación nocturna (limpia, completa), pero las compilaciones que ocurren en cada confirmación (aproximadamente) nos dicen muy rápidamente si alguna prueba falla.