Si revisas las páginas anteriores, verás que un tema se repite una y otra vez: administrar tu propio código es bastante sencillo, pero administrar sus dependencias es mucho 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 “Necesito eso antes de poder tener esto” es algo que se repite de forma reiterada en el diseño de los sistemas de compilación, y la administración de dependencias es quizás la tarea más fundamental de un sistema de compilación.
Cómo trabajar 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 destino que especifica una unidad compilable, como una java_library o una 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 una compensación entre el rendimiento y la capacidad de mantenimiento. El uso de un solo módulo para todo el proyecto puede significar que nunca necesites modificar el archivo BUILD, excepto cuando agregues una dependencia externa, pero significa que el sistema de compilación siempre debe compilar todo el proyecto de una sola vez. Esto significa que no podrá
paralealizar ni distribuir partes de la compilación, ni tampoco podrá almacenar en caché partes
que ya se compilaron. Un módulo por archivo es lo opuesto: el sistema de compilación tiene la máxima flexibilidad en la creación de caché y la programación de 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. En el caso de lenguajes como Java, que tienen una noción integrada de empaquetado, cada directorio suele contener 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 las pruebas entran en juego, ya que los objetivos de mayor precisión significan que el sistema de compilación puede ser mucho más inteligente para ejecutar solo un subconjunto limitado de pruebas que podrían verse afectadas por cualquier cambio determinado. Debido a que Google cree en los beneficios sistémicos de usar objetivos más pequeños, hemos avanzado en la mitigación de las desventajas invirtiendo en herramientas para administrar automáticamente los archivos BUILD y evitar sobrecargar a los desarrolladores.
Algunas de estas herramientas, como buildifier y buildozer, están disponibles con Bazel en el directorio buildtools.
Minimiza la visibilidad del módulo
Bazel y otros sistemas de compilación permiten que cada destino especifique una visibilidad, una
propiedad que determina qué otros destinos pueden depender de ella. Solo se puede hacer referencia a un objetivo privado dentro de su propio archivo BUILD. Un objetivo puede otorgar visibilidad más amplia a los objetivos de una lista definida explícitamente 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
posible. Por lo general, los equipos de Google solo publican los objetivos si estos representan bibliotecas de uso general 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 referirse entre sí. 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). Expresar estas dependencias suele ser la mayor parte del contenido de un archivo BUILD.
Dependencias internas
En un proyecto grande dividido en módulos detallados, es probable que la mayoría de las dependencias sean internas, es decir, en otro destino definido y compilado en el mismo repositorio de origen. Las dependencias internas difieren de las externas en que se compilan desde la fuente en lugar de descargarse como artefacto precompilado mientras se ejecuta 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 destino A depende del destino B, que depende de un destino de biblioteca común C. ¿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, comenzamos a ver problemas. Supongamos que B se refactorizó de modo que ya no dependía de C. Si se quitara la dependencia de B en C, A y cualquier otro objetivo que use C a través de 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 comenzaron a ralentizar.
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. Lanzar este cambio en toda la base de código de Google y refactorizar cada uno de nuestros millones de destinos de compilación para enumerar de forma explícita sus 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 de costumbre, aplicar dependencias transitivas estrictas implicó una compensación. Hizo que los archivos de compilación fueran más detallados, ya que las bibliotecas de uso frecuente ahora deben enumerarse de forma explícita en muchos lugares en lugar de extraerse de forma incidental, y los ingenieros tuvieron que esforzarse más para 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 estrictas
transitivas
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. La dependencia se importa directamente desde un repositorio de artefactos (al que se suele acceder a través de Internet) y se usa tal como está, en lugar de compilarse desde la fuente. Una de las diferencias más importantes entre las dependencias externas y las internas es que las dependencias externas tienen versiones, y esas versiones existen independientemente del 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 las versiones de dependencias externas se administren 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 suelen ser un desastre en proyectos de tamaño no trivial o en los que trabaja más de un ingeniero. El problema con las dependencias administradas automáticamente es que no tienes control sobre cuándo se actualiza la versión. 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 fácil de detectar qué cambió o de revertirla a un estado funcional. Incluso si la compilación no falla, puede haber cambios sutiles de comportamiento o rendimiento que son imposibles de rastrear.
Por el contrario, como las dependencias administradas de forma manual requieren un cambio en el control de código fuente, se pueden descubrir y revertir fácilmente, y es posible consultar una versión anterior del repositorio para compilar con dependencias anteriores. Bazel requiere que las versiones de todas las dependencias se especifiquen de forma manual. 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 una estricta 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 el problema de dependencia de diamante. Supongamos que el destino A depende del destino B y de la versión 1 de una biblioteca externa. Si el destino B se refactoriza más adelante para agregar una dependencia en la versión 2 de la misma biblioteca externa, el destino A fallará porque ahora depende implícitamente de dos versiones diferentes 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 que los artefactos especifiquen dependencias en versiones particulares de otros artefactos en el 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 aparentemente no relacionadas en toda la base de código si la versión nueva comienza a extraer versiones en conflicto de algunas de sus dependencias.
Bazel no solía descargar dependencias transitivas automáticamente. Solía usar un archivo WORKSPACE que exigía que se enumeraran todas las dependencias transitivas, lo que generaba muchos problemas a la hora de administrar dependencias externas. Desde entonces, Bazel agregó compatibilidad con la administración automática de dependencias externas transitivas en forma de archivo MODULE.bazel. Consulta la descripción general de las dependencias externas para obtener más detalles.
Una vez más, la elección aquí es entre conveniencia y escalabilidad. Es posible que los proyectos pequeños prefieran no tener que preocuparse por administrar las dependencias transitivas por sí mismos y que puedan usar dependencias transitivas automáticas. Esta estrategia se vuelve cada vez menos atractiva a medida que la organización y la base de código crecen, y los conflictos y los resultados inesperados se vuelven cada vez más frecuentes. A escalas más grandes, el costo de administrar dependencias de forma manual es mucho menor que el costo de abordar los problemas causados por la administración automática de dependencias.
Almacenamiento en caché de resultados de compilación con dependencias externas
Por lo general, las dependencias externas son proporcionadas por terceros que lanzan versiones 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. En teoría, esto puede acelerar las compilaciones si los artefactos son lentos de compilar, pero rápidos de descargar.
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 que los artefactos tardan mucho tiempo en compilarse es usar un sistema de compilación que admita el almacenamiento en caché remoto, como se describió anteriormente. Un sistema de compilación de este tipo 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 otra persona compiló recientemente, el sistema de compilación lo 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. Esta es la estrategia que Google usa de forma interna, y Bazel se puede configurar para usar una caché remota.
Seguridad y confiabilidad de las dependencias externas
Depender de artefactos de fuentes de terceros es inherentemente 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 compensación es que estos espejos requieren esfuerzo y recursos para su mantenimiento, por lo que la decisión de usarlos a menudo depende de la escala del proyecto. El problema de seguridad también se puede evitar por completo con poca sobrecarga si se requiere que el hash de cada artefacto de terceros se especifique en el repositorio de origen, lo que hace que la compilación falle si se manipula el artefacto. Otra
alternativa que evita por completo el problema es vender 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 que todas las dependencias externas del proyecto
se convierten en dependencias internas. 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 solo funciona en Google porque el sistema de control de código de Google está personalizado para controlar un monorepo extremadamente grande, por lo que la venta a proveedores podría no ser una opción para todas las organizaciones.