¿Cómo es posible construir toda la base de código desde la fuente a escala de Google?


8

La primera respuesta a una pregunta antigua, recientemente activa , vinculada a un video que habla sobre cómo se realiza el repositorio de Google.

Una cosa interesante que se mencionó es el hecho de que todo está construido desde la fuente, sin depender de binarios. Esto ayuda a evitar problemas con las dependencias que se vuelven obsoletas pero que todavía se usan en otros proyectos, un problema que realmente encontré mucho.

¿Cómo es técnicamente posible? Si intento lo mismo en mi empresa, incluso teniendo en cuenta la gran brecha entre la escala de la base de código de mi empresa y la escala de Google, no sería posible por dos razones:

  • El IDE (Visual Studio) dejará de responder rápidamente, dado que sufre mucho incluso con soluciones pequeñas que contienen, por ejemplo, 50 proyectos.

  • Cualquier análisis estático se vería reducido por el tamaño de toda la base de código. Por ejemplo, las métricas de código o la comprobación estática de contratos de código difícilmente serían posibles (los contratos de código probablemente tomarían días o semanas).

  • Con la integración continua, la compilación también llevaría una gran cantidad de tiempo y destruiría los servidores tan pronto como se modificara un proyecto con muchas dependencias, lo que requeriría la recompilación de un gran árbol de proyectos.

¿Cómo puede una pequeña empresa sortear esos problemas y ser capaz de:

  1. Use el IDE sin verse afectado por el bajo rendimiento,

  2. ¿Compilar el código después de cada confirmación sin destruir el servidor, incluso cuando las consecuencias de un cambio requieren que se vuelva a compilar una gran cantidad de la base de código?


Hay una charla en Youtube sobre cómo lo hace Google: youtube.com/watch?v=2qv3fcXW1mg
Patrick

Respuestas:


11

Está asumiendo un proceso de compilación tradicional, y el proceso de Google es cualquier cosa menos tradicional. Hay una serie de artículos en el blog de Herramientas de ingeniería que explican su proceso con cierto detalle, elaborando sobre la presentación de 2010: Herramientas para la integración continua a escala de Google :

  1. Construir en la nube: acceder al código fuente
  2. Build in the Cloud: cómo funciona el sistema Build
  3. Construir en la nube: distribuir pasos de compilación
  4. Construir en la nube: acceder al código fuente
  5. Pruebas a la velocidad y escala de Google

Para resumir, utilizan un sistema de construcción distribuido personalizado que permite un alto grado de paralelismo y automatización, aprovechando al máximo su infraestructura existente. También depende en gran medida del almacenamiento en caché, con una tasa de aciertos de caché general del 90%.

Pero, ¿cómo puede aplicar todo esto en su empresa? El primer paso es distribuir la compilación, y para eso necesitarías:

  • Una nube
  • Un compilador distribuido
  • Un caché del compilador.

En un entorno de desarrollo de gcc, configurar una granja de compilación es relativamente fácil. distcc se encarga de la distribución y ccache se encarga del almacenamiento en caché, y funcionan muy bien juntos. No conozco ninguna herramienta similar para el ecosistema de Microsoft (supongo que está utilizando un lenguaje de Microsoft basado en su elección de IDE), pero sí sé que MSBuild puede ejecutar compilaciones en paralelo , aprovechando las CPU de varios núcleos . No es realmente una granja de compilación, pero ciertamente es un paso en la dirección correcta.


2
  1. No tiene que construir todos los 2000 proyectos para usar solo los que necesita.
  2. El lenguaje Go fue diseñado específicamente para aliviar este problema haciendo que los tiempos de compilación sean muy rápidos. Fue una de las razones por las que inventaron el lenguaje.

Dicho esto, desconfiaría de la "construcción justo a tiempo", a menos que el código que se está implementando en toda la empresa se haya verificado como parte de un ciclo de lanzamiento formal (más o menos), y no sea solo un azar construcción nocturna H

Tener 5000 desarrolladores que acceden a 2000 proyectos que se encuentran en un estado continuo de flujo parece una receta para el desastre, y Google contrata a personas muy inteligentes, por lo que estoy bastante seguro de que eso no es lo que realmente está sucediendo.


1. Por supuesto, pero es por eso que mencioné el caso en el que se realiza una modificación en un proyecto que afecta a muchos otros proyectos. Esto no sucede a menudo, pero sucede. 2. En el video, Ashish Kumar señala que la base de código está principalmente en C y Java. No se mencionó a Go.
Arseni Mourzenko

Entonces, tal vez la creación de Go es una respuesta a las dificultades que están teniendo.
Robert Harvey

Es cierto, pero aún así, Google todavía fue capaz de hacerlo funcionar durante años. ¿Cómo?
Arseni Mourzenko

¿Muy cuidadosamente? Recuerde, no solían ser tan grandes como lo son ahora. ¿Viste el video que Patrick enlazó?
Robert Harvey

1
No estoy realmente interesado en la época en que la base de código de Google era pequeña, ni en la época en que Google migró mágicamente / migrará toda la base de código a Go. Estoy hablando de 2010 (en el momento en que Ashish Kumar está hablando de la base de código, supongo que es 2010). En 2010 , según el video de Ashish Kumar, (1) la base de código es enorme, (2) contiene C y Java primarios, (3) todo está compilado desde la fuente, (4) los desarrolladores de Google aún pueden abrir código en su IDE y los servidores aún pueden compilar el código. Nota: no, todavía no he visto el video que Patrick ha vinculado. Lo veré mañana.
Arseni Mourzenko
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.