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. depender de una tarea (por ejemplo, “enviar la documentación antes de marcar una versión como (completar”) y, a veces, depende de un artefacto (como “Necesito la última versión de la biblioteca de visión artificial para compilar mi código"). A veces, tienes dependencias internas en otra parte de tu base de código. a veces, hay dependencias externas en el código o datos que son propiedad de otro equipo (ya sea en tu organización o con 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 BUILD
archivos. 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.
Cómo usar módulos detallados y la regla de 1:1:1
La primera pregunta que surge cuando se estructura una compilación basada en artefactos es
decidir cuánta funcionalidad debe incluir 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 la otra fila
extremo, casi todos los archivos fuente podrían
convertirse en su propio módulo,
lo que requiere que cada archivo se incluya en un archivo BUILD, cada otro archivo 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 ni distribuir partes de la compilación, ni tampoco almacenar en caché las 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 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 idioma (y, a menudo,
lenguaje), Google tiende a favorecer módulos significativamente más pequeños
suelen escribir en un sistema de compilación
basado en tareas. Un objeto binario de producción típico en
Google suele depender de decenas de miles de objetivos, e incluso de una red de
puede tener cientos de objetivos
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 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 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 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 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
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 referirse unos 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, 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 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 existe la noción de “versión” las dependencias internas: un objetivo y todas sus dependencias internas que se compilan en la misma confirmación y revisión en el 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 objetivo 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 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. Efectivamente, la cobertura de un objetivo las dependencias pasaron a formar parte de su contrato público y nunca cambió. 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 ingresando una “configuración transitiva “modo de dependencia” 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 construcciones ahora mucho más rápido, dado que los objetivos tienen menos dependencias innecesarias los ingenieros pueden quitar dependencias que no necesitan sin preocuparse sobre romper objetivos que dependen de ellos.
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,
desarrollaron herramientas que reducen este trabajo repetitivo
detectando automáticamente muchos
las dependencias y agregarlas a un archivo BUILD sin ningún desarrollador
para la intervención del usuario. Pero incluso sin tales herramientas, descubrimos que el sacrificio está bien.
vale la pena a medida que se escala la base de código: se agrega de forma explícita 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. Para
Por ejemplo, Gradle permite declarar una versión de dependencia como “1.+” para especificar
que cualquier versión secundaria o de parche de una dependencia sea aceptable siempre que el
versión principal es 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 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 haber cambios sutiles de comportamiento o 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
Las diferentes versiones de una biblioteca suelen estar representadas por distintos artefactos por lo que, en teoría, no hay motivo para que diferentes versiones de la misma la dependencia no se pudo declarar 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 causa 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 objetivo A depende del objetivo B y de v1 de una dirección biblioteca. Si el objetivo B se refactoriza más adelante para agregar una dependencia en la versión 2 de la misma biblioteca externa, el objetivo 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. Seguir la regla de una versión imposibilita este conflicto (si una “target” agrega una dependencia en una biblioteca de terceros, cualquier dependencia existente ya estarán en esa versión, por lo que pueden coexistir sin problemas.
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 cada una dependencia transitiva de forma predeterminada, lo que significa que agregar una sola dependencia en tu proyecto podría hacer que se descarguen docenas de artefactos en total.
Esto resulta muy conveniente: al agregar una dependencia en una biblioteca nueva, sería es un gran inconveniente tener que rastrear cada una de las dependencias transitivas de esa biblioteca y agregarlos manualmente. 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.
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
de un proyecto, y ese archivo se puede actualizar manualmente para ajustar las versiones
de cada dependencia.
Sin embargo, una vez más, la elección 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 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.
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 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, asegurarse de que las compilaciones sean coherentes como si siempre se hubieran creado a partir de 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 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 el sistema de terceros
vulnerado por un atacante, este podría reemplazar la referencia
con uno propio con su propio diseño, lo que les permite inyectar
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 su mantenimiento, por lo que la decisión de 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 su sistema de control de código 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.