Al revisar las páginas anteriores, un tema se repite una y otra vez: administrar tu propio código es bastante sencillo, pero administrar sus dependencias es mucho sea más difícil. Hay todo tipo de dependencias: a veces, hay una dependencia en una tarea (como “enviar la documentación antes de marcar una versión como completa”) y, a veces, hay una dependencia en un artefacto (como “necesito tener la versión más reciente de la biblioteca de visión por computadora para compilar mi código”). A veces, tienes dependencias internas en otra parte de tu base de código y, a veces, tienes dependencias externas en código o datos que pertenecen a otro equipo (ya sea en tu organización o en un tercero). Pero, en cualquier caso, la idea de “I necesito eso antes de poder tener esto” es algo que aparece repetidamente en el del diseño de sistemas de compilación y la administración de dependencias es quizás el trabajo fundamental de un sistema de compilación.
Maneja con módulos y dependencias
Los proyectos que usan sistemas de compilación basados en artefactos, como Bazel, se dividen en un conjunto de módulos, con módulos que expresan dependencias entre sí a través de archivos BUILD. La organización adecuada de estos módulos y dependencias puede tener un efecto enorme en el rendimiento del sistema de compilación y en la cantidad de trabajo que se necesita para mantenerlo.
Usa módulos detallados y la regla 1:1:1
La primera pregunta que surge cuando se estructura una compilación basada en artefactos es decidir cuánta funcionalidad debe abarcar un módulo individual. En Bazel,
Un módulo se representa con un objetivo que especifica una unidad compilable, como una
java_library o go_binary. En un extremo, todo el proyecto podría estar contenido en un solo módulo si se coloca un archivo BUILD en la raíz y se agrupan de forma recursiva todos los archivos fuente de ese proyecto. En el otro extremo, casi todos los archivos de origen se pueden convertir en su propio módulo, lo que requiere que cada archivo enumere en un archivo BUILD todos los demás archivos de los que depende.
La mayoría de los proyectos se encuentran entre estos extremos, y la elección implica
para compensar
el rendimiento y el mantenimiento. Usar un solo módulo para la
todo un proyecto puede significar que nunca necesitarás tocar el archivo BUILD, excepto
cuando se agrega una dependencia externa, pero significa que el sistema de compilación debe
crear todo el proyecto de una sola vez. Esto significa que no podrá
paralelizar o distribuir partes de la compilación, ni almacenar en caché partes
que ya está construido. Un módulo por archivo es lo opuesto: el sistema de compilación tiene la máxima flexibilidad en la caché y la programación de los pasos de la compilación, pero los ingenieros deben esforzarse más para mantener las listas de dependencias cada vez que cambian a qué archivos hacen referencia.
Aunque el nivel de detalle exacto varía según el lenguaje (y, a menudo, incluso dentro del mismo lenguaje), Google tiende a favorecer módulos mucho más pequeños de los que se suelen escribir en un sistema de compilación basado en tareas. Un binario de producción típico en Google a menudo depende de decenas de miles de destinos, y hasta un equipo de tamaño moderado puede tener varios cientos de destinos dentro de su base de código. Para lenguajes como
con una sólida noción integrada de empaquetado, cada directorio suele
contiene un solo paquete, destino y archivo BUILD (Pants, otro sistema de compilación
basado en Bazel, lo llama la regla 1:1:1). Los lenguajes con convenciones de empaquetado más débiles suelen definir varios destinos por archivo BUILD.
Los beneficios de los objetivos de compilación más pequeños realmente comienzan a mostrarse a gran escala, ya que generan compilaciones distribuidas más rápidas y una necesidad menos frecuente de volver a compilar los objetivos.
Las ventajas se vuelven aún más convincentes
después de que se hacen pruebas,
objetivos más precisos permite que el sistema de compilación sea más inteligente
ejecutar solo un subconjunto limitado de pruebas que podrían verse afectados por cualquier
cambio. Debido a que Google cree en los beneficios sistémicos de usar
objetivos, logramos algunos avances en la mitigación del inconveniente al invertir en
herramientas para administrar automáticamente archivos BUILD y evitar abrumar a los desarrolladores
Algunas de estas herramientas, como buildifier y buildozer, están disponibles con
Bazel en el
directorio buildtools.
Minimiza la visibilidad de los módulos
Bazel y otros sistemas de compilación permiten que cada destino especifique una visibilidad, como
que determina qué otros destinos pueden depender de él. Solo se puede hacer referencia a un objetivo privado dentro de su propio archivo BUILD. Un objetivo puede otorgar permisos
visibilidad para los destinos de una lista definida de forma explícita de archivos BUILD, o
en el caso de la visibilidad pública, a todos los objetivos del espacio de trabajo.
Al igual que con la mayoría de los lenguajes de programación, lo mejor es minimizar la visibilidad lo
más posible. Generalmente, los equipos de Google hacen públicos los objetivos solo si
esos objetivos representan bibliotecas muy usadas y disponibles para cualquier equipo de Google.
Los equipos que requieran que otras personas se coordinen con ellos antes de usar su código mantendrán una lista de entidades permitidas de objetivos de clientes como visibilidad de su objetivo. Los objetivos de implementación internos de cada equipo se restringirán solo a los directorios que sean propiedad del equipo, y la mayoría de los archivos BUILD tendrán solo un objetivo que no sea privado.
Administra dependencias
Los módulos deben poder hacer referencia a otros. La desventaja de dividir una base de código en módulos detallados es que debes administrar las dependencias entre esos módulos (aunque las herramientas pueden ayudar a automatizar este proceso). Expresando estos
por lo general, las dependencias terminan siendo la mayor parte del contenido de un archivo BUILD.
Dependencias internas
En un proyecto grande, dividido en módulos detallados, la mayoría de las dependencias probablemente sean internos; es decir, en otro destino definido y integrado en la misma en un repositorio de código fuente. Las dependencias internas difieren de las dependencias externas que se compilan desde la fuente en lugar de descargarse como un artefacto compilado previamente. mientras ejecutas la compilación. Esto también significa que no hay noción de “versión” para las dependencias internas: un destino y todas sus dependencias internas siempre se compilan en la misma confirmación o revisión del repositorio. Un problema que se debe controlar con cuidado con respecto a las dependencias internas es cómo tratar las dependencias transitivas (Figura 1). Supongamos que el objetivo A depende del objetivo B, que depende de un destino de biblioteca C en común. ¿Debe el objetivo A poder usar las clases definidas en el objetivo C?
Figura 1. Dependencias transitivas
En lo que respecta a las herramientas subyacentes, no hay problema con esto. B y C se vincularán al destino A cuando se compile, por lo que A conocerá todos los símbolos definidos en C. Bazel permitió esto durante muchos años, pero a medida que Google crecía, comenzaste a ver problemas. Supongamos que B se refactorizó, de modo que ya no necesario depender de C. Si luego se quitara la dependencia de B de C, entonces A y cualquier otro el destino que usa C mediante una dependencia en B, fallaría. En efecto, las dependencias de un objetivo se convirtieron en parte de su contrato público y nunca se pudieron cambiar de forma segura. Esto significaba que las dependencias se acumulaban con el tiempo y las compilaciones en Google comenzó a ralentizarse.
Con el tiempo, Google resolvió este problema con la introducción de un “modo de dependencia transitiva estricta” en Bazel. En este modo, Bazel detecta si un destino intenta hacer referencia a un símbolo sin depender de él directamente y, de ser así, falla con un error y un comando de shell que se puede usar para insertar automáticamente la dependencia. Implementar este cambio en toda la base de código de Google y refactorizar cada uno de nuestros millones de objetivos de compilación para enumerar explícitamente sus de dependencias fue un esfuerzo de varios años, pero valió la pena. Nuestras compilaciones ahora son mucho más rápidas, ya que los destinos tienen menos dependencias innecesarias, y los ingenieros pueden quitar las dependencias que no necesitan sin preocuparse por romper los destinos que dependen de ellas.
Como es habitual, aplicar dependencias transitivas estrictas implica un equilibrio. Hizo que
archivos de compilación más detallados, ya que ahora se deben enumerar las bibliotecas de uso frecuente
de forma explícita en muchos lugares, en lugar de
extraerse accidentalmente, y los ingenieros
necesario para dedicar más esfuerzo a agregar dependencias a los archivos BUILD. Desde entonces, desarrollamos herramientas que reducen esta tarea, ya que detectan automáticamente muchas dependencias faltantes y las agregan a un archivo BUILD sin ninguna intervención del desarrollador. Sin embargo, incluso sin esas herramientas, descubrimos que la compensación vale la pena a medida que la base de código se escala: agregar explícitamente una dependencia al archivo BUILD es un costo único, pero lidiar con dependencias transitivas implícitas puede causar problemas continuos mientras exista el destino de compilación. Bazel
aplica dependencias transitivas estrictas
en el código Java de forma predeterminada.
Dependencias externas
Si una dependencia no es interna, debe ser externa. Las dependencias externas son aquellas que se basan en artefactos que se compilan y almacenan fuera del sistema de compilación. El una dependencia se importa directamente desde un repositorio de artefactos (a los que se accede a través de Internet) y se usan como están, en lugar de compilarse a partir de la fuente. Uno de La diferencia más grande entre las dependencias internas y externas las dependencias externas tienen versiones, y esas versiones existen independientemente de el código fuente del proyecto.
Comparación entre la administración de dependencias automática y manual
Los sistemas de compilación pueden permitir que se administren las versiones de dependencias externas
de forma manual o automática. Cuando se administra de forma manual, el archivo de compilación enumera de forma explícita la versión que desea descargar del repositorio de artefactos, a menudo con una cadena de versión semántica, como 1.1.4. Cuando se administra automáticamente, el archivo fuente especifica un rango de versiones aceptables, y el sistema de compilación siempre descarga la más reciente. Por ejemplo, Gradle permite que una versión de dependencia se declare como “1.+” para especificar que se acepta cualquier versión secundaria o de parche de una dependencia, siempre que la versión principal sea 1.
Las dependencias administradas automáticamente pueden ser convenientes para proyectos pequeños, pero por lo general, son una receta para los desastres en proyectos de tamaño no trivial o que en las que está trabajando más de un ingeniero. El problema de la configuración automática las dependencias administradas es que no tienes control sobre cuándo se crea la versión se actualicen. No hay forma de garantizar que las partes externas no realicen actualizaciones que generen errores (incluso cuando afirman usar el control de versiones semánticas), por lo que una compilación que funcionó un día podría fallar al día siguiente sin una forma sencilla de detectar qué cambió o de revertirla a un estado funcional. Incluso si la compilación no falla, puede pueden ser cambios sutiles en el comportamiento o el rendimiento que son imposibles de rastrear.
En cambio, debido a que las dependencias administradas manualmente requieren un cambio en la fuente tienen más control, pueden descubrirse y revertirse fácilmente, y es posible revisa una versión anterior del repositorio para compilar con dependencias antiguas. Bazel requiere que las versiones de todas las dependencias se especifiquen manualmente. Incluso a escalas moderadas, la sobrecarga de la administración manual de versiones vale la pena por la estabilidad que proporciona.
La regla de una versión
Por lo general, las diferentes versiones de una biblioteca se representan con artefactos diferentes, por lo que, en teoría, no hay razón para que no se puedan declarar diferentes versiones de la misma dependencia externa en el sistema de compilación con nombres diferentes. De esa manera, cada destino podría elegir qué versión de la dependencia quería usar. Esto genera muchos problemas en la práctica, por lo que Google aplica Regla de una versión para todas las dependencias de terceros en nuestra base de código.
El mayor problema de permitir varias versiones es la dependencia del diamante problema. Supongamos que el destino A depende del destino B y de la versión 1 de una biblioteca externa. Si posteriormente el destino B se refactoriza para agregar una dependencia en la v2 del mismo externa, el destino A no funcionará porque ahora depende implícitamente de dos diferentes versiones de la misma biblioteca. En realidad, nunca es seguro agregar una dependencia nueva de un destino a cualquier biblioteca de terceros con varias versiones, ya que cualquiera de los usuarios de ese destino podría depender de una versión diferente. Si se sigue la regla de una versión, este conflicto es imposible. Si un objetivo agrega una dependencia a una biblioteca de terceros, las dependencias existentes ya estarán en esa misma versión, por lo que pueden coexistir.
Dependencias externas transitivas
Lidiar con las dependencias transitivas de una dependencia externa puede ser particularmente difícil. Muchos repositorios de artefactos, como Maven Central, permiten artefactos para especificar dependencias en versiones particulares de otros artefactos en del repositorio. Las herramientas de compilación, como Maven o Gradle, suelen descargar de forma recursiva cada dependencia transitiva de forma predeterminada, lo que significa que agregar una sola dependencia en tu proyecto podría provocar que se descarguen decenas de artefactos en total.
Esto es muy conveniente: cuando se agrega una dependencia a una biblioteca nueva, sería un gran problema tener que hacer un seguimiento de cada una de las dependencias transitivas de esa biblioteca y agregarlas todas de forma manual. Sin embargo, también tiene un gran inconveniente: como las diferentes bibliotecas pueden depender de diferentes versiones de la misma biblioteca de terceros, esta estrategia incumple necesariamente la regla de una versión y genera el problema de dependencia de diamante. Si tu destino depende de dos bibliotecas externas que usan versiones diferentes de la misma dependencia, no se puede saber cuál obtendrás. Esto también significa que actualizar una dependencia externa podría causar fallas no relacionadas en la base de código si la nueva versión comienza a incorporarse versiones conflictivas de algunas de sus dependencias.
Por este motivo, Bazel no descarga automáticamente las dependencias transitivas.
Lamentablemente, no hay una solución mágica. La alternativa de Bazel es requerir un archivo global que enumere cada una de las dependencias externas del repositorio y una versión explícita que se use para esa dependencia en todo el repositorio. Por suerte, Bazel proporciona herramientas que pueden mostrar automáticamente
generar un archivo que contenga las dependencias transitivas de un conjunto de
artefactos. Esta herramienta se puede ejecutar una vez para generar el archivo WORKSPACE inicial
para un proyecto, y ese archivo se puede actualizar de forma manual para ajustar las versiones
de cada dependencia.
Una vez más, la elección aquí es entre conveniencia y escalabilidad. Pequeño es posible que los proyectos prefieran no tener que preocuparse por administrar dependencias transitivas y podrían dejar de usar las funciones las dependencias. Esta estrategia se vuelve cada vez menos atractiva a medida que la organización y la base de código crece, y los conflictos y resultados inesperados se vuelven frecuentes. A gran escala, el costo de administrar dependencias manualmente es mucho son menores que el costo de lidiar con los problemas causados por la dependencia automática y administración de posturas.
Cómo almacenar en caché los resultados de compilación con dependencias externas
Las dependencias externas suelen ser proporcionadas por terceros que liberan estables de bibliotecas, quizás sin proporcionar código fuente. Algunas organizaciones también pueden optar por hacer que parte de su propio código esté disponible como artefactos, lo que permite que otros fragmentos de código dependan de ellos como dependencias de terceros en lugar de dependencias internas. Esto puede acelerar, en teoría, las compilaciones si se detecta son lentos para compilar, pero se descargan rápido.
Sin embargo, esto también genera mucha sobrecarga y complejidad: alguien debe ser responsable de compilar cada uno de esos artefactos y subirlos al repositorio de artefactos, y los clientes deben asegurarse de mantenerse al día con la versión más reciente. La depuración también se vuelve mucho más difícil porque se compilarán diferentes partes del sistema desde diferentes puntos del repositorio y ya no habrá una vista coherente del árbol de origen.
Una mejor manera de resolver el problema de los artefactos que tardan mucho tiempo en construirse es usar un sistema de compilación que admita el almacenamiento en caché remoto, como se describió anteriormente. Este el sistema de compilación guarda los artefactos resultantes de cada compilación en una ubicación que se comparte entre los ingenieros, de modo que si un desarrollador depende de un artefacto que que otra persona haya creado recientemente, el sistema de compilación descarga automáticamente en lugar de compilarlo. Esto proporciona todos los beneficios de rendimiento de depender directamente de los artefactos y, al mismo tiempo, garantiza que las compilaciones sean tan coherentes como si siempre se compilaran desde la misma fuente. Este es el que usa Google internamente, y Bazel puede configurarse para que use un servidor la caché.
Seguridad y confiabilidad de las dependencias externas
Depender de artefactos de fuentes externas es intrínsecamente riesgoso. Existe un riesgo de disponibilidad si la fuente de terceros (como un repositorio de artefactos) falla, ya que toda la compilación podría detenerse si no puede descargar una dependencia externa. También existe un riesgo de seguridad: si un atacante vulnera el sistema de terceros, podría reemplazar el artefacto al que se hace referencia por uno de su propio diseño, lo que le permitiría insertar código arbitrario en tu compilación. Ambos problemas se pueden mitigar reflejando los artefactos de los que dependes en los servidores que controlas y bloqueando el acceso de tu sistema de compilación a repositorios de artefactos de terceros, como Maven Central. La desventaja es que
estos espejos requieren esfuerzo y recursos para mantenerlos, por lo que la decisión de si
usarlos a menudo depende de la escala del proyecto. El problema de seguridad también puede
puede evitarse por completo con poca sobrecarga, ya que solicita el hash de cada
que un artefacto de terceros se especifique en el repositorio de código fuente, lo que hace que la compilación
a fallar si se manipuló el artefacto. Otra alternativa que completamente
el problema es proveer las dependencias de tu proyecto. Cuando un proyecto vende sus dependencias, las incluye en el control de código fuente junto con el código fuente del proyecto, ya sea como fuente o como objetos binarios. Esto significa efectivamente
que todas las dependencias externas del proyecto se conviertan en dependencias
las dependencias. Google usa este enfoque de forma interna y verifica cada biblioteca de terceros a la que se hace referencia en Google en un directorio third_party en la raíz del árbol de fuentes de Google. Sin embargo, esto funciona en Google solo porque la
el sistema de control de origen está diseñado
para manejar un monorepo grande.
la creación de proveedores de productos
podría no ser una opción para todas las organizaciones.